← AWSサービスの内部原理 コース
3. どのパーティションに行くかはハッシュが決める — パーティションキーの正体
パーティションキーの値がどうやって物理的な格納先を決めるのか、図で追っていきましょう。
①書き込み先はハッシュが決める
put(項目)パーティションキー付き
キーの値を入力
内部ハッシュ関数
出力値が格納先を一意に決定
パーティションA
パーティションB
ここに保存パーティションC
- ・パーティション=SSDで構成された格納領域のかたまり
- ・読み取りも同じキー→同じハッシュ→同じパーティションで項目に到達
パーティションキーの値をハッシュ関数に通し、その出力値が格納先パーティションを一意に決めます。
②正体はハッシュテーブルの分散版
キー任意の長さの入力
ハッシュ関数
固定的な出力値
出力で格納先が決まる
バケットメモリ上(ハッシュテーブル)
パーティション複数AZに複製されたストレージ
DynamoDBはこちら「キーをハッシュして格納先を決める」骨格は同じ。違いは格納先がメモリのバケットか、複数AZに複製された物理パーティションか。
③単純主キーと複合主キーの違い
単純主キーPKのみ
PK値だけで一意複合主キーPK+ソートキー
同じPK値が複数あり得る複合キーの場合
item collection同じPK値の項目群をSK昇順で保存
- ・項目を一意に識別するのは主キー全体(複合キーではPK単独では一意にならない)
- ・公式は「まとめておく傾向がある」と表現
- ・LSIを持たないテーブルでは、量に応じてitem collectionが複数パーティションに分割されることがある
複合キーでは同じPK値の項目が複数あり得ます(item collection)。それでも起点を決めるのはPKのハッシュ、という骨格は共通です。
④ホットパーティションはハッシュの原理から起こる
取りうる値が数種類のキー低カーディナリティ
ハッシュしても散らせない
パーティションA
アクセス集中=ホットパーティションBほぼ空
パーティションCほぼ空
- ・ハッシュテーブルで悪いキーを選ぶと同じバケットに集中したのと原因は同じ
キーの値のばらつき(カーディナリティ)が乏しいと、ハッシュは散らしようがなく、一部のパーティションにアクセスが偏ります。
⑤良いキーの条件は「散らばる×偏らない」
userId / orderId など十分に多くの異なる値を取れる
それでも特定の1値に殺到すると
人気商品IDの行き先
そこだけホット化他のパーティション
だから設計の勘所は
値が十分に散らばる
アクセスが偏らない
公式はuserIdなど高カーディナリティなキーを推奨。ただし特定の1値にアクセスが殺到すればホット化は起こり得ます。