値

ストア内のレコードは、キーと値のペアとして編成されます。値は、格納、管理および取得するデータです。

単純なケースでは、値をバイト配列として編成できます。(複雑な場合は、表APIを使用する必要があります。)その場合、配列とデータ構造とのマッピング(シリアライズおよびデシリアライズ)はすべて、アプリケーションで行う必要があります。

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

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

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

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

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

名前
性別
住所
電話番号

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

イメージ・ファイル
公開キー1
公開キー2
録音された音声あいさつ

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

注意:

次の例では、非推奨のAvroの使用方法について説明します。引き続きAvroを使用してデータを管理できますが、表APIの方が解決策として優れています。

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

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

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

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

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

ユーザーのレコードがアクセスされるたびにすべての小さなプロパティが必ず使用されます。
単純なユーザー検索では、すべての大きなプロパティが読み取られます。
ユーザー・レコードが更新される際、同時に公開キーが必ず更新されます(書き込まれます)。
イメージ・ファイルと記録された音声あいさつは、他のものとは別に更新されます。

この場合、ユーザーごとに4つのキーを使用してユーザー・プロパティを格納します。各キーは、次のようにユーザーを識別するために同じコンポーネントを共有します。

/surname/familiar name/-/contact

このキーに対する値は、すべての小さなユーザー・プロパティ(名前、電話番号、住所など)を含むAvroレコードです。
/surname/familiar name/-/publickeys

このキーに対する値は、ユーザーの公開鍵を含むAvroレコードです。これらは常に同時に読み書きされるため、1つのキー下に編成することは理にかなっています。
/image.lob/-/surname/familiar name

このキーに対する値は、Oracle NoSQL Databaseのラージ・オブジェクト・サポートを使用して保存したイメージ・ファイルです。
/audio.lob/-/voicegreeting/surname/familiar name

このキーに対する値も、ラージ・オブジェクト・サポートを使用して保存したmp3ファイルです。

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