DynamoDB でリレーショナルデータをモデル化するための最初のステップ
注記
NoSQL 設計では、RDBMS 設計とは異なる考え方が必要です。RDBMS の場合は、アクセスパターンを考慮せずに正規化されたデータモデルを作成できます。その後、新しい課題とクエリの要件が発生したら、そのデータモデルを拡張することができます。対照的に、Amazon DynamoDB の場合は答えが必要な質問が分かるまで、スキーマの設計を開始しないでください。ビジネス上の問題とアプリケーションのユースケースを理解することが極めて重要です。
効率的に拡張する DynamoDB テーブルの設計を開始するには、サポートする必要のあるオペレーションおよびビジネスサポートシステム (OSS/BSS) で必要とされるアクセスパターンを特定するために、まずいくつかの手順を実行する必要があります。
新しいアプリケーションの場合は、アクティビティや目的に関するユーザーストーリーを確認します。特定するさまざまなユースケースを文書化し、必要なアクセスパターンを分析します。
既存のアプリケーションでは、クエリログを分析して、ユーザーが現在どのようにシステムを使用しているか、主要なアクセスパターンを調べます。
このプロセスが完了したら、次のようなリストが表示されます。
| パターン # | アクセスパターンの説明 |
|---|---|
| 1 | 従業員 ID で従業員の詳細を検索する |
| 2 | 従業員名で従業員の詳細をクエリする |
| 3 | 従業員の電話番号を検索する (複数可) |
| 4 | 顧客の電話番号を検索する (複数可) |
| 5 | 日付範囲内の顧客の注文を取得する |
| 6 | 日付範囲内のすべての OPEN の注文を表示する |
| 7 | 最近雇用したすべての従業員を確認する |
| 8 | 倉庫のすべての従業員を検索する |
| 9 | 製品の注文中のすべての項目を取得する |
| 10 | すべての倉庫の製品在庫を取得する |
| 11 | アカウント担当者別に顧客を取得する |
| 12 | アカウント担当者別に注文を取得する |
| 13 | 役職を持つ従業員を取得する |
| 14 | 商品および倉庫別に在庫を取得する |
| 15 | 商品在庫総数を取得する |
実際のアプリケーションでは、リストはさらに長くなる場合があります。しかし、このコレクションは、本番環境で見つかる可能性のあるクエリパターンの複雑さの範囲を表します。
DynamoDB スキーマ設計の最新のアプローチでは、集約指向の原則を使用し、厳格なエンティティの境界ではなくアクセスパターンに基づいてデータをグループ化します。このアプローチでは、複数の設計パターンを考慮します。
単一テーブル設計 - 複合ソートキー、オーバーロードされたグローバルセカンダリインデックス、隣接リストパターンを使用して、複数のエンティティタイプを 1 つのテーブルに保存します
マルチテーブル設計 - 独立した運用特性を持ち、アクセス相関が低いエンティティに個別のテーブルを使用し、エンティティ間のクエリには戦略的な GSI を使用します
集約設計 - 常に一緒にアクセスされる場合に関連するデータを埋め込む (Order + OrderItems)、または関係を識別するために項目コレクションを使用します (Product + Inventory)
これらのアプローチの選択は、特定のアクセスパターン、データ特性、運用要件によって異なります。これらの要素を使用してデータを構造化することで、アプリケーションは、テーブルまたはインデックスの単一のクエリを使用して、特定のアクセスパターンに必要なものを取得できます。
注記
単一テーブル設計とマルチテーブル設計の選択は、特定の要件によって異なります。単一テーブル設計は、エンティティのアクセス相関性が高く、運用特性が類似している場合に適しています。エンティティに独立した運用要件や異なるアクセスパターンがある場合、または明確な運用上の境界が必要な場合は、マルチテーブル設計が推奨されます。このガイドの例では、戦略的集約と非正規化によるマルチテーブルアプローチを示しています。
NoSQL Workbench for DynamoDB を使用してパーティションキー設計を視覚化する方法については、「NoSQL Workbench を使用したデータモデルの構築」を参照してください。
