表のモデル化と設計

Oracle NoSQL Databaseにおけるスキーマの柔軟性

スキーマが純粋に固定されたリレーショナル・データベースの世界とは異なり、NoSQL Databaseではスキーマの柔軟性に重点が置かれ、データの編成および格納方法を簡単に変更できます。

Oracle NoSQL Databaseのスキーマの柔軟性は、主に非スカラー・データ型の形式によるものです。これらの非スカラー・データ型を使用して、柔軟な構造を表に埋め込むことができます。

非スカラー・データ型:

Oracle NoSQL Databaseは、次の非スカラー・データ型がサポートされています。

JSON – JSONは、Oracle NoSQL Databaseで列のデータ型として使用できるキー/値ペアのマップです。JSONデータ型を使用すると、JSONドキュメントにどのような内容が格納されているかを事前に認識していなくても、動的に属性の読取りおよび書込みができます。Oracle NoSQL DatabaseからJSON文字列として読み取ることでドキュメントをイントロスペクトすることや、JSONの階層に必要な深さのパス式を指定することができます。たとえば、契約の可変条件を表すJSONドキュメントを作成できます。ドキュメント属性名(キー)は、契約条件のタグまたは名前を表し、属性の値はその条件のテキストを表すことができます。JSONを使用することで、データ・モデルに究極の柔軟性がもたらされます。
レコード – スカラー値または非スカラー値を含むレコードは、Oracle NoSQL Database表の列のデータ型として使用できます。レコードは一連の固定された属性を持つドキュメントと考えることができますが、レコードの1つ以上の属性を非固定配列またはJSONドキュメントにできるため、スキーマを変更しないで固定ドキュメントを柔軟に拡張できます。レコードは、固定スキーマの世界の利点(スキーマの単一コピー)とJSONワールドの究極の柔軟性の間の、興味深い中間ステップを示します。
配列 – スカラー値または非スカラー値の配列は、Oracle NoSQL Database表の列のデータ型として使用できます。配列は、イベント値のコレクションを格納する場合に便利です。たとえば、Webページを参照するユーザーの行動セグメントのリストを収集する場合があります。

柔軟なスキーマを使用する場合のトレードオフ:

柔軟なスキーマを検討する場合の指針にできるいくつかのガイドラインを次に示します。

柔軟性/スケーリング・コストのトレードオフ:

スキーマをどの程度柔軟にするかを検討するときには、スキーマの柔軟性が高くなればなるほど、ソリューションのスケーリングの課題が大きくなることを理解することが重要です。たとえば、ユーザーの行動に関する情報を保存するとします。この情報は、ユーザーがWebサイトにアクセスするときに保存する必要があります。ここでは、2つのオプションのいずれかを実装できます。追跡する必要がある必須ユーザー属性の固定列を使用して、ソリューションをモデル化することを選択できます。または、スキーマを進化させる必要なく、ユーザーの属性を柔軟に追加および削除できるように、JSONドキュメントを使用してこれをモデル化することを選択できます。

2番目のオプションは、少数のユーザーの場合に効率的に機能する可能性がありますが、このソリューションを多数のユーザーに拡張する必要がある場合は、追加の記憶域が必要となります。また、JSONドキュメントでキー/値ペア(属性名とその値)を処理するための追加の計算オーバーヘッドも必要となります。これにより、ソリューションのスケーリングにかかるコストが莫大なものになる可能性があります。メタデータとそのデータ(属性名など)を格納するために追加の記憶域が必要になり、さらにこれらのドキュメントのシリアライズおよびデシリアライズのために追加の計算が必要です。複数のレプリケーション係数を使用している場合、追跡されるユーザーごとにオーバーヘッドが増加します。大規模なスケーリングが主要な要件である場合は、柔軟性よりも記憶域の効率化を優先し、より固定されたスキーマの使用を検討することが適切である可能性が高くなります。

柔軟性/レイテンシのトレードオフ:

多くのNoSQLアプリケーションでは、低レイテンシのデータ・アクセスが重要な要件になります。このような状況では、あるデータ・モデリング方法を使用することで、他の方法にはない、I/Oレイテンシに関する潜在的なトレードオフが発生することを理解することが重要です。この観点からは、レコード、配列、JSONドキュメントなどの非スカラー・データ型を使用すると、読取りに続いて更新が行われます。

