DynamoDB LSI vs GSI: ユースケースで選ぶセカンダリインデックス完全ガイド
DynamoDBで『このアイテムを注文日でも検索したい』と思った瞬間、テーブル設計を見直す羽目になった経験は少なくないはずだ。プライマリキー以外の属性でクエリを実行したいとき、LSI（ローカルセカンダリインデックス）とGSI（グローバルセカンダリインデックス）のどちらを選ぶかは、後から変更できない制約も絡むため、設計段階での判断が特に重要になる。 TL;DR: LSI vs GSI 早見表 項目 LSI（ローカルセカンダリインデックス） GSI（グローバルセカンダリインデックス） パーティションキー ベーステーブルと同一 任意の属性を指定可能 ソートキー 異なる属性を指定 任意の属性を指定可能（省略可） 作成タイミング テーブル作成時のみ テーブル作成後でも追加可能 整合性モデル 強整合性読み取り可能 結果整合性のみ ストレージ制限 パーティションあたり10GB上限 制限なし（テーブル全体と同様） スループット ベーステーブルと共有 独立したキャパシティ設定が可能 テーブルあたりの上限 最大5個 最大20個（デフォルト） DynamoDB セカンダリインデックスの仕組み DynamoDBのセカンダリインデックスは、ベーステーブルのデータを別のキースキーマで参照できるようにした、内部的には独立したデータ構造だ。インデックスへの書き込みはDynamoDBが自動的に管理する非同期プロセスで、ベーステーブルへの書き込みが成功した後にインデックスへ反映される。LSIの場合はこの反映が同一パーティション内で行われるため強整合性読み取りをサポートできるが、GSIは非同期レプリケーションのため結果整合性のみとなる。 インデックスに射影（Projection）する属性の選択も重要だ。 KEYS_ONLY 、 INCLUDE 、 ALL の3種類があり、射影する属性が多いほどストレージコストと書き込みコストが増加する。クエリで必要な属性だけを射影するのが基本的な最適化方針になる。 sequenceDiagram participant App as アプリケーション...