← AWSサービスの内部原理 コース
12. LSIは同じパーティションに同居する — ローカルであることの代償
LSI(ローカルセカンダリインデックス)が「本体と同じパーティションに同居する」ことで得られる強整合と、その引き換えに支払う3つの代償を図で追っていきます。
① LSIの3つの決まり — 同じ部屋に置く「もう1冊の索引」
本体テーブルPK: ForumName / SK: Subject
属性に LastPostDateTimeソートキーだけ差し替え(PKは同一)
LSIPK: ForumName(同じ) / SK: LastPostDateTime
本体のSK(Subject)非キー属性として自動投影
- 決まり1: パーティションキーは本体テーブルとまったく同じ
- 決まり2: ソートキーだけ別のスカラ属性に差し替える
- 決まり3: 本体のソートキーは非キー属性として自動投影される
- 本体と同じ部屋(パーティション)の中に置かれた索引。最大5つ/テーブル
LSIはアイテムコレクションの上に「もう1つの並び順」を重ねる仕組みで、パーティションキーは本体と同一、ソートキーだけを別のスカラ属性に差し替える。テーブルあたり最大5つ作れる。
② なぜ同居させるのか — 同期更新と強整合
書き込み
同じサーバー内で同期更新(アトミック)
本体アイテム
LSIエントリ
同じパーティション=同じサーバーだから可能
強整合読み取りConsistentRead=true → 常に最新の値
GSIは不可別サーバー群へ非同期伝搬 → 結果整合のみ
- 1パーティション = 1台の物理サーバー(のレプリカグループ)
- 同じ場所なら同期更新+強整合、分散すれば非同期 — 分散システムの基本トレードオフ
LSIエントリは本体アイテムと同じサーバー(パーティション)にあるため、書き込みを同期的(アトミック)に更新でき、強整合読み取り(ConsistentRead=true)が可能になる。これがGSIとの決定的な違い。
③ 代償1 — アイテムコレクション10GB上限
本体アイテム同じPK値
全LSIのエントリ同じPK値
合計サイズ
アイテムコレクション ≤ 10GB1つのパーティションに収まる必要
超えると
ItemCollectionSizeLimitExceededException追加・サイズ増加が不可に
- サイズを縮める書き込みは引き続き可能
- LSIはCreateTable時にしか作れず、後から追加・削除できない(同居する仕組み上の制約)
LSIが1つでもあると、1つのパーティションキー値あたり「本体アイテム+全LSIエントリの合計」が最大10GBに制限される。LSIのないテーブルやGSIにはこの制限はない。
④ 代償2 — アダプティブキャパシティの分割が効かない
1つのPK値にトラフィック集中ホットパーティション
アダプティブキャパシティの動き
LSIなしテーブル別パーティションへ分割・再配置して回避
LSIありテーブルアイテムコレクションを分割しない
LSIありの帰結
1パーティションの上限に固定3000RCU / 1000WCU
- ソートキーで分割して逸らす逃げ道が閉ざされる
- 強整合の対価として自動分散を放棄している
公式に「LSIがあるテーブルではアイテムコレクションを複数パーティションに分割しない」と明記されている。分割すると局所性と強整合というLSIの存在意義が崩れるためで、ホットなPK値は1パーティションの上限に縛られる。
⑤ 代償3 — 射影外属性の自動フェッチ
LSIへのクエリ
要求属性で分岐
投影済み属性のみインデックスだけ読んで完結
投影外属性を含む本体へ自動フェッチ
フェッチのコスト
レイテンシ増
追加RCU要求属性分ではなくアイテム全体分
- 投影の種類: KEYS_ONLY(キーのみ) / INCLUDE(指定属性) / ALL(全属性)
投影されていない属性をクエリが要求すると、DynamoDBは自動的・透明に本体テーブルへ取りに行く。レイテンシが増えるうえ、本体アイテムごとに「アイテム全体の読み取り分」の追加RCUを消費する。
⑥ まとめ — ローカルであることの代償
同居(データの局所性)同期更新+強整合が可能
引き換えに
収まる場所の上限アイテムコレクション10GB
作成タイミングの固定CreateTable時のみ・追加/削除不可
自動分散の放棄アダプティブキャパシティが分割しない
LSIは同居による同期更新と強整合を得る代わりに、3つの代償を引き受けている。