たとえば、配列に新しい値を追加する場合、アプリケーションはまずNoSQL Databaseからレコードを読み取り、配列に値を追加してからNoSQL Databaseにライトバックする必要があります。Oracle NoSQL DatabaseのSQL UPDATE演算子を使用してこの操作を実行する場合でも(レプリケーション・ノードで実行されます)、やはり、永続記憶域からレコードを読み取り、デシリアライズ、変更、シリアライズおよびライトバックする必要があります。回転式ディスクを使用するシステムでは、15ミリ秒から30ミリ秒の範囲で(またはそれ以上の)時間がかかる可能性があります。オンライン広告などの特定のアプリケーションの場合、これは許容されるレイテンシのSLAを超える可能性があります。同様の厳しいレイテンシのSLAに対処する必要がある場合は、読取りを伴わず、新しい値の書込みを単に実行できる子表アプローチを優先することを検討してください。ここでは低レイテンシと柔軟性の1つをトレードオフすることになります。

親子表を使用するタイミングの詳細は、「Oracle NoSQL Databaseでの親子表の使用」を参照してください。

非スカラーへの更新と挿入:

Oracle NoSQL Databaseストレージ・エンジンは、追加専用アーキテクチャ(ログ構造化記憶域とも呼ばれる)をその基礎としています。ログ構造化記憶域システムは、挿入する新しいレコードが単にログの最後に追加される挿入操作について、非常に効果的に機能します。更新操作では、更新されたレコードをログに追加した後、古いレコードに削除のマークを付けます。削除対象としてマークされたレコードは、ディスク領域を解放するために、クリーナと呼ばれるバックグラウンド・プロセスによってNoSQL Databaseのログから定期的にクリーン・アップされます。クリーナは高度に最適化されているものの、CPUおよびI/Oのオーバーヘッドがレプリケーションノードに追加されます。アプリケーションによって実行される更新が増加すると、ログのクリーニング・アクティビティも増加します。

ガイドラインとして、アプリケーション(または特定の表)のパフォーマンス目標が非常に高い場合は、親/子表と非スカラー列を使用してデータ・モデルを作成してみることを積極的に検討してください(これにより、更新が挿入に置き換えられる可能性があります)。親子表を使用するタイミングの詳細は、「Oracle NoSQL Databaseでの親子表の使用」を参照してください。

静的データと動的データ:

多くのアプリケーションでは、ある程度静的で比較的ゆっくり変化するデータ部分と、非常に動的でミリ秒の粒度でも頻繁に変化する他のデータ部分を識別できます。たとえば、オンライン広告では、キャンペーンは比較的動きの遅いデータである一方、予算消費(配信されたインプレッションやクリック数)は、何百万人ものユーザーがキャンペーンに関連付けられた広告を含むWebページをロードするために、数ミリ秒ごとに変化する可能性があります。予算に関するデータは、非常に動的なデータのケースとなります。これは、高速な書込み操作があるシナリオの例です。Oracle NoSQL Databaseはログ構造化された追加専用の記憶域アーキテクチャであり、更新操作よりも挿入が適しています。

データの静的な部分については、非スカラー・データ型の柔軟性が、アプリケーションにとって魅力的なオプションとなる場合があります。JSONドキュメントを使用すると、パフォーマンスを過度に犠牲にすることなく、アプリケーションでこのデータを操作するための拡張可能な方法が提供されます。その一方で、急速に変化するデータや迅速に挿入されるデータについては、このデータに対する柔軟性とのトレードオフを検討し、固定スキーマを持つ親表と固定スキーマを持つ子表を使用することが適切になります。急速に変化するデータを親表または子表としてモデル化するかどうかは、そのデータへのアクセス方法に大きく依存します。親子表を使用するタイミングの詳細は、「Oracle NoSQL Databaseでの親子表の使用」を参照してください。

NoSQL Databaseでのキーの選択

主キーおよびシャード・キーはスキーマの重要な要素として、データへのアクセスと分散の効率化に役立ちます。

主キーとシャード・キーは、データ分散および簡単なアクセスにとって不可欠です。主キーとシャード・キーは、表を作成するときにのみ指定します。表の存続期間中はそのまま維持され、変更や削除はできません。

