DynamoDB の GSI vs LSI
グローバルセカンダリインデックス（GSI）もローカルセカンダリインデックス（LSI）も、テーブルのキーではない属性で Query できるようにします。両者は交換可能ではありません — その違いが、どのパターンにどちらが必要かを決めます。
DynamoDB の GSI と LSI の違いは何ですか？
グローバルセカンダリインデックスは 任意のトップレベルスカラー 属性（String、Number、Binary）をパーティションキーとして使え、独自のキャパシティを持ち、いつでも追加できます — ただし結果整合性のある読み取りしか提供しません。ローカルセカンダリインデックスはテーブルと 同じ パーティションキーを異なるソートキーで保ち、強い整合性のある読み取りをサポートし、テーブルのキャパシティを共有しますが、テーブルと同時に作成する必要があります。
効いてくる違い
| GSI | LSI | |
|---|---|---|
| パーティションキー | 任意の スカラー (S/N/B) | テーブルと 同じ |
| ソートキー | 任意のスカラー (S/N/B) | 任意のスカラー (S/N/B) |
| 作成のタイミング | いつでも | テーブル作成時のみ |
| 整合性 | 結果整合性のみ | 強い整合性が利用可能 |
| キャパシティ | 独自 | テーブルと共有 |
| 書き込み伝播 | 非同期（結果整合性） | 同期（アトミック） |
| テーブルあたり最大 | 20（デフォルト、引き上げ可） | 5（ハード上限） |
| 10 GB パーティション上限 | なし | あり（PK ごと） |
経験則
- 異なる が必要（例: 注文を
customerではなくstatusで引く）? なら GSI が必要です — LSI は再パーティションできません。 - 同じパーティション内での 2 つ目のソート順 が必要 — LSI はテーブルの正確なパーティションキーを保ち、異なる ソート キーだけを差し替えます — 前もって決めておき、読み取りが欲しい? なら LSI が合います。
選択は 1 つの問いに収束します — どのキーを変えるのか、です。
異なるパーティションキーは GSI を強制します。同じパーティションで異なるソートキー、これが LSI の合う唯一のケースです。
実際には、ほとんどのチームがほぼ GSI ばかりに手を伸ばします。後から追加でき、独立してスケールし、10 GB のパーティションあたり制限を受けないからです。単一の GSI のキーをオーバーロードして複数のパターンに使いましょう — シングルテーブル設計を参照してください。
Scan を潰すために GSI を追加するなら、それが 独自 の読み取り/書き込みキャパシティを持つことを忘れないでください。その追加コストは料金計算ツールで見積もり、コミットする前に DynoTable を試してインデックスの射影された属性を調べてください。