【要約】最近のDynamoDB設計事情：single-table偏重の見直しとGSIマルチ属性キー [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
DynamoDBで複雑な検索を実現しようとする開発者が、GSIの制約により「合成キー」の管理という重い負担を強いられていた。
従来のGSIは1属性しかキーに持てなかったため、以下の問題が発生していた。
従来のGSIは1属性しかキーに持てなかったため、以下の問題が発生していた。
- ・属性の連結による型情報の喪失: 数値型のcreatedAtを連結すると文字列になり、正確な範囲検索が困難になる。
- ・クエリ可能性の固定: 連結順序（例: type#status#date）が固定されるため、順序を変えた検索ができない。
- ・実装と運用の複雑化: 検索用にアプリ側で連結キーを生成する必要があり、GSI追加時のデータ移行（バックフィル）も手間となる。
// Approach
AWSが導入したGSIマルチ属性キーを活用し、ドメイン境界に基づいた柔軟なテーブル設計を採用する。
具体的には、以下の手法で設計の複雑性を解消する。
具体的には、以下の手法で設計の複雑性を解消する。
- ・マルチ属性キーによる直接指定: 連結キーを作らず、複数の属性をそのままGSIのキーとして定義する。
- ・ドメイン単位のテーブル分割: 関連性の高いエンティティは1つのテーブルにまとめ、ドメイン境界でテーブルを分ける。
- ・ソートキーの階層的利用: 絞り込みたい属性をソートキーに並べ、最右端の属性で範囲検索を行う設計を徹底する。
// Result
設計者が技術的制約ではなく、ワークロードやチーム構成に基づいて最適な設計を選択できるようになった。
新機能の導入により、以下の成果が得られる。
新機能の導入により、以下の成果が得られる。
- ・開発体験の向上: アプリ側での合成キー生成コードが不要になり、実装がシンプルになる。
- ・検索精度の維持: 数値型のまま保持できるため、createdAtなどを用いた正確な範囲検索が可能になる。
- ・運用の柔軟性: 既存の属性をそのまま使えるため、新しい検索要件に対するGSIの追加コストが大幅に低下する。
Senior Engineer Insight
> 本記事の指摘通り、Single-tableの「職人芸」は、設計の柔軟性を犠牲にしたトレードオフであった。GSIマルチ属性キーは、そのトレードオフの境界線を大きく動かした。特に、数値型の保持とGSI追加コストの低減は、運用の機敏性を高める。ただし、ソートキーの評価順序が固定される制約は依然として残る。現場では「ドメイン内でまとめる」という2階層の設計思想を軸に、アクセスパターンの変化を許容できる設計を標準とすべきだ。