Oracle NoSQL表での主キーとシャード・キーの使用

主キー

表を作成するときには、1つ以上の主キー列を指定する必要があります。主キーは変更できず、表の有効期間中は存在します。主キーは、表のすべての行を一意に識別します。単純なCRUD操作の場合、Oracle NoSQL Databaseは、読取りまたは変更する特定の行を取得するために主キーを使用します。NoSQL Databaseの基礎となる記憶域はキー/値モデルに基づいているため、主キーを選択すると、特定の参照操作のパフォーマンスが大幅に向上する可能性があります。

シャード・キー

シャード・キーの主な目的は、スケーラビリティ実現のためにOracle NoSQL Databaseクラスタ全体にデータを分散し、かつ、参照しやすくするために、同じシャード・キーを共有するレコードを同じ物理ノード上にまとめることです。これらのレコードには、アトミックかつ効率的にアクセスできます。

アプリケーション開発時のキーの影響:

Oracle NoSQL Databaseでは、レプリケーション・ノードがグループ化されて、NoSQL Databaseクラスタのシャードを形成します。アプリケーションが特定のキーのレコードを取得するように要求すると、NoSQL Databaseドライバは、キーの一部(シャード・キーとして示される)をハッシュして、データを格納するシャードを識別します。シャードが識別されると、NoSQL Databaseドライバは、要求された一貫性レベルに応じて、シャード内の最適なレプリカからデータを読み取ることを選択できます。書込み操作については、NoSQL Databaseドライバは、常に書込みリクエストをシャードの動的に選択されたリーダー・ノードにルーティングします。したがって、ワークロード・スケーリングの観点からは、通常、このアーキテクチャはシャードを追加することでスケーリングされていると考えることができます。Oracle NoSQL Databaseでは、シャードを追加することで、クラスタのオンラインでのエラスティックな拡張をサポートしていますが、シャード・キーを適切に選択しないと、クラスタの拡張はソリューションのスケーリングに役立ちません。

主キーとシャード・キーをどのように設計するかは、システム・スループットのスケーリングと実現に大きく影響します。たとえば、レコード間でシャード・キーを共有すると、1つのアトミック操作で複数の表の行を削除することや、1つのアトミック操作で表の行のサブセットを取得することができます。シャード・キーを適切に設計すると、スケーラビリティが実現されるのみでなく、単一のシャードに対するデータの配置またはデータの取得に必要なサイクル数が減ることで、パフォーマンスを改善できます。シャード・キーでは、キー値の問合せを効率化するために、同じシャード上の記憶域を指定します。ただし、最適なパフォーマンスとスケーラビリティを実現するにはデータをシャード間で分散することが適切であるため、少数の一意の値を持つシャード・キーは避ける必要があります。

シャード・キーの選択時に考慮する重要な要素:

カーディナリティ: 低カーディナリティのフィールド・グループは、少数のシャードにまとめて格納されます。これらのシャードでは頻繁にデータ・リバランスを行う必要があるため、ホット・シャードの問題が発生する可能性が高くなります。一方、各シャード・キーのカーディナリティは高くなり、値が数100万個になることもあります。パフォーマンスと価値を最大限に高めるには、よりカーディナリティの高いフィールド(ID番号など)を選択して、数百万件のレコードに対応できるようにします。
原子性:同じシャード・キーを共有するオブジェクトのみをトランザクションに含めることができます。複数のレコードにわたるACIDトランザクションの要件がある場合は、その要件を満たすことができるシャード・キーのみを選択します。

指針となるベスト・プラクティス:

シャード・キーの均一分散:操作は、1つのシャードの容量によって制限される可能性があります。シャード・キーが均一に分散されている場合、1つのシャードによってシステムの容量が制限されることはありません。値が均等に分散されることがわかっている1つ以上の列を選択することが理想的です。
問合せの分離: スケーラビリティを最大化するには、問合せのターゲットを特定のシャードに限定します。問合せが単一のシャードに分離されていない場合、問合せはすべてのシャードに適用されます。これは効率性が低く、問合せレイテンシが増加します。問合せで単一のシャードに格納されたデータがフェッチされるようにします。シャード・キーを適切に設計し、単一のシャードからデータが取得されるようにすることでパフォーマンスを改善できます。シャード・キーでは、キー値の問合せを効率化するために、同じシャード上の記憶域を指定します。フィールド(アプリケーション問合せで頻繁に使用される)をシャード・キーとして指定します。

