内部

テーブルがスロットルするのに CloudWatch の平均使用率は 50% 未満で、アダプティブ キャパシティは魔法の修正のように聞こえるが、1 つのパーティションキーが依然として 不釣り合いなトラフィックを吸収する。物理パーティションのメンタルモデルなしでは、 それらの振る舞いはランダムに見える。

このセクションは深い側だ。パーティションキーがストレージ分割へどうハッシュするか、 GSI がどう別のパーティション化された構造か、リクエストルーターがどうエンドポイントを 選ぶか、そして今日の DynamoDB がどこで元の Dynamo 論文と韻を踏むか。モデリングと インデックスが腹に落ちたあとに読む — 前のセクションが渡したルールを説明する。

読み終えたらできること

• ハッシュ分布とアイテムコレクションサイズからホットキー症状を予測できる。
• なぜ GSI がベーステーブルに遅れ、自分の GSI 書き込みを強整合で読めないかを 説明できる。
• アダプティブキャパシティを、1 キー上の無制限バーストではなく再配分として 説明できる。
• パーティション分割とストレージ配置を、なぜ Query が 1 つのハッシュキーに 局所的に留まるかに結びつけられる。

読む順番

1. パーティションキーの仕組み — ハッシュキーからパーティション割り当てへ。スループット分離の単位。
2. アダプティブキャパシティ — パーティション横断でのキャパシティ借用。持続する偏りでの限界。
3. GSI の内部 — 別パーティション、非同期伝播、 インデックスアイテムあたりのストレージオーバーヘッド。
4. 物理パーティション — コレクションが 成長するときの分割。文脈の中での 10 GB LSI コレクション上限。
5. ストレージの内部 — パーティション内の b-tree 風の局所順序。「ソートキーでソート」がディスク上で意味すること。
6. リクエストルーティング — エンドポイント、 DNS、クライアントがバックオフ付きでスロットルをリトライすべき理由。
7. Dynamo 論文から DynamoDB へ — 歴史的な 系譜。どの約束がマネージドサービスまで生き残ったか。

パーティションキー値は一度に 1 つのハッシュスロットへマップされ、そのハッシュキーを 共有するすべてのアイテムは、分割が起きるまで 1 つのアイテムコレクションに住む。 毎秒 10,000 イベントを PK = TENANT#acme へ書くと、テーブルに何千もの物理 パーティションがあっても、WRU は一握りの物理パーティションに集中する。アダプティブ キャパシティは静かなパーティションから余剰を移せるが、1 キー上の持続する偏りは それでも勝つ。

GSI の伝播は非同期 — AWS によれば通常条件では通常 1 秒未満 — で、インデックス上に ConsistentRead の逃げ道はない。

ワークベンチで練習する

DynoTable をダウンロードし、偏っていると分かっているテーブルで 設定 を開く。重いテナントパーティションと静かなものへの Query で、 キー構造とパーティションあたりのアイテム数を比べる。

SQL Workbench では、境界づけられた Scan または Query 結果の上でパーティション キー（または SQL で抽出した接頭辞）を GROUP BY し、画面上でどのキーが最も多くの アイテムを運ぶかを見る。その集約は取得済み行に対してクライアント側で走る — テーブルを無料でスキャンはしない。

アイテムサイズ計算機 は、大きなアイテムコレクションが なぜ分割閾値に近づくかを説明するのに役立つ。DynoTable は CloudWatch メトリクスや パーティションヒートマップを露出しない。フリート全体の熱には AWS のオブザーバビリティを、 見えているものの背後のモデルにはカリキュラムを使う。

GSI の書き込み増幅と結果整合がすでに馴染みになるよう、インデックス のあとに内部を読む。