無料ツール

DynamoDB シングルテーブル設計ツール

エンティティと、それをどう読み取る必要があるかを入力してください — プランナーはエンティティ名をプレフィックスにした PK/SK キーテンプレートを提案し、アイテムコレクションをプレビューし、ベーステーブルでパターンを処理できない場合にのみ GSI を追加します。

エンティティ
アクセスパターン
提案されたキースキーマ
エンティティPKSK
UserUSER#<userId>USER#<userId>
Order
User のアイテムコレクション内
USER#<userId>ORDER#<orderDate>#<orderId>
GetItem · ベーステーブルUser を ID で取得
PK = USER#<userId> AND SK = USER#<userId>
Query · ベーステーブルUser の下の Order を一覧
PK = USER#<userId> AND begins_with(SK, 'ORDER#') ScanIndexForward: false
  • ソートキーは文字列として比較されます — ソート属性はソート可能な形式(ISO-8601 の日付、先頭ゼロ埋めの数値)で保存してください。
Query · GSI1User を email で検索
GSI1PK = USER#EMAIL#<email>
  • GSI は一意性を強制しません — 重複は、ベースアイテムへの条件式を使って書き込み時に防いでください。
グローバルセカンダリインデックス
GSI1User アイテムをインデックス化します
GSI1PK = USER#EMAIL#<email> GSI1SK = USER#EMAIL#<email>
  • GSI は一意性を強制しません — 重複は、ベースアイテムへの条件式を使って書き込み時に防いでください。
サンプルアイテム
エンティティPKSKGSI1属性
UserUSER#user-1USER#user-1USER#EMAIL#user-1@example.com USER#EMAIL#user-1@example.comuserId: user-1, email: user-1@example.com
OrderUSER#user-1ORDER#2025-06-01#order-1orderId: order-1, orderDate: 2025-06-01, userId: user-1
OrderUSER#user-1ORDER#2025-06-02#order-2orderId: order-2, orderDate: 2025-06-02, userId: user-1
テーブル定義(CreateTable JSON)
{
  "TableName": "AppTable",
  "BillingMode": "PAY_PER_REQUEST",
  "AttributeDefinitions": [
    {
      "AttributeName": "PK",
      "AttributeType": "S"
    },
    {
      "AttributeName": "SK",
      "AttributeType": "S"
    },
    {
      "AttributeName": "GSI1PK",
      "AttributeType": "S"
    },
    {
      "AttributeName": "GSI1SK",
      "AttributeType": "S"
    }
  ],
  "KeySchema": [
    {
      "AttributeName": "PK",
      "KeyType": "HASH"
    },
    {
      "AttributeName": "SK",
      "KeyType": "RANGE"
    }
  ],
  "GlobalSecondaryIndexes": [
    {
      "IndexName": "GSI1",
      "KeySchema": [
        {
          "AttributeName": "GSI1PK",
          "KeyType": "HASH"
        },
        {
          "AttributeName": "GSI1SK",
          "KeyType": "RANGE"
        }
      ],
      "Projection": {
        "ProjectionType": "ALL"
      }
    }
  ]
}

aws dynamodb create-table --cli-input-json 用のプレーンな JSON — 汎用的な文字列型の PK/SK 属性、ALL 射影の GSI、オンデマンド課金。

コストヒント
アイテムあたりの読み取りユニット(結果整合性)
0.5 RCU
アイテムあたりの書き込みユニット
1 WCU
月額オンデマンド見積もり(us-east-1)— ベーステーブルのみ
$4.93
GSI への書き込みレプリケーションを含む(×1)
$8.21

各 GSI はすべてのアイテムの射影されたコピーを独自に保持するため、テーブルへの 1 回の書き込みは各 GSI でも書き込みキャパシティを消費します。この見積もりは完全射影を前提とし、当社の料金計算ツールおよびアイテムサイズ計算ツールと同じ 4 KB 読み取り / 1 KB 書き込みの丸めを使用します。

アクセスパターンからキースキーマへ

シングルテーブル設計はエンティティではなく読み取りから始まります。テーブルを正規化してクエリ時に結合するのではなく、アプリケーションがデータを取得するあらゆる方法を列挙し — ユーザーを ID で取得、ユーザーの注文を新しい順に一覧、アカウントをメールアドレスで検索 — それぞれが単一の GetItem または Query になるようにキーを形づくります。ベーステーブルで応答できないパターンごとにインデックスが 1 本必要になり、そのトレードオフはテーブルを作成する前に見えているべきです。