キー・サイズとキーのみのモデル化方法

Oracle NoSQL Databaseは、各表のキーをキャッシュします。そのため、キー・サイズはメモリーを効果的に使用するために重要なコンポーネントとなり、最終的には、Oracle NoSQL DatabaseがパフォーマンスSLAに対処できるかどうかを決定する要素となる可能性があります。したがって、サイズに関して可能なかぎり効率的な主キーを作成することが重要です。1秒当たり数百万の操作にわたって読取りと書込みのレイテンシを非常に低くする(1桁から2桁台前半のミリ秒)必要があるワークロードの場合、NoSQLのBツリーにキャッシュされたキーを活用することが、これらの厳しい要件を達成可能なアプリケーションを構築できるかどうかを左右する場合があります。さらに、他の方法ではキーにならない値をエンコードして主キーの一部とし、かつキーとNoSQL Databaseクラスタのサイズを慎重に設定することが可能な場合は、ACIDセマンティクスで維持されるメモリー・キャッシュされたBツリー・アクセス方法による非常に優れた利点を実現できます。高度に最適化され、レイテンシが非常に低いアプリケーションに関しては、Oracle NoSQLは、すべてをキーのみのデータとしてモデル化できるワークロードに対して、キーのみのアクセサを提供します。Oracle NoSQL Databaseは、キーのみのスキャンを実行するために、multiKetGeysやtableKeysIteratorなどの便利なキーのみのアクセスAPIを提供します。

データのキーのみのモデル化がアプリケーションに適しているかどうかを検討するときには、次のことを考慮してください。

レイテンシおよびスループットのSLA - キーのみのモデルを必要とする、非常に厳しいレイテンシおよびスループットのSLAはありますか。値の取得時にI/Oを実行する余裕はありますか。回転式ディスクでは値取得の平均レイテンシは15から30ミリ秒の範囲で、単一共有ディスク(SSD)ではこれは1から5ミリ秒の範囲である可能性があります。
回転式ディスクとSSD - SSDの使用を検討していて、レイテンシSLAの対象の読取りが5ミリ秒の範囲内に問題なく収まる場合、そのアプリケーションに関してはキーのみのモデルを作成することに労力を費やす意味はない可能性があります。
コードの保守性と拡張性 - キーのみのモデル化により、コードのメンテナンス性と拡張性の潜在的なコストにおいて、パフォーマンス上の大きな利点がアプリケーションにもたらされます。値をキーにエンコードすることが、最終的には複雑で難解な戦略となる可能性があります。最終的に、開発および保守するコードが、キーのみのソリューションがもたらす利点に対して過度に複雑で難解かどうかを判断する必要があります。
データの正確なサイズ設定 - Oracle NoSQL Databaseクラスタを適切にサイズ設定できるように、キーのある程度正確なサイズ設定を導出することはできますか。キーのみのデータ・モデルの利点を活用するには、各レプリケーション・ノードのクラスタおよびキャッシュのサイズ設定が重要です。

キー列の順序付けおよび問合せ機能

Oracle NoSQL Databaseにおいて、キー列を宣言する順序は、部分的なキー参照問合せを満たすために重要です。これは、ストレージ・エンジンが基礎となるBツリーを管理する方法によるものです。コンポジット・キーは、キー宣言(主キーまたは索引キー)のDDLで指定された列を順序に従って連結したものと考えることができます。キーのDDLでの列の出現順序は、最も重要な列から最も重要でない列の順にすると考えてください。表にコンポジット主キー(複数の列を持つ主キー)がある場合、主キーは、各列の文字列表現を連結したものになります。この場合に問合せのパフォーマンスを改善するには、最も一般的に使用される問合せ列を、主キーで最も重要な列として指定することが重要です。

