Oracle NoSQL Databaseにおけるスキーマの柔軟性
スキーマが純粋に固定されたリレーショナル・データベースの世界とは異なり、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での親子表の使用」を参照してください。
JSONコレクション表:
Oracle NoSQL Databaseでは、JSONコレクション表がサポートされています。これは、ドキュメントとしてのみデータを格納および取得するアプリケーションに特に役立ちます。このような表には、主キー・フィールドとドキュメントが含まれます。JSONコレクション表のスキーマを変更して型付きフィールドを追加することはできません。JSONコレクション表は、ドキュメントの管理と操作を簡素化するために作成されます。JSONコレクション表を使用すると、表の作成時にフィールドをJSON型として宣言する必要がなくなります。表にデータを挿入すると、各行は任意の数のJSONフィールドを含む単一のドキュメントとして挿入されます。JSONフィールドは、INSERTまたはUPSERT操作を介して追加できます。