DynamoDBのLSIとGSIを 改めて整理してみた rinda2001 2024/12

• 自己紹介 • DynamoDBとは（おさらい） • DynamoDBのキー構造 • LSIとGSIの使い分け • 注意しておくこと • まとめ 目次

自己紹介

自己紹介 Akihiro Takamura （rinda2001） @rinda2001 テックリード エス・ビー・エス株式会社（S.B.S. inc.） Amplify / ECS / Codeシリーズ React/Next.js/ReactNativeと戯れる日々 リングフィットアドベンチャー5年生（現在6周目突入） 私生活のアップデートネタが無さすぎて この部分を書くのに大変困ってます

DynamoDBとは（おさらい）

DynamoDBとは • DynamoDBはAWSフルマネージド・サーバーレス なNoSQL Database ‣ NoSQL(Key/Value型）であり≠RDB ‣ フルマネージド・サーバーレス（ゼロスケール可） ‣ 低コスト ‣ 大容量、データ量に依存しない一貫したレイテンシー ‣ 1桁ミリ秒のレイテンシー！ ‣ Amazon Prime Dayでは1秒で1億520万件を処理 ‣ 日本人全員が一気にアクセスしても耐える！ ‣ しかもデータ量・アクセス量で性能が劣化しない（やや誇 張） ‣ クロスリージョンDRも対応できるよ（Global Table） ‣ キャッシュもできるよ（DAX） ‣ ストリーム処理もできるよ（DynamoDB Streams）

DynamoDBとは • その他覚えておくといいこと ‣ リージョナルリソースです ‣ VPCリソースではありません ‣ なのでセキュリティグループとかないです（S3と同じ感じ） ‣ リージョナルリソースです（２回目） ‣ アクセスにはリージョン指定が必要です ‣ 別リージョンのDynamoDBにアクセスするにはクロスリージョンなIAMポリ シーが必要です ‣ アクセスするにはCLIやSDKが必要です ‣ クエリしたい場合とかでも、基本はコードを書く必要があります ‣ スキーマレスです ‣ 後からいくらでもフィールド追加できます ‣ 同じテーブル内で異なるフィールドのレコードを持てます ‣ フィールドの中にJSONを突っ込むこともできます

DynamoDBのユースケース • 向いていないものを知ることが近道 ‣ 一度に大量のトランザクションは❌ ‣ １トランザクションで100アクションが上限 ‣ 柔軟な検索は ❌ ‣ インデックスがないと検索条件にできない ‣ 後からベタベタとインデックスを貼る感じではない ‣ 設計段階で検索用途を整理できるレベルの用途 ‣ JOINは ❌ ‣ マルチテーブル vs シングルテーブル ‣ そもそも設計思想が違うのでRDB脳から切り替えて • 逆に上記を回避できる用途なら積極利用したい

DynamoDBのキー構造 🍎

DynamoDBのキー構造 • 基本のキーは２つ ‣ パーティションキー（過去ハッシュキーと呼ばれていた） ‣ パーティションキー指定で同一のレコード「群」をクエリで きる ‣ 各テーブルに設定が必須 ‣ ≠プライマリキー。重複可能。 ‣ ex)ユーザのアクティビティテーブルならユーザID ‣ ソートキー ‣ パーティションキーと組み合わせてクエリする ‣ 名前の通り並び替えに使うだけでなく、抽出も可能 ‣ ex)ユーザのアクティビティテーブルならdatetime ‣ ※パーティションキー＋ソートキーで一意になるように設計 ‣ そうしないと後から単一行のレコード更新・削除ができない