クラスタとOracle NoSQL Databaseキャッシュのサイズ設定方法を考える場合、重要な考慮事項は、キー・サイズの見積りを取得することです。Oracle NoSQLにより、ほとんどまたはすべての索引ノードをメモリーに保持できるようキャッシュのサイズを設定すると、アプリケーションで、パフォーマンス上の多数の利点を実現できます。キーのシリアライズ方法と永続的な格納方法を理解することは、より正確にサイズ設定を見積るために役立ちます。Oracle NoSQL Databaseでは、数値キーは圧縮された文字列値として格納されますが、文字列書式の場合は、ソート可能なままにしておく必要があります。つまり、数値キーは、キー文字列として表される場合、固定サイズである必要があります。シャード容量、シャード記憶域およびスループット容量の詳細と、シャードとマシンの合計を見積る方法については、「初期容量計画」を参照してください。

NoSQL Databaseでの索引の使用

Oracle NoSQL Databaseでは、問合せプロセッサは、使用可能な索引のうち問合せに有効なものを識別し、その索引を利用するように問合せをリライトできます。

索引を使用するとは、そのエントリの連続した部分範囲をスキャンしたり、その部分範囲内のエントリに対してさらにフィルタリング条件を適用したり、関連する表の行を抽出して返すために、索引エントリに格納されている主キーを使用することを意味します。スキャンする索引エントリの部分範囲はWHERE句の条件によって決定され、その一部は索引の検索条件に変換される場合があります。索引エントリの(できれば小さい)サブセットのみが検索条件を満たす場合、個々の表の行にアクセスせずに問合せを評価できるため、大量に発生する可能性があるディスク・アクセスを抑制できます。

Oracle NoSQL Databaseでは、主キー索引がデフォルトで常に作成されます。この索引は、表の主キー列を表の行の物理的な位置にマップします。また、使用可能な他の索引がない場合は、主索引が使用されます。つまり、純粋な表スキャン・メカニズムはありません。表スキャンは主キー索引を使用したスキャンと同等です。索引および問合せについては、問合せプロセッサが次の2つの質問に回答する必要があります。

索引は問合せに適用可能ですか。つまり、この索引を使用して表にアクセスするほうが、(主索引を使用して)全表スキャンを実行するよりも効率的ですか。
適用可能な索引の中で、どの索引または索引の組合せを使用するのが最適ですか。

表の列内の値の数と分布に関する統計はありません。そのため、問合せプロセッサは、適用可能な索引の選択において、単純な経験則に依存するしかありません。また、SQL for Oracle NoSQL Databaseでは、問合せに索引ヒントを含めることができます。索引ヒントを使用すると、問合せで特定の索引の使用を強制できます。問合せ実行計画を使用して、問合せで使用されている索引を把握できます。問合せの実行方法の詳細は、「問合せ実行計画」を参照してください。

2次索引

読取り要件の一部をサポートするために、2次索引を使用することが必要になる場合があります。各2次索引を表に追加すると、各索引を維持する必要があるため、書込みのオーバーヘッドが発生します。Oracle NoSQLの優れた点は、2次索引パーティションが主データと同じシャードに存在するため、2次索引に対する更新がシャード単位で制限されることです。Oracle NoSQLの索引更新もアトミックであるため、シャード内のレコードに対する更新が2次索引に対する更新と一致し、これらの構造は必ず同期することがアプリケーションに対して保証されます。考慮するもう1つの要素は、Oracle NoSQL Databaseノードでは、リーフ以外の索引ノードがキャッシュに保持され、リーフ部分(データ・レコードなど)がキャッシュされないことです。これにより、索引付きスキャンでは、索引なしスキャンを上回るパフォーマンス上の多数の利点が得られます(回転式ディスクを使用するシステムの場合)。

Oracle NoSQL Databaseで2次索引の使用を決定する際には、いくつかの点を考慮する必要があります。