このプランナーはそのトレードオフを明示します。標準的なシングルテーブルのルールを決定論的に適用し — エンティティ名をプレフィックスにした複合キー、1 対多パターンにはアイテムコレクション、残りには反転 GSI または属性スコープの GSI — きれいに処理できないパターンについては、取り繕うのではなくその旨を伝えます。サンプルアイテムの表では、結果の行がパーティションの中で実際にどう隣り合って並ぶのかを確認できます。

出力は、汎用的な文字列型のキー属性を持つプレーンな CreateTable JSON ドキュメントです — 後でほどく必要のあるツール固有の要素は一切ありません — さらに、当社の料金計算ツールとアイテムサイズ計算ツールが使うのとまったく同じ 4 KB 読み取り / 1 KB 書き込みの丸めを再利用したコストヒントも付きます。

概念にまだ馴染みがない、あるいはこのアプローチがワークロードに合うか確信が持てませんか? 当社のシングルテーブル設計ガイド では考え方を第一原理から解説しており、 使うべきでないケース では正直な反例を取り上げています。スキーマが固まったら、 DynamoDB クエリビルダーで実際のリクエストを組み立てる か、月額料金の全体は DynamoDB 料金計算ツールで見積もれます.

よくある質問

DynamoDB のシングルテーブル設計とは何ですか?

アプリケーションのすべてのエンティティタイプが、汎用的なパーティションキー・ソートキー属性(PK/SK)を持つ 1 つのテーブルを共有するモデリング手法です。関連するアイテムはパーティションキーを共有するため、単一の Query でまとめて取得できます — 設計を駆動するのは、正規化されたエンティティの形ではなくアクセスパターンです。

このプランナーはどのようにキー設計を決めますか?

固定された公開ルールによって — 生成的にではなく決定論的に決めます。各エンティティはまず、エンティティ名をプレフィックスにしたキーを持つ独自のアイテムコレクションのルートとして始まります。最初の「子を一覧する」パターンで、その子は複合ソートキーに乗って親のパーティションへ移されます。他の属性による検索、2 つ目の親、全件一覧のパターンは GSI の提案になります。そしてルールできれいに処理できないパターンは、でっち上げの設計を受け取るのではなく、未対応としてマークされます。

アクセスパターンにグローバルセカンダリインデックスが必要になるのはどんなときですか?

ベーステーブルのキーレイアウトでは応答できないときです。親のパーティションへ移し替えられた子をその ID で取得する、同じアイテムを 2 つ目の親の下で一覧する、メールアドレスのようなキー以外の属性でアイテムを検索する、あるタイプのアイテムをすべて一覧する、といったケースです。これらはいずれも同じデータにキーを付け直す操作であり、それができるのはインデックスだけです — プランナーはキーの形ごとに 1 つを提案し、同じ形を共有するパターン間で再利用します。

GSI は DynamoDB のコストにどう影響しますか?

各 GSI は対象アイテムの射影されたコピーを独自に保持するため、テーブルへの 1 回の書き込みは、そのアイテムを射影するすべての GSI でも書き込みキャパシティを消費し、ストレージはコピーごとに課金されます。コストカードには、ベーステーブルのみの見積もりと、GSI の書き込みレプリケーションを含めた見積もりが表示されます。計算には、当社の料金計算ツールおよびアイテムサイズ計算ツールと同じ 4 KB 読み取り / 1 KB 書き込みの丸めを使用します。

プランナーは私のデータモデルをどこかにアップロードしますか?

いいえ。このページは静的で、設計はすべてブラウザ内で計算されます — エンティティ名、ID 属性、アクセスパターンがサーバーに届くことはありません。設計がページの外に出る唯一の経路は「リンクをコピー」の URL で、設計をリンクに詰め込むため、共有は常に意図的な行為にとどまります。

Console なしで DynamoDB を扱う

DynoTable は DynamoDB 向けの高速なデスクトップクライアントです — テーブルを閲覧し、SQL スタイルのクエリを実行し、アイテムをローカルで編集できます。