Amazon DynamoDB
開発者ガイド (API バージョン 2012-08-10)

DynamoDB でリレーショナルデータをモデル化するためのベストプラクティス

従来のリレーショナルデータベース管理システム (RDBMS) プラットフォームは、正規化されたリレーショナル構造にデータを格納し、階層データ構造を複数のテーブルに格納される共通要素のセットに減らします。次のスキーマは、理論的な製造元の運用およびビジネスのサポートシステムを支える HR スキーマをサポートした一般的な注文エントリアプリケーションの例です。

RDBMS スキーマの例。

RDBMS プラットフォームは、アドホックのクエリ言語 (一般的に SQL のフレーバー) を使用して、アプリケーション層のアクセスパターンをサポートする、正規化されたデータのビューを生成またはマテリアライズします。

たとえば、各項目を出荷するすべてのウェアハウスで在庫数量でソートされた発注書項目のリストを生成するには、前のスキーマに対して次のクエリを発行します。

SELECT * FROM Orders INNER JOIN Order_Items ON Orders.Order_ID = Order_Items.Order_ID INNER JOIN Products ON Products.Product_ID = Order_Items.Product_ID INNER JOIN Inventories ON Products.Product_ID = Inventories.Product_ID ORDER BY Quantity_on_Hand DESC

この種のワンタイムクエリは、データにアクセスするための柔軟な API を提供しますが、大量の処理が必要です。多くの場合、複数の場所からデータを照会するだけでなく、提示する結果を組み立てる必要があります。前述のクエリでは、多数のテーブルにわたって複雑なクエリを行い、結果として出力されるデータをソートして統合します。

RDBMS システムを減速させるもう 1 つの要素として、ACID 準拠のトランザクションフレームワークをサポートする必要がある点があります。ほとんどのオンライントランザクション処理 (OLTP) アプリケーションで使用される階層的なデータ構造は、RDBMS に格納されているときに複数の論理テーブルに分割して分散させる必要があります。そのため、アプリケーションで書き込み中のオブジェクトを読み取ろうとした場合に発生する可能性のある競合状態を回避するためには、ACID 準拠のトランザクションフレームワークが必要です。このようなトランザクションフレームワークは、書き込みプロセスに高いオーバーヘッドが追加されます。

これらの 2 つの要因は、従来の RDBMS プラットフォームをスケーリングするための主な障壁です。分散された RDBMS ソリューションを実現する上で、NewSQL コミュニティが成功を収めるかどうかは現時点では分かりません。しかし、この方法でも以前に説明した 2 つの制限を解決することはできません。ソリューションが提供方法にかかわらず、正規化と ACID トランザクションの処理コストは変わらず重要です。

このため、高トラフィックのクエリに対して低レイテンシーの応答が必要な場合は、NoSQL システムを利用すると、一般的に技術的および経済的な効果がもたらされます。Amazon DynamoDB では、回避することで、リレーショナルシステムのスケーラビリティを制限する問題を解決します。

リレーショナルデータベースシステムは、以下の理由により適切に拡張されません。

  • データを正規化し、複数のクエリを必要とする複数のテーブルに格納して、ディスクに書き込みます。

  • 一般的に、ACID 準拠のトランザクションシステムのパフォーマンスコストが発生します。

  • 高価な結合を使用して、クエリ結果の必要なビューを再構成します。

DynamoDB は、次の理由により適切に拡張されます。

  • スキーマの柔軟性により、DynamoDB は複雑な階層データを 1 つの項目内に格納できます。

  • 複合キー設計では、関連する項目を同じテーブルの範囲内に格納できます。

データストアに対するクエリは、多くの場合次のような形式で、非常に簡単になります。

SELECT * FROM Table_X WHERE Attribute_Y = "somevalue"

DynamoDB は、以前の例の RDBMS と比較して、リクエストされたデータを返す作業がはるかに少なくなっています。