DynamoDB をもっと深く知りたい -- パーティション編
yukiBlack Belt を読んでいく！
yukiかなり飛ばすけどパーティションが今回一番勉強したいところだったのでメモ。
- プロビジョンされたスループットを確保するためにテーブルを複数のパーティションに分散して格納している。
- Partition Key をパーティション間でデータ分散に使用する。
- Partition Key は偏りが出ないように設計しないと性能が出なくなってくるので、設計には注意が必要になる。ホットパーティション問題とかいう名前がついてたかな？
パーティショニング数の算出方法（このスライドが書かれた時点の情報の可能性はありそう）
- 読み込みキャパシティユニット / 3000 RCU + 書き込みキャパシティユニット / 1000 WCU
- 単一のパーティションには約10GB確保されるので、テーブルサイズ (GB) / 10 GB
- 1, 2 の大きい方を取る。
詳しいところはスライド p.38 - p.40 に記載がある。
yukiキャパシティ変更時には各パーティションのキャパシティが減ることになる。なので、減った後はしばらくひとつひとつのパーティションのキャパシティが低い状態になり、結果としてキャパシティエラーを引き起こしやすくなる。
yukiBurst Capacity というものがあり、パーティションごとのキャパシティのうち、利用されなかった分を300秒分（5分間）保持しておいてくれる。なので、直前までまずまずあまりがある状態であれば、キャパシティを超過したトラフィック（Burst Traffic）をその分で処理することができるみたい。
yuki全然関係ないんだけど、パーティションキーのベストプラクティス読もうとしたらこんなページがあって、
- Compressing Large Attribute Values: たとえば掲示板のメッセージ部分のように、長文が期待されるテキストは gzip なんかにまとめて
Binaryという Attribute Type を使えばいいよ。 - Storing Large Attribute Values in Amazon S3: Attribute Value を S3 に保存しておくこともできるよ。その際は、オブジェクトキーかS3のリンクを入れておく。DynamoDB と S3 のデータの間のトランザクションは担保できないから、どっちかの保存が失敗すると孤児化するので注意が必要だよ。
あまりそのような長文データなどは保存したことがないけれど、頭の片隅に置いておきたいと思った。
yukiパーティションキーのベストプラクティスを読んでいく！前から結構気になってた
Designing Partition Keys to Distribute Your Workload Evenly
というページを軽く見ると、どういったパーティションキーがよさそうかが書いてある！
見ていて気になったのは、
Device ID, where each device accesses data at relatively similar intervals.
Device ID, where even if there are many devices being tracked, one is by far more popular than all the others.
このふたつで、実は今業務で関わっているプロダクトでは下に該当するｗ
これは Bad らしい。ちょっと考えてみたらそうかも。アクセスが偏るっていうことだから、その分ホットパーティションが発生しやすそうに思う。
DynamoDB に直接読み込みをかけた場合の話だと思うから、キャッシュとかを噛ませてパーティションキーへのアクセス頻度を平坦化したらまた状況は変わってきそうではある。
各パーティションキーへのおおよそのアクセス頻度や、アクセスがよっているパーティションキーの統計をとったりする機能はあるんだろうか🤔 ないとわりとチューニングが難しそう……
yukiDistributing Write Activity Efficiency During Data Upload
ソートキーを使って一度並べ直してからインポートすると、書き込み時のスループットが向上する。DynamoDB に負荷を書けながら保存できる。理由はソートキーでソートしてブロックを作って入れるようにすると、パーティションキーを分散した状態で保存処理をかけられるからだと思う。スループットはパーティションキーごとに設定されているので、それらを同時並行的に動かせるのだと思われる。
これは DynamoDB の原理を考えるとそれはそうだなあと思える話だけど、全然知らなかった。batch write にも適用されるのかな。
yukiたとえば日付をパーティションキーにした場合には、2020-11-25.1, 2020-11-25.2, 2020-11-25.200 みたいにサフィックスをつけるとよい。
パーティションキーを 2020-11-25 で絞る際には、Query の beginWith で絞り込みをかけてあげればアクセスが可能だったはず。こうすることで、事実上同じパーティションキーを元にパーティションを分散させることができる。
yuki一旦パーティション周りはわかったのでクローズ！次は時間あるときにデータモデリングをいくつか勉強したい。