公開日:2021.11.17

DynamoDB キホンのホン(WEB+DB PRESS vol.125 を読んで)

テクログaws

どうも!

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

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

今回の内容は、タイトル通り「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 にしておいた方が良いということになります。(1ユーザの投稿頻度には限界がある=Hot Keyが発生しづらい)

読み込みオペレーション

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

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

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

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

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

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

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

さいごに

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

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

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

以上、わいでした。

健闘を祈る!!

この記事を書いた人

わい

入社年2019年

出身地大阪

業務内容システム開発

特技または趣味芸人のラジオを聴く、ダイビング

わいの記事一覧へ

テクログに関する記事一覧