DynamoDBでLSIを設計するポイントは、GSIとの付き合い方にある！LSIにハマりポイントを解説！😎

想定する読者

• DynamoDB の設計で LSI の貼り付けを悩んでる方
• DynamoDB の開発中に LSI の扱いについて悩んでいる方

はじめに

LSI の制約

• 1 テーブルについて作成可能な LSI は 5 つまで
• LSI を貼り付ける属性数が 5 つを超える場合は物理的に構築不可

DynamoDB の設計でのよくあるアンチパターン（というか設計ミス）は、まず LSI を 5 つ以上貼ってしまった・・というパターンです。

一言で言えば、開発者泣かせな設計ですね笑

これをしてしまうと、恐らくマイグレーションの際にエラーで進まないと思います。

そしてそれを開発者が独断で無視して LSI を貼り付けないなどの対応をした場合は、当然先々で想定する検索が行えない可能性があります。

じゃあ LSI との付き合い方は？

LSI は一方で、「セカンダリインデックスに対して強力な整合性のある読み込みを実現する場合には LSI を利用する必要がある」という面があるので、GSI と上手く併用して扱いたいですね。

私たちは、多くのケースで下記のような採用をしています。他にもユースケースがありそうですが・・。

• ステータス等のフラグ管理を行う属性値は LSI ではなく GSI に設定（掛け合わせで範囲指定を行うケースが多いので）
• updatedAt, CreatedAt あたりには LSI を付与しておく
• ビジネスのユースケースに合わせて貼り付ける

DynamoDB の大原則として、検索要件が定まっていない時の開発はそもそも控えましょう。（OverLoading テクニックなどで工夫して導入するのを検討しましょう）

参考資料

セカンダリインデックスを使用したデータアクセス性の向上 – Amazon DynamoDB

ローカルセカンダリインデックス – Amazon DynamoDB

DynamoDB のグローバルセカンダリインデックスの使用 – Amazon DynamoDB

まとめ

GSI の設計をもとに、LSI の貼り付けは考えましょう。

GSI は上限緩和申請で１テーブル最大２０個の枠を超えて作成することも可能です。

先々 BI ツールと連携するのを見越すなら、基本的に日付での検索を可能にしておくのがベターなので、createdAt, updatedAt には LSI を貼り付けておきましょう。

サーバーレス開発については、お気軽にお問い合わせください。