DynamoDBのキー構造 パーティションキー ソートキー action detail madonna 20240101100101 GET { … } madonna 20240101100103 POST { … } madonna 20240102100105 GET { … } tommyleejones 20240101090124 GET { … } ύʔςΟγϣϯΩʔͰநग़Ͱ͖Δ ˠ̍ճͷ(&5ΞΫγϣϯͰ̏Ϩίʔυ ύʔςΟγϣϯΩʔɾιʔτΩʔΛ૊ Έ߹ΘͤΔͱ ɾNBEPOOBͷͷσʔλͩ ͚औಘ ɾNBEPOOBͷશΞΫςΟϏςΟΛ߱ ॱͰऔಘ ͱ͍ͬͨ͜ͱ͕Ͱ͖Δ ςʔϒϧͷྫ

DynamoDBのキー構造 • キーの制約 ‣ パーティションキーとソートキーはテーブル作成時に指定する必要がある ‣ 一度設定したキーは変更できない ‣ パーティションキーとソートキーはそれぞれ１つのみ ‣ パーティションキーだけ指定、ソートキーなしは可能

DynamoDBのキー構造 パーティションキー ソートキー action detail madonna 20240101100101 GET { … } madonna 20240101100103 POST { … } madonna 20240102100105 GET { … } tommyleejones 20240101090124 GET { … } NBEPOOBͷ(&5ΞΫγϣϯ͚ͩநग़͍ͨ͠৔߹͸ʁ • actionフィールドはパーティションキーでもソートキーでもない ‣ actionフィールドを検索条件にはできない ‣ パーティションキー=madonnaで３件抽出後、filterをすることになる ‣ もしmadonnaのデータが1億件あったら？？

LSIの登場🎉

LSIとは • Local Secondary Index（LSI） ‣ 追加のソートキーと考えればOK ‣ １テーブルにつき最大５つのLSIを作成できる ‣ テーブル作成時のみ作成が可能 ‣ 後から追加はできない！ ‣ ソートキーと同じでパーティションキー＋LSIで検索する パーティションキー ソートキー action detail madonna 20240101100101 GET { … } madonna 20240101100103 POST { … } madonna 20240102100105 GET { … } tommyleejones 20240101090124 GET { … } -4*ʹ͢Δ

さて問題です

次の問題です パーティションキー ソートキー action (LSI) detail madonna 20240101100101 GET { … } madonna 20240101100103 POST { … } madonna 20240102100105 GET { … } tommyleejones 20240101090124 GET { … } ಛఆͷ೔෇ͷɺશϢʔβͷ(&5ΞΫγϣϯ͚ͩ நग़͍ͨ͠৔߹͸Ͳ͏͢Ε͹͍͍ʁ

次の問題です パーティションキー ソートキー action (LSI) detail madonna 20240101100101 GET { … } madonna 20240101100103 POST { … } madonna 20240102100105 GET { … } tommyleejones 20240101090124 GET { … } ಛఆͷ೔෇ͷɺશϢʔβͷ(&5ΞΫγϣϯ͚ͩ நग़͍ͨ͠৔߹͸Ͳ͏͢Ε͹͍͍ʁ நग़৚݅ʹ͸ʮύʔςΟγϣϯΩʔ͕ඞਢʯͳͷͰ ϢʔβΛލͬͯҰؾʹݕࡧ͕Ͱ͖ͳ͍😔

GSIの登場🎉

GSIとは • Global Secondary Index（GSI） ‣ テーブルに設定されているパーティションキー とは異なるパーティションキー・ソートキーを作ることができ る ‣ １テーブルにつき最大２０個のGSIを作成できる ‣ テーブル作成時だけじゃなく後からでも作成が可能 ‣ 内部的にはテーブル更新時に非同期でレプリケートされる感じ で 別のテーブルを作っているイメージ（射影） パーティ ションキー ソート キー actio n detail madonna 20240101 100101 GET { … } madonna 20240101 100103 POS T { … } madonna 20240102 100105 GET { … } tommyleejon es 20240101 090124 GET { … } GSIパーティ ションキー GSIソート キー userid detail GET 20240101 100101 madonna { … } POST 20240101 100103 madonna { … } GET 20240102 100105 madonna { … } GET 20240101 090124 tommyleej ones { … }

LSIとGSIの使い分け

LSIとGSIの使い分け • 基準はパーティションキーを跨ぐかどうか ‣ パーティションキーを跨がない→LSI ‣ パーティションキーを跨ぐ→GSI • 強い整合性読み込みはLSIのみ（GSIは❌） ‣ DynamoDBは基本結果整合性のアクセス ‣ オプションで強い整合性読み込みが可能 ‣ ただしこれはLSIのみ ‣ GSIは非同期でレプリケートされた結果への読み込みなので そもそも結果整合性でのアクセスしかできない

注意すべきポイント

注意すべきポイント • 設計時にクエリパターンを明確化したい ‣ なんといってもLSIはテーブル作成時にしか作れない ‣ 後からLSI欲しくなったら、別テーブルにexport/import ‣ しかもこれが結構厄介（同名❌とか色々と・・・） • DynamoDBは設計にすべてを寄せてる ‣ どういう検索をされるか、をちゃんと整理する ‣ これによりデータの保持方法、インデックスの貼り方が 決定されることで最大パフォーマンスを出せる

まとめ

まとめ • パーティションキー、ソートキー以外でのクエリ が必要な場合はLSIまたはGSIを利用する • LSI・GSIの特性をよく理解して設計段階で検討す る ‣ LSIはテーブル作成時のみ、LSI/GSIともに上限が ある等 • DynamoDBの特性上、後からインデックス変更す るのは大変なのでとにかく設計時の検討が重要 -4*(4*͸ͪΌΜͱཧղͯ͠࢖͑͹0,ʂ บ͸͋Δ͚Ͳͦͷ෼ಘΒΕΔϝϦοτ΋ଟ͍