パーティション

違うデータを別の台に置く

複製は同じ予約を複数台に写す手でした。パーティションはデータを分けて置く手で、分けた保存先をシャードと呼びます。1台の保存量や処理量が足りないときに検討します。

どの予約をどの台へ置くかは、鍵から計算で決めます。この回では予約IDの文字の符号を足し、台数で割った余りをシャード番号にする簡単な方式を使います。

入れるだけなら順番でもできますが、後で読むために置き場所の表が要ります。鍵から毎回同じ番号を計算できれば、読む側もその台を探せます。

書く側と読む側で同じ鍵、同じ計算、同じ台数を使うことが条件です。台数を変えると余りも変わるので、古いデータを動かす手順も必要になります。

鍵の選び方で偏る

公演IDを鍵にすると、同じ公演の予約を1台に集められます。公演ごとの一覧は読みやすい一方、人気公演の発売開始にはその台へ書き込みが集中します。

予約IDを鍵にすると、同じ公演でも予約ごとに別の台へ分けられます。ただし分散の程度はIDと計算方法で変わり、必ず均等になるとは限りません。

そうです。予約IDで分けると、公演ごとの一覧を作るために複数台へ問い合わせ、結果を集める必要があります。書きを分散する代わりに、まとめて読む手間を引き受けます。

席の在庫と予約を一緒に更新する処理も確認します。別々のシャードにまたがる更新は複雑になるため、予約の一覧だけを分ける案でも、在庫の確認方法を残しておきます。

鍵の候補は、台ごとの件数だけでなく、読み書きの頻度でも比べます。保存量が均等でも、よく読まれる予約が特定の台へ偏れば、その台が先に詰まります。

予約サービスで解いてみる

DAU3万人、1人6回の要求から平均約2 QPSと見積もります。ピーク係数50で100件/秒、1台40件/秒なら、均等に分けられる前提で3台が目安です。

この3台に予約一覧を置く例で、公演IDと予約IDのどちらを鍵にするか比べます。まず、文字の符号を足した数を台数で割り、余りを置き場所にします。

r-101の合計 = 114 + 45 + 49 + 48 + 49 = 305
r-102の合計 = 306
r-103の合計 = 307
3で割った余り = 順に2、0、1

同じ人気公演の予約でも、この3件は別々の台へ入ります。予約IDで1件を探すなら1台に聞けばよく、公演の予約を全部集めるなら3台に聞きます。

発売開始の書きを分散したいなら、予約IDが候補です。月5万円の予算内で、複数台への問い合わせや移動の運用まで扱えるかを確かめて決めます。