ストア内のレコードは、キーと値のペアとして編成されます。値は、格納、管理および取得するデータです。ほとんどの場合、Avroを使用して値のデータ・スキーマを指定し、値を作成する必要があります。Avroスキーマについては、「Avroスキーマ」で説明します。

単純なケースでは、値をバイト配列として編成することもできます。その場合、配列とデータ構造とのマッピング(シリアライズおよびデシリアライズ)はすべて、アプリケーションで行う必要があります。このマニュアルの最初の部分では、バイト配列を例で使用していますが、それは推奨される方法ではありません。かわりに、非常に単純な値に対しても、Avroを使用してください。

値のサイズに制限はありません。ただし、各レコードのサイズを決める際、ストアのパフォーマンスを考慮する必要があります。どのデータ格納方法でもそうですが、レコードが大きくなるほど、格納場所からの情報の読取りと格納場所への情報の書込みに時間がかかります。ストアの読取り/書込みのパフォーマンスに影響するほど値が大きくなった場合、あるいは大きすぎてメモリー・キャッシュに(またはJavaヒープ領域にさえも)収まらない場合は、Oracle NoSQL Databaseのラージ・オブジェクト・サポートを使用した値の格納を検討してください。詳細は、「ラージ・オブジェクトの使用」を参照してください。

その一方で、各レコードには一定のオーバーヘッドが伴います。また、レコードの数が非常に多くなると、検索時間に悪影響を及ぼし始めます。その結果、非常に多くの非常に小さなレコードを格納するようにすると、ストアのパフォーマンスを損う場合もあります。

したがって、ストアの内容を設計する際、少数の非常に大きなレコードと多数の非常に小さなレコードとの間で適切なバランスを見つける必要があります。特定の情報がアクセスされる頻度を考慮する必要もあります。

たとえば、ストアにユーザーに関する情報が含まれ、各ユーザーは電子メール・アドレスで識別されるとします。各ユーザーについて保持する情報のセットがあります。この情報には、サイズの小さなものもあれば、大きなものもあります。頻繁にアクセスされる情報もあれば、あまりアクセスされない情報もあります。

小さなプロパティには次のようなものがあります。

大きなプロパティには次のようなものがあります。

このデータを編成する方法はいくつか考えられます。方法は、データ・アクセス・パターンによって異なります。

たとえば、レコードにアクセスするたびに、前述のすべてのプロパティを読み書きする必要があるとします。(これはあまりないことですが、単純なケースの例です。)その場合、アプリケーションで、ユーザーについて保持する各プロパティを表す1つのAvroスキーマを作成します。すると、メジャー・キー・コンポーネントのみを使用してレコードを簡単に編成でき、たとえば、ユーザーBob Smithのすべてのデータにキー/Smith/Bobを使用してアクセスできます。

ただし、ユーザーのレコードにアクセスするたびにすべてのプロパティにアクセスする必要があることはあまりありません。ユーザー検索を行うたびにすべてのプロパティを必ず読み取る必要がある場合はありますが、更新時は多くの場合、一部のプロパティのみが操作されます。

このようなことから、データがアクセスされる頻度とデータのサイズを考慮することが有用です。あまりアクセスされない大きなプロパティは、頻繁にアクセスされるプロパティとは別のキーを使用する必要があります。これらの大きなプロパティ用の各キーはメジャー・キー・コンポーネントを共有できますが、マイナー・キー・コンポーネントは別にします。ただし、大きなプロパティに対してラージ・オブジェクト・サポートを使用している場合は、格納している他のプロパティで使用するメジャー・キーとは別のメジャー・キーの下にこれらを編成する必要があります。

同時に、ストアに含まれる各キーにはオーバーヘッドが伴うため、ユーザー・プロパティごとにキーを作成することはしません。したがって、多数の小さなプロパティがある場合、特定の操作で一部のプロパティのみが更新されたり、読み取られる可能性が高い場合でも、1つのキー下にすべてのプロパティを編成することがあります。

たとえば、前述のプロパティに対して、アプリケーションで次のようなことが必要だとします。

この場合、ユーザーごとに4つのキーを使用してユーザー・プロパティを格納します。各キーは同じメジャー・コンポーネントを共有しますが、マイナー・コンポーネントは次のように異なります。

マイナー・キー・コンポーネントのみが異なる別のキーの下に編成された任意のデータを使用すると、1つの原子的操作で様々なプロパティを一度に読み取ったり更新できるということで、ユーザー・レコードの更新でACIDが完全にサポートされます。同時に、絶対に必要な場合を除き、アプリケーションで大きなプロパティ(イメージ・ファイル、音声記録など)を読み書きする必要はありません。これらのラージ・オブジェクトを読み書きする必要がある場合は、このようなトラフィックに最適化されたOracle NoSQL Databaseのストリーム・インタフェースを使用できます。