HatenaPocket以前書いた記事の焼き直しになります。PocketsDynamoDBのテーブル設計時に気を付けることhttps://www.blog.danishi.net/2019/08/09/post-2091DynamoDBを使いだして、DynamoDBの仕様やNoSQLへの理解不足ゆえに、あーこれ設計ミスったなーとか、設計段階で考慮すべきだった問題が噴出してきたので、知見をまとめてみます。テーブル設計より先にデータ利用シーンを洗い出すAWSの公式ドキュメントには、次のように書いてあります。設計とは異なる考え方が必要です。場合は、アクセスパターンを考慮せずに正規化されたデータモデルを作成できます。その後、新しい質問とクエリの要件が発生したら、そのデータモデルを拡張することができます。各タイ...あれから何度かDynamoDBを使ってきて、考えなおすところもあったので。SQL一応使える用途によっては無理に1つのテーブルにまとめなくてもいいんじゃない?DynamoDBのテーブルは少ないほどいいというのがAWS公式でもアナウンスされているベストプラクティスですが、是が非でも非正規化して少なくまとめる必要はないんじゃないかというのが私の見解です。理由その1:テーブルの中身が複雑になるテーブルを少なくまとめてファセットを多用すると一目でそのテーブルに何が入っているのか全然わからなくなります。設計案件が増えてきました。これは実装・デバッグ面で足かせになりますし、補助ドキュメントをちゃんとつくらないと何が何だか分からなくなります。私見ですが人が理解しづらいデータ構造はやめた方がいいと思っています。お客さんにわかるように説明するのも一苦労だし。理由その2:LSI・GSIをたくさん張れない最初にユースケースを洗い出すのがDynamoDBの鉄則ですが、そうはいっても往々にして仕様変更でユースケースや検索・ソートしたい箇所が変わることは結構あります。テーブルを多くしておけばそれだけ、1テーブル5つのLSI、20までのGSIの制限が緩くなります。理由その3:キャパシティの見積もりそんなする?テーブルが少なければキャパシティの見積もりが楽になるというのがありますが、オンデマンドモードが入ってからは特に考えずにこれに設定することが多いです。コストが気になるならちゃんと見積もらないといけないとは思いますが。N+1問題もありますが、DynamoDBなら速度でゴリ押せる面も多少はあるので扱うデータの大枠の分類ごとにテーブルを作成するようにして、あんまりファセットを使わなくてもいいように最近はしています。日時で属性を分けなくてもいいこれは以前の記事で分けるよう書いてしまってたので訂正です...。ソートキーに日時属性つけておけば前方一致や範囲検索で日付or日時検索は実現できます。それでも共通のパーティションキーは必要なのであくまで用途次第ですが。集計データはリアルタイムで作成するこれも以前の記事で解がなかったので。ご存じDynamoDBはSQLみたいに集計関数がないため集計が苦手です。冗長データとなってしまいますが集計前のデータが追加・変更・削除された時点で集計後のデータも更新しに行くような作りにしてしまうことで、集計せずともそこを読みに行くだけで集計結果を取るやり方があります。集計結果を持つ場所はファセットや、同じ項目内に集計後の属性を設けておいたり。更新の同期はロジック側で関数化しておくなりして担保しておきましょう。制約がどうしても必要でなければ、単なるリストでなるべく定義するようにしましょう。セット型を使うと単純なJSONへのコンバートができなくなり面倒な場面が多かったです。SQL一応使えるSQL互換のPartiQL(パーティクル)に最近対応しました。SQL互換のクエリ言語「PartiQL」対応を発表https://www.itmedia.co.jp/news/articles/2011/30/news129.htmlAWSがDynamoDBをSQLで操作可能に。SQL互換のクエリ言語「PartiQL」に対応した。米国や東京リージョンなどで利用できる。キーを意識しないとフルスキャンになってしまうらしいので、使いどころは考えないといけないとは思いますが、今まで辛かったデータの調査が少し楽になるかも。こんな感じでデータの検索が可能です。,'score#')私見も大いにありますし、作るシステムの性質次第な気もしますが、一意見として参考になれば。専門知識」の試験対策に。コメントをキャンセルメールアドレスが公開されることはありません。*次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。