鍵5万種を混ぜて置き場所に振りました。8個に分けると、いちばん多い場所は15.98%です。
512個に増やしても5.10%までしか下がりません。均等なら0.20%のはずで、26.1倍の開きです。
あとから条件を足して探す形ではありません。鍵の設計が、その後の性能をほぼ決めます。
DynamoDBの鍵には2つの形があります。ドキュメントはこう定めています。
DynamoDBの表の各項目を一意に定める主鍵は、単純な形（置き場所を決める鍵のみ）か、複合の形（置き場所を決める鍵と並べ替えの鍵の組み合わせ）のいずれかであるという記述です。
重要なのは前半です。置き場所を決める鍵が、データの居場所を決めます。
1番目が、条件で探せる仕組みとの大きな違いです。PostgreSQLの記事で扱った「あとから索引を足す」形は取れません。
だから読み方を先に洗い出すことになります。読み方が決まらないうちは、鍵も決まりません。
ドキュメントは設計の目標も示しています。表とその二次索引にわたって、すべての置き場所を決める鍵で均一な活動になるよう、応用を設計すべきであるという記述です。
「均一な活動」がどこまで実現できるかを、次の節で数えます。
The primary key that uniquely identifies each item in an Amazon DynamoDB table can be simple (a partition key only) or composite (a partition key combined with a sort key).原文AWS ドキュメント「Best practices for designing and using partition keys effectively in DynamoDB」 この内容の有効期限2027-02-18
混ぜて振り分けても、同じ鍵は同じ場所へ行きます。鍵そのものの偏りは消えません。
DynamoDBのドキュメントは均一な活動を勧めています。実際にどこまで均されるかを数えました。
鍵5万種を50万回引きます。鍵は混ぜてから置き場所に振り分けますので、鍵の並びによる偏りは消えています。
鍵 50,000種・引く回数 500,000回 鍵を混ぜて置き場所を決める。置き場所の数を変えて、いちばん多い置き場所の割合を見る 置き場所の数 均等なら よく引かれる鍵がある場合 均される場合 最大と均等の比 8個 12.50% 15.98% 12.60% 1.3倍 32個 3.13% 7.46% 3.18% 2.4倍 128個 0.78% 5.52% 0.82% 7.1倍 512個 0.20% 5.10% 0.22% 26.1倍
右から2列目を見てください。引かれ方が均される場合は、ほぼ均等な値に収まっています。
その左が本題です。よく引かれる鍵がある場合、512個に分けても5.10%で止まります。
右端の列は逆を向いています。8個では1.3倍だった比が、512個では26.1倍になります。
均等の値だけが下がるためです。いちばん多い場所は、いちばん多い鍵の分だけ下がりません。
つまり分けても直りません。混ぜてから振り分けているので、並びの問題ではないことも分かります。
直すには鍵そのものを分けます。1つの鍵に接尾辞を足して複数に散らすやり方で、読むときは散らした分を合わせます。
均される場合はほぼ均等。偏りがある場合だけ下がらない。
You should design your application for uniform activity across all partition keys in the table and its secondary indexes.原文AWS ドキュメント「Best practices for designing and using partition keys effectively in DynamoDB」 この内容の有効期限2027-02-18
全体に余裕があっても、1つの置き場所が上限に当たれば、そこだけが詰まります。
DynamoDBの上限は、置き場所ごとに定められています。ドキュメントは数値を明記しています。
DynamoDBの表のすべての置き場所は、毎秒3000の読みの単位と、毎秒1000の書きの単位という最大の能力を届けるよう設計されているという記述です。
前の計測と合わせると、集中が上限にどう効くかが見えます。
512個に分けた場合、全体の上限は読みで毎秒153万です。ところが1つの場所は3000で頭打ちになります。
いちばん多い場所が5.10%を受けるなら、全体が毎秒5万9千に届いた時点で、その場所が3000に当たります。全体の上限の3.8%です。
均される場合は0.22%なので、全体が毎秒136万まで伸びてから当たります。23倍の違いです。
全体の使用量だけを見ていると、この詰まりは見えません。置き場所ごとの偏りを先に数えることになります。
似た構図は、要求の集中を扱う場面で繰り返し出てきます。平均が隠す上位の話はMongoDBの記事でも数えました。
偏りを先に数えてから、置き場所の数を決める。
引かれ方の偏りは式で作ったもので、実在の分布ではありません。偏りが弱ければ均される側の列に近づきます。混ぜる関数も簡単なものを使っており、実際の実装とは違います。上限に当たる時期の計算は、ドキュメントの3000という値と、この計測の割合を掛け合わせた見積もりです。ここで見せているのは、分けても消えない偏りがあること、上限が置き場所ごとに掛かることの2つです。
Every partition in a DynamoDB table is designed to deliver a maximum capacity of 3,000 read units per second and 1,000 write units per second.原文AWS ドキュメント「Best practices for designing and using partition keys effectively in DynamoDB」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る