行のサイズ、またはフィールドに格納するデータの量に制限はありません。ただし、各表および行のサイズを決める際、ストアのパフォーマンスを考慮する必要があります。どのデータ格納方法でもそうですが、行が大きくなるほど、格納場所からの情報の読取りと格納場所への情報の書込みに時間がかかります。
その一方で、各表の行には一定のオーバーヘッドが伴います。また、行の数が非常に多くなると、検索時間に悪影響を及ぼします。その結果、多数の表を使用する場合、各表はフィールド数が少ない行を使用するため、ストアのパフォーマンスが低下する可能性があります。
したがって、表の内容を設計する際、多数の行を使用する少数の表と、少数の行を使用する多数の表との間で適切なバランスを見つける必要があります。特定の情報がアクセスされる頻度を考慮する必要もあります。
たとえば、表にユーザーに関する情報が含まれ、各ユーザーは名と姓で識別されるとします。各ユーザーについて保持する情報のセットがあります。この情報には、サイズの小さなものもあれば、大きなものもあります。頻繁にアクセスされる情報もあれば、あまりアクセスされない情報もあります。
小さなプロパティには次のようなものがあります。
名前
性別
住所
電話番号
大きなプロパティには次のようなものがあります。
イメージ・ファイル
公開鍵1
公開鍵2
録音された音声あいさつ
このデータを編成する方法はいくつか考えられます。方法は、データ・アクセス・パターンによって異なります。
たとえば、行にアクセスするたびに、前述のすべてのプロパティを読み書きする必要があるとします。(これはあまりないことですが、単純なケースの例です。)その場合、アプリケーションで、ユーザーについて保持する各プロパティのフィールドを含む複数の行を作成します。
ただし、ユーザーの情報にアクセスするたびに、アプリケーションでそのユーザーのすべてのプロパティにアクセスする必要がなくなる可能性が高くなります。ユーザー検索を行うたびにすべてのプロパティを必ず読み取る必要がある場合はありますが、更新時は多くの場合、一部のプロパティのみが操作されます。
このようなことから、データがアクセスされる頻度とデータのサイズを考慮することが有用です。あまりアクセスされない大きなプロパティは、頻繁にアクセスされるプロパティとは別の表に配置する必要があります。
たとえば、前述のプロパティに対して、アプリケーションで次のようなことが必要だとします。
ユーザーのレコードがアクセスされるたびにすべての小さなプロパティが必ず使用されます。
単純なユーザー検索では、すべての大きなプロパティが読み取られます。
ユーザー情報が更新される際、同時に公開鍵が必ず更新されます(書き込まれます)。
イメージ・ファイルと記録された音声あいさつは、他のものとは別に更新されます。
この場合、表と子表を使用してユーザー・プロパティを格納できます。親表は、すべての小さいプロパティと公開鍵を含む行を保持します。子表にはイメージ・ファイルと音声あいさつが含まれます。
## Enter into table creation mode table create -name userInfo ## Now add the fields add-field -type STRING -name surname add-field -type STRING -name familiarName add-field -type STRING -name gender add-field -type STRING -name street add-field -type STRING -name city add-field -type STRING -name state add-field -type STRING -name zipcode add-field -type STRING -name userPhone add-field -type BINARY -name publickey1 add-field -type BINARY -name publickey2 primary-key -field surname -field familiarName shard-key -field surname ## Exit table creation mode exit ### Must add the parent table before we add the child plan add-table -name userInfo -wait table create -name userInfo.largeProps add-field -type STRING -name propType add-field -type BINARY -name voiceGreeting add-field -type BINARY -name imageFile primary-key -field propType exit plan add-table -name userInfo.largeProps -wait
親表には、ユーザー・データにアクセスしたときにアクセスされるすべてのデータが含まれるため、1回の原子的操作でデータを一度に更新できます。同時に、イメージ・データと音声あいさつを子表に分割することで、行を取得するときに大きいデータ値を取得しないようにできます。
イメージ・データと音声あいさつにキー/値APIを使用することもできます。これにより、ラージ・オブジェクトのサポートに最適化されたOracle NoSQL Databaseラージ・オブジェクト・インタフェースを使用できます。ラージ・オブジェクトの操作の詳細は、『Oracle NoSQL Database Key/Value APIスタート・ガイド』を参照してください。