どうも！

ブログ当番の日にちを一日間違えていたわいです！

本日もお付き合いのほどよろしくお願いいたします。

今回の内容は、タイトル通り「WEB+DB PRESS vol.125」の「速習 DynamoDB」を（社内図書で借りて）読んで、自分なりに重要だなと思ったポイントについて書いていきます。

ちなみに、私はサーバサイドエンジニアを自称しておきながら、アプリケーションのコードを書くことしかできないです。

AWSについて全く理解できていないので、内容に誤りがあるかもしれないです。（間違いがあれば便所に流しておいてください。下水処理場で会いましょう）

詳細を知りたくなった方は本家を参照してください。

https://www.amazon.co.jp/WEB-DB-PRESS-Vol-125-PRESS%E7%B7%A8%E9%9B%86%E9%83%A8-ebook/dp/B09JYT6M5M/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=

特徴（RDBMSとの違い）

• 高パフォーマンスで、高スケーラビリティ
• サーバの管理が不要
• NoSQL
• クエリ要件に合わせてテーブル設計を行う

テーブル（Table）

• 項目（Item）：RDBMSでいうレコード（のようなもの）
• 属性（Attribute）：RDBMSでいうカラム（のようなもの）
• プライマリキー：パーティションキー単体の場合、シンプルな主キー。パーティションキーとソートキーの場合、複合主キー
• セカンダリインデックス：プライマリキーに対するクエリに加えて、代替キーを使用して、テーブル内のデータのクエリを行うことができる
• グローバルセカンダリインデックス（GSI）： パーティションキーおよびソートキーを持つインデックス。テーブルのものとは異なる場合がある
• ローカルセカンダリインデックス（LSI）：パーティションキーはテーブルと同じだが、ソートキーが異なるインデックス

パーティション

DynamoDBではパーティションと呼ばれるリソースが集合し、テーブルを構成しています。そして書き込まれたデータがどのパーティションに割り当てられるのかを（ハッシュ計算で）決定するのがパーティションキーです。

パーティションの数は自動でスケールしますが、パーティション一つに対しては以下の制限があります。

• 最大1,000WCU（1KBまでのデータを1秒に1回書き込むと1WCU）までのスループット
• 最大3,000RCU（4KBまでのデータを1秒に1回読み込むと1RCU（結果整合性の場合、0.5RCU））までのスループット
• 10GBまでのストレージ

つまり、同一のパーティションキーにリクエストが集中しすぎて（Hot Key）スロットリングエラーが起こらないようにテーブル設計する必要があります。

読み込みに関しては、キャッシュを使って対応することも可能なので、特に書き込みが集中しすぎないように注意するべきです。

以下のようなチャットシステムの例が載ってあったので、そのまま使わせていただきます。

• comment（コメント）
• time（タイムスタンプ）
• chat_room（チャットルームのID）
• name（ユーザID）

素直に考えると、chat_room をパーティションキーに、time をソートキーにすれば、あとはチャットルームごとに書き込みが時系列で並んでいくので、問題ないように思えます。

しかし、超人気サービスでチャットルームに多くの人がいるとした場合、大量の同時書き込みで先ほどのHot Keyが発生してしまう可能性があります。

こういった場合のことを考慮すると、パーティションキーは name 、ソートキーを time にしておいた方が良いということになります。（１ユーザの投稿頻度には限界がある＝Hot Keyが発生しづらい）

読み込みオペレーション

Filter文を利用して絞り込みを行うことはできますが、これはデータを全部読み取った後に条件にマッチするItemのみを抽出する処理なので消費するRCUの削減にはつながらないことに注意が必要です。

パーティションキーの完全一致とソートキーの条件で絞り込みができたものだけが、データを読み込む前の絞り込みに役立ちます。

先ほどのチャットシステムを例に再び考えてみます。

このままの状態だと、チャットルームごとのコメントを取得することができません。

そこで、GSIを活用します。

GSIで chat_room をパーティションキー、time をソートキーに指定すると、問題は解決できます。

チャットルームごとに完全一致で chat_room の指定ができ、time がソートキーにあるため、Itemのユニーク性も担保されています。

さいごに

「クエリ要件に合わせてテーブル設計を行う」必要性が、なんとなくわかった気がします。

これでDynamoDBについて少しは理解できた気がするので、テーブル設計を見直していきたいですね。

他にも運用・保守に重要なことがたくさん書いてありましたが、ここでは割愛させていただきます。

以上、わいでした。

健闘を祈る！！