DynamoDB設計キャッチアップ

記載するものはすべて引用。
キャッチアップ用

押さえておくべきDynamoDB設計(ベストプラクティス) まとめ

DB設計は必ずアクセスパターン（仕様）が決まってから着手すること
でないとDB設計根本から変更することになる
つまり運用は楽になるかもだけど、開発時に考え抜いて設計要

データはPartition Key(PK)、または PK と Sort Key(SK)の組み合わせで識別される。= Primary Key
テーブル数を少なく設計する。

少ないとキャパシティユニットを最適化できる
関連するデータをまとめとくと応答時間短縮に繋がる。←「参照の局所化」

設計が優れたアプリケーションでは、必要なテーブルは 1 つのみです。

なのでアクセスパターン要件の洗い出しが完了するまでDynamoDB設計に取りかからない

Query対象が増えた時のために１つのGSIに複数の検索要件を持たせる。

より効果的なセカンダリインデックスキーを実現。
クエリを最適化したい場面で効果的。

DynamoDB設計のちょっとした技

DynamoDBのテーブル設計に最適！NoSQL WorkbenchのData modelerで今度こそDynamoDBを使いこなす！

【イチから理解するサーバーレスアプリ開発】サーバーレスアプリケーション向きの DB 設計ベストプラクティス 20190905版

多対多の関係を管理するためのベストプラクティス

より一般的には、DynamoDB のグラフデータ (ノードとエッジ) を表現する方法
最上位エンティティ (グラフモデル内のノードと同義) はすべて、パーティションキーを使用して表現されます
他のエンティティとの関係 (グラフのエッジ) は、ソートキーの値をターゲットエンティティ ID (ターゲットノード) に設定することによって、パーティション内の項目として表現
メリット
- ターゲットエンティティ (ターゲットノードへのエッジを含む) に関連するすべてのエンティティ (ノード) を見つけるために重複データを最小限に抑えられること
- クエリパターンを簡素化できる

DynamoDBで多対多のテーブル設計

上のドキュメントの補足
ユーザーとグループをDynamoDBで実現する例
Adjancy List Design Pattern(隣接リストパターン)
- PK=SK(GSI-PK)=user_idのとき、ユーザーを示す。
- PK=SK(GSI-PK)=group_idのとき、グループを示す。
- PK=user_id, SK(GSI-PK)=group_id のとき、user_idに所属するグループを示す。
  - つまり、group_idに所属するuser_idの数だけ冗長である
クエリが簡単になる
- PK=SK=user_id としてget_itemしたら良い。任意のグループの詳細情報であれば、PK=SK=group_id

DynamoDB でリレーショナルデータをモデル化するための最初のステップ

DynamoDB の場合は答えが必要な質問が分かるまで、スキーマの設計を開始しないでください。ビジネス上の問題とアプリケーションのユースケースを理解することが極めて重要
設計の手順
- 新しいアプリケーションの場合は、アクティビティや目的に関するユーザーストーリーを確認します。特定するさまざまなユースケースを文書化し、必要なアクセスパターンを分析
- 既存のアプリケーションでは、クエリログを分析して、ユーザーが現在どのようにシステムを使用しているか、主要なアクセスパターンを調べます。
本番環境で見つかる可能性のあるクエリパターンの複雑さの範囲を表します