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

DynamoDB でリレーショナルデータをモデル化するための最初のステップ

重要

NoSQL 設計では、RDBMS 設計とは異なる考え方が必要です。RDBMS の場合は、アクセスパターンを考慮せずに正規化されたデータモデルを作成できます。その後、新しい質問とクエリの要件が発生したら、そのデータモデルを拡張することができます。DynamoDB の場合は対照的に、答えが必要な質問が分かるまで、スキーマの設計を開始しないでください。ビジネス上の問題とアプリケーションのユースケースを理解することが極めて重要です。

効率的に拡張する DynamoDB テーブルの設計を開始するには、サポートする必要のあるオペレーションおよびビジネスサポートシステム (OSS/BSS) で必要とされるアクセスパターンを特定するために、まずいくつかの手順を実行する必要があります。

  • 新しいアプリケーションの場合は、アクティビティや目的に関するユーザーストーリーを確認します。特定するさまざまなユースケースを文書化し、必要なアクセスパターンを分析します。

  • 既存のアプリケーションでは、クエリログを分析して、ユーザーが現在どのようにシステムを使用しているか、主要なアクセスパターンを調べます。

このプロセスが完了したら、次のようなリストが表示されます。

主要なアクセスパターンのリスト (ID による従業員の詳細の検索、従業員の名前によるクエリ、顧客の電話番号の検索などの項目)。

実際のアプリケーションでは、リストはさらに長くなる場合があります。しかし、このコレクションは、本番環境で見つかる可能性のあるクエリパターンの複雑さの範囲を表します。

DynamoDB スキーマ設計の一般的なアプローチとして、アプリケーションレイヤーエンティティを識別し、非正規化と複合キー集約を使用してクエリの複雑さを軽減します。

DynamoDB では、複合ソートキー、過負荷になっているグローバルセカンダリインデックス、パーティションテーブル/インデックス、その他のデザインパターンを使用することを意味します。これらの要素を使用してデータを構造化することで、アプリケーションは、テーブルまたはインデックスの単一のクエリを使用して、特定のアクセスパターンに必要なものを取得できます。リレーショナルモデル化 に示されている正規化されたスキーマをモデル化するために使用できる主なパターンは、隣接関係リストのパターンです。この設計で使用されるその他のパタ​​ーンには、グローバルセカンダリインデックスの書き込みシャーディング、グローバルセカンダリインデックスのオーバーロード、複合キー、マテリアライズされた集計があります。

重要

一般的に、DynamoDB アプリケーションではできるだけ少ないテーブルを維持する必要があります。設計が優れたアプリケーションでは、必要なテーブルは 1 つのみです。例外として、大容量の時系列データが必要な場合や、データセットのアクセスパターンが非常に異なる場合などがあります。反転されたインデックスを含む単一のテーブルでは通常、シンプルなクエリを使用してアプリケーションで必要とされる複雑な階層データ構造を作成および取得できます。