RDSにて開発を行っておりましたが、VPCでの遅延やコネクション数などの諸事情もある上にビジネス的な要件よりDynamodbに移行が決まりました。
そこでDynamodbについてのawsが発行している文献を読み、テーブル設計をしてある程度運用して一ヶ月くらい経ったのですが、いくつか概念についての質問があります。厳密さを重視というよりは、大まかなイメージ把握をご教示いただければ幸いでございます。
具体的には、wordpressのようなブログサイトのデータ構造をdynamodbに置換したイメージです。
hash key: articleId
sort key: create_at
attribute: category, tagList, authorId, itemId, authorAttributes{}, otherAttributes{}
この中でarticleId, category, tagList, authorId, itemIdが検索に使用するキーです。
今のところ、
- cateogryは事前に組み合わせ(親カテゴリーと小カテゴリーなどの800パターンくらい)があるため、文字列でGSIとしています。
- tagListは別テーブルに保持(tagId(P), counts(S), articlesList{})しておりまして、タグの検索にあたってarticlesListを取得して、戻してaritcleのテーブルにbatchgetを行って複数取得しております。GSIでもLSIでもないです。こちらを参考にしました。
- authorId, itemId はGSIでして、=を使用してgetするのがメインで、普通の使い方です。
##LSIとGSIなどのセカンドインデックスは、tableの中にindexをよしなにハッシュキーないしソートキーにしたようなtableを別に持つイメージでしょうか?
awsのqueryについての文献では、料金について
- インデックスのプロビジョニングされた読み込みキャパシティー
- ベーステーブルのプロビジョニングされた読み込みキャパシティー
と記述されています。例えばdataAを保存する際に、表現がわからないため普通のテーブルのことをメインテーブルと呼ぶと、メインテーブルにももちろん保存され、LSIとしてハッシュキーとソートキーが保存もされる場所、GSIではそこで選択されているattribute達が保存される場所が別に存在するという意味なのでしょうか?
それともそもそも保存形式としてのセカンダリインデックスであり、単にdataAというデータに新規にリレーションデータベースでいうprimary keyのようなものが保存されるという意味合いなのでしょうか?
##そもそもアクセスパターンが多くデータ数も多いためscanを使いたくないと考えている場合、queryを使うとしてGSIを増やすのは得策でしょうか?
今のところGSIを3つ使用しております。これ以上増えることも考えられますし、何よりテーブル設計をもう少し正規化のように綺麗にすることができたらなと思うこと多く、お尋ねしたいです。
具体的には、tagListのように検索するパターン別に(今回では、categoryなど)別途テーブルを用意するのは得策なのでしょうか?
ケースバイケースだと思うのですが、そのケースバイケースにて考慮すべき内容をご教示いただけると幸いでございます。
初めての質問になりまして、正しくないフォーマットでしたら申し訳ございません、
何卒よろしくお願いいたします。
あなたの回答
tips
プレビュー