ソースに近いデータのフィルタ処理 - Oracle NoSQL Databaseでは、問合せにフィルタが必要で、そのフィルタをデータのできるかぎり近くで実行する必要がある場合、主なメカニズムとして2次索引を利用します。問合せ用にデータをフィルタ処理する際に2次索引が必要な理由を完全に理解するために、表内のデータをスキャンするオプションについて考えてみましょう。
- フル・シャード・キーのない、順序付けされていないパラレル表スキャン - シャード・キーは、表で行をどのように分散するかを制御するために使用される、その表の1つ以上の列です。シャード・キーの主な目的は、スケーラビリティ実現のためにOracle NoSQL Database Cloudクラスタ全体にデータを分散し、かつ参照およびアクセスしやすくするために、同じシャード・キーを共有するレコードをローカルに配置することです。フィルタを使用する問合せを記述し、そこに含まれる列の中にシャード・キーの一部であるものとそれ以外のものがある場合は、結局パラレル表スキャンを実行することになります。各シャードはパラレルにスキャンされ、データがアプリケーションに返されます。これにより、NoSQL Databaseのすべてのシャードにわたる表内のすべてのレコードが返されます。
- 順序付きまたは順序付けされていないパラレル索引スキャン - 各シャードのBツリー索引がパラレルにスキャンされます。順序付きスキャンが要求されると、結果がマージされて表示されます。
表をスキャンする各オプションには独自のコストと利点があり、これらのトレードオフを慎重に検討し、アプリケーション要件と予想されるワークロードについて知っている情報を使用して、モデル化の決定に役立てる必要があります。
- 効率的なレンジ・スキャン - 問合せで値の範囲を制限することはよくありますか。たとえば、アプリケーションで、日付範囲内のすべてのレコードを検索するなどの問合せに回答する必要がある場合、Oracle NoSQL Databaseの2次索引を使用すると、アプリケーションでこれらのタイプの問合せに最も簡単かつ効率的に回答できます。
- ワークロードおよび索引メンテナンスの更新 - 索引メンテナンスのために、書込みで追加のオーバーヘッドが発生することは許容されますか。追加の書込みオーバーヘッドが発生することよりも読取りのレイテンシが重要である場合に、ワークロードで大量の読取りアクティビティが発生しますか。

問合せでの索引の使用に関するガイドラインの詳細は、「SQL問合せのチューニングおよび最適化」を参照してください。

NoSQLデータベースでのトランザクション

Oracle NoSQL Databaseでは、トランザクションは、単一のデータベース操作を伴う論理的でアトミックな作業単位として扱われます。

データベース内のそれぞれのデータ変更は、システムによって管理される1つのトランザクションで実行されます。データベース開発者は、トランザクションの開始/終了の概念がないため、複数の操作を1つのトランザクションにグループ化できません。データベースでは、トランザクション・セマンティクスは、多くの場合、ACIDプロパティによって記述されます。

ACIDプロパティ

Oracle NoSQL Databaseでは、トランザクションにより次のすべてのプロパティが保持され、開発者はそれらの一部を制御できます。

原子性: トランザクション全体が完了または失敗します。中間の状態はなく、部分的なトランザクションはありません。
一貫性: トランザクションはデータベースを有効な状態のままにします。
分離: 2つのトランザクションが互いに混在または干渉しません。2つのトランザクションが順番に実行されても、パラレルに実行されても、開発者にとっては同じ結果になります。
永続性: トランザクションの変更は保存され、変更はあらゆるタイプの障害(ネットワーク、ディスク、CPUまたは電源障害)後も存続します。

開発者は、Oracle NoSQL Databaseダイレクト・ドライバでのアプリケーションのニーズに応じて、幅広い一貫性レベルを定義できます。また、Oracle NoSQL Databaseドライバ(通常はSDKと呼ばれる)では、最終的および絶対的な一貫性もサポートされます。

開発者は、Oracle NoSQL Databaseダイレクト・ドライバを使用して、データベース内の更新された行が失敗しても存続するように、永続性を構成することもできます。永続性はSDKでは構成できません。

原子性および分離は構成できませんが、Oracle NoSQL Databaseでは、アプリケーション・ニーズのためのパフォーマンスをトレードオフするために、一貫性および永続性ポリシーを制御できます。一部のNoSQLデータベースでは、最終的な一貫性のみがサポートされ、絶対的な一貫性のメカニズムはありません。

シャード・キーは、Oracle NoSQLデータベースでACIDプロパティを取得する際に重要な役割を果たします。たとえば、レコード間でシャード・キーを共有すると、1つのアトミック操作で複数の表の行を削除することや、1つのアトミック操作で表の行のサブセットを取得することができます。シャード・キーを適切に設計すると、スケーラビリティが実現されるのみでなく、単一のシャードに対するデータの配置またはデータの取得に必要なサイクル数が減ることで、パフォーマンスを改善できます。

NoSQL表階層は、データの正規化を必要とするが、大規模に予測可能な低レイテンシも必要なアプリケーションにとって、理想的なデータ・モデルです。階層は、異なる表をリンクして左外部結合を有効にし、2つ以上の表の行をそれらの間の関連列に基づいて結合します。親子表の行が同じシャードに配置されるため、このような結合は効率的に実行されます。また、階層の各表に存在するレコードは同じシャード・キーを共有するため、表階層内の複数の表への書込みは、トランザクションACIDプロパティに従います。すべての書込み操作は、単一のアトミックな単位として実行されます。そのため、すべての書込み操作が正常に実行されるか、何も実行されません。

Oracle NoSQL Databaseでの親子表の使用

Oracle NoSQL Databaseでは、表を親子関係にすることができます。これを表階層といいます。

多くのNoSQLデータベースは、配列やマップなどのデータ型をサポートしています。データ関係をモデル化するとき、アプリケーション開発者が、各親行がその子行を、配列内か、ネストされた構造内のマップに格納するようにすると簡単になる考える場合があります。このようにすると、データ関係が非正規化されるのみでなく、親行が大きくなる可能性があり、特に、階層が複雑にネストされている場合は、記憶域が非効率になってパフォーマンスが低下します。Oracle NoSQL Databaseの表階層は、配列およびマップに関連する問題を回避するための理想的なデータ・モデルです。埋込み配列ではなく子表を使用する最大の利点の1つは、書込み操作が高速なワークロードの場合にもたらされます。埋込み配列を使用すると、書込み操作は更新されますが、子表としてモデル化されている場合、これらの操作は挿入になります。ログ構造化された追加専用の記憶域アーキテクチャへの挿入は、更新よりもはるかに適しています。Oracle NoSQL Databaseでデータ関係を構築する場合、表階層の使用を検討する必要があります。

NoSQL表階層は、データの正規化を必要とするが、大規模に予測可能な低レイテンシも必要なアプリケーションにとって、理想的なデータ・モデルです。階層は、異なる表をリンクして左外部結合を有効にし、2つ以上の表の行をそれらの間の関連列に基づいて結合します。親子表の行が同じシャードに配置されるため、このような結合は効率的に実行されます。また、階層の各表に存在するレコードは同じシャード・キーを共有するため、表階層内の複数の表への書込みは、トランザクションACIDプロパティに従います。すべての書込み操作は、単一のアトミックな単位として実行されます。そのため、すべての書込み操作が正常に実行されるか、何も実行されません。

表階層の利点

Oracle NoSQL Database表階層には、次の利点があります。

親子階層にデータを格納する場合の優れた効率性 - 親行と子行が別々のNoSQL表に格納されるため、ネストされた配列またはマップに含めた子が単一の親に伴う場合と比較して、親行のサイズが小さくなります。Oracle NoSQL Databaseの追加専用アーキテクチャの場合、親表または子表に対する書込み操作によって、より小さい行の新しいバージョンが作成され、これらの変更が効率的に格納されます。
読取りおよび書込みワークロードの高いパフォーマンス - 親行と子行は同じローカル・シャードに存在するため、階層内のすべてのレコードについて単一のネットワーク・コールでの読取りまたは書込みが可能となり、書込みおよび読取り操作で高パフォーマンスを実現できます。
ファイングレイン認可のための高い柔軟性 - 親表または子表へのアクセス権限は、実行時の条件に基づいて個別に構成でき、きめ細かく柔軟な認可を提供します。
スケーラブルなACIDトランザクション - 親データと子データを同じシャードに配置することで、スケーラビリティ、低レイテンシおよびACIDの目標を一意に調整します。
表結合 - ネストされた表句または左外部結合を使用して、データを問い合せることができます。

親子表の特性:

子表は、親表の主キー列を継承します。
階層内のすべての表には同じシャード・キー列があり、これらはルート表のCREATE TABLE文に指定されています。
子が削除される前に親表を削除することはできません。
参照整合性制約は、親子表では適用されません。

NoSQL表階層は、データ・エンティティ間の関係を取得するのみでなく、親子行のコロケーションを利用して、高パフォーマンスの取得と優れたスケーラビリティを提供します。表階層を使用すると、アプリケーションでACIDトランザクションを実装できます。同じ親子行のすべてのデータは同じシャードに格納され、原子性、一貫性、分離、永続性を確保するために単一のデータベース操作としてコミットできます。