DynamoDB でリレーショナルデータをモデル化する例

この例では、Amazon DynamoDB でリレーショナルデータをモデル化する方法について説明します。DynamoDB テーブルの設計は、「リレーショナルモデル化」に示されているリレーショナルオーダーのエントリスキーマに対応しています。この設計では、単一の隣接リストではなく複数の特殊なテーブルを使用し、戦略的 GSI を活用してすべてのアクセスパターンを効率的に処理しながら、明確な運用上の境界を提供します。

設計アプローチでは、集約指向の原則を使用し、厳格なエンティティ境界ではなくアクセスパターンに基づいてデータをグループ化します。主な設計上の決定事項には、アクセス相関が低いエンティティに個別のテーブルを使用すること、常に一緒にアクセスされる場合に関連データを埋め込むこと、関係を特定するための項目コレクションを使用することが含まれます。

次のテーブルとそれに付随するインデックスは、リレーショナルオーダーのエントリスキーマをサポートしています。

従業員テーブルの設計

従業員テーブルには、従業員情報が項目ごとに 1 つのエンティティとして保存され、従業員を直接検索できるように最適化し、戦略的 GSI を通じて複数のクエリパターンがサポートされます。このテーブルは、独立した運用特性を持ち、エンティティ間のアクセス相関が低いエンティティに対して個別のテーブルを設計する原則を示しています。

このテーブルでは、各従業員が個別のエンティティであるため、ソートキーなしでシンプルなパーティションキー (employee_id) を使用します。4 つの GSI により、さまざまな属性による効率的なクエリが可能になります。

顧客テーブルの設計

顧客テーブルは、Account_rep_id を戦略的に非正規化して顧客情報を維持し、アカウント担当者のクエリを効率的に実行できるようにします。この設計の選択により、わずかなストレージオーバーヘッドと引き換えにクエリパフォーマンスが向上し、顧客データとアカウント担当者データの結合が不要になります。

このテーブルは、リスト属性を使用して顧客ごとに複数の電話番号をサポートしており、DynamoDB のスキーマの柔軟性を示しています。単一の GSI により、アカウント担当者のワークフローが有効になります。

注文テーブルの設計

注文テーブルは、注文ヘッダーと注文項目に個別の項目を含む垂直パーティショニングを使用します。この設計により、すべての注文コンポーネントを同じパーティション内に維持しながら、効率的な製品ベースのクエリが可能になり、効率的にアクセスできるようになります。各注文は複数の項目で構成されます。

このテーブルには、顧客検索を必要とせずに直接アカウント担当者クエリを有効にするための account_rep_id (顧客テーブルから複製) の戦略的な非正規化が含まれています。高スループットの書き込みシナリオの場合、OPEN の注文には、複数のパーティションにわたる書き込みシャーディングを有効にするためのステータスとシャード属性が含まれます。

4 つの GSI は、最適化された射影を使用してさまざまなクエリパターンをサポートします。

製品テーブルの設計

製品テーブルは、項目コレクションパターンを使用して、製品メタデータと在庫データの両方を同じパーティション内に保存します。この設計では、製品と在庫間の識別関係を活用します。親製品がないと在庫は存在できません。製品メタデータに SK=product_id を、在庫項目に SK=warehouse_id を使用し、PK=product_id を設定すると、個別の在庫テーブルと GSI が不要になり、コストが約 50% 削減されます。

このパターンにより、個々の倉庫在庫 (複合キーを持つ GetItem) と製品のすべての倉庫在庫 (パーティションキーに対するクエリ) の両方に対する効率的なクエリが可能になります。製品メタデータ項目の total_inventory 属性は、合計在庫数をすばやく検索するための非正規化集計を提供します。

各テーブルは、必要なアクセスパターンを効率的にサポートするように、特定のグローバルセカンダリインデックス (GSI) で設計されています。この設計では、戦略的な非正規化とスパースインデックス作成を備えた集約指向の原則を使用して、パフォーマンスとコストの両方を最適化します。

主要な設計の最適化には以下が含まれます。

最後に、前に定義したアクセスパターンを再度使用することができます。次のテーブルは、戦略的 GSIs を備えたマルチテーブル設計を使用して、各アクセスパターンを効率的にサポートする方法を示しています。各パターンは、直接キー検索または単一の GSI クエリのいずれかを使用するため、コストのかかるスキャンを回避し、あらゆる規模で一貫したパフォーマンスを提供します。