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

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は上限緩和申請で1テーブル最大20個の枠を超えて作成することも可能です。

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