1. まず結論 ― どう切り分けるか
| 判断ポイント | LSI が向くケース | GSI が向くケース |
|---|---|---|
| パーティションキー | ベーステーブルと同じ | ベーステーブルと異なるキーが欲しい |
| 定義タイミング | テーブル作成時のみ | 作成後でも追加・削除できる |
| 一貫性 | 強整合 クエリ可 | 最終的整合 のみ (※ 2025‑04 時点) |
| サイズ上限 | 同一 PK 内で 10 GB | テーブル全体と同じ上限まで |
| スループット課金 | テーブルと共有 | インデックス専用に課金枠が増える |
| 典型用途 | 「同じ PK 内で別の並び順・絞り込み」 | 「横断検索」「逆方向の参照」 |
2. JIRA 風「課題管理」テーブル設計例
| 属性名 (型) | 説明 | 例 |
|---|---|---|
| PK ProjectKey (S) | プロジェクト識別子 | PRJ |
| SK IssueNo (N) | 連番 (1001, 1002 …) | 1001 |
| Title (S) | 件名 | “ログイン失敗時に 500” |
| Status (S) | OPEN / IN_PROGRESS / … | |
| Assignee (S) | 担当者 ID | alice |
| Priority (N) | 1=Blocker … 5=Trivial | |
| UpdatedAt (N, epoch) | 更新日時 | 1713400000 |
2‑A. LSI: Status-UpdatedAt-index
- 同じ ProjectKey を持つ課題を
Status（＝新しいソートキー列）で絞り、UpdatedAtで並び替えて取り出す - 例: 「PRJ の
OPENな課題を更新日時降順で 20 件」
bash
aws dynamodb query \ --table-name Issues \ --index-name Status-UpdatedAt-index \ --key-condition-expression 'ProjectKey = :p and Status = :s' \ --expression-attribute-values '{":p":{"S":"PRJ"},":s":{"S":"OPEN"}}' \ --scan-index-forward false \ --limit 20
✔ なぜ LSI?
同一プロジェクト内 (＝同じ PK) で並び順とフィルタ条件だけを変えたいから。
強整合で “今まさに更新された課題” を即座に見たい運用にも向く。
2‑B. GSI①: Assignee-UpdatedAt-index
- どのプロジェクトにも跨って 自分に割り当てられた課題を時系列で一覧
- PK＝
Assignee, SK＝UpdatedAt
bash
aws dynamodb query \ --table-name Issues \ --index-name Assignee-UpdatedAt-index \ --key-condition-expression 'Assignee = :u' \ --expression-attribute-values '{":u":{"S":"alice"}}' \ --scan-index-forward false
✔ なぜ GSI?
複数プロジェクトを横断しなければならないため、
ベーステーブルとは 異なる PK が必要。
2‑C. GSI②: Priority-index （パーティションキーのみ）
- 全課題を優先度で絞る “緊急ボード” 用
- PK＝
Priority、SK なし（単一テーブルを擬似的に 5 つにシャーディング）
3. 使い分け早見チャート
- 同じパーティション内の “並び替え／小絞り込み” だけ？ → LSI
- 別パーティションキーで横断検索したい？ → GSI
- 後から要件が変わりそう？ → 追加・削除が容易な GSI を検討
- 直後に結果の完全性が必須？ → 強整合が取れる LSI が候補
- PK 内が 10 GB を超える可能性？ → LSI は不可、GSI
4. コスト・運用の注意
| 項目 | LSI | GSI |
|---|---|---|
| RCU/WCU 消費 | テーブルと共通枠 | インデックスごとに追加で発生 |
| TTL / ストレージ課金 | テーブルに比例 | インデックスにも複製分が課金 |
| 再設計の痛み | 作り直し必須 | 追加・削除で可 |
| 整合性選択 | 強/最終を選択可 | 最終のみ |
5. まとめ
- LSI は「同じ箱の中を別の順序で見る引き出し」。
‑ 例: プロジェクト単位で状態・更新日順に閲覧 - GSI は「まったく別のラベルで並べ直したコピー」。
‑ 例: 担当者や優先度ごとに全プロジェクトから横断検索 この基準を覚えておくと、JIRA 風アプリの検索要件が増えても “どの視点が必要か” を言語化しやすくなり、スキーマ設計の段階で迷いません。