Mímisbrunnr知恵の泉

← 分散システム 一覧

🎓 レベル:標準 | 重要度:A(必須)

📎 前提:透過性とスケーラビリティ | 関連:一貫性ハッシュレプリケーション方式(同期/非同期・リーダー/リーダーレス)

要点(BLUF)

問題設定 ── 1台に乗らないデータを分ける

レプリケーション(レプリケーション方式(同期/非同期・リーダー/リーダーレス))は同じデータを複数に置くだけで、1台の容量・書き込み上限は超えられません。データそのものを分割して別ノードに置けば、容量も書き込みも台数ぶん伸びる——これがパーティショニングです(透過性とスケーラビリティ の水平スケール)。

モデル ── 範囲分割 vs ハッシュ分割

flowchart TB
    K["キー空間"] --> RG["範囲分割:A-F→P1, G-M→P2, N-Z→P3"]
    K --> HS["ハッシュ分割:hash(key)で分散→P1・P2・P3"]
    RG -->|"レンジ検索○ / 偏り×"| R1["連続キーが同一パーティション"]
    HS -->|"均等○ / レンジ検索×"| H1["連続キーが散らばる"]
方式利点欠点
範囲分割レンジ検索が高速(連続キーが近い)、ソート済みホットスポット(時系列キー等で末尾に集中)
ハッシュ分割負荷が均等に散るレンジ検索不可(連続キーが散る)

実務ではハッシュで大枠を分け、範囲で細分するなどの折衷(複合キー)も使います。

難所1 ── ホットスポット

特定パーティションにアクセスが集中する偏り。典型は「タイムスタンプを先頭キーにした範囲分割」で常に最新パーティションに書き込みが殺到する。対策:キーにランダム接頭辞やハッシュを混ぜて分散(ただしレンジ検索性を犠牲にする)。

難所2 ── 二次インデックス

分割キー(例:user_id)では引けるが、別の属性(例:色=“red”の商品全部)で引くと全パーティションに問い合わせが要る。2方式:

難所3 ── リバランス

ノードを増減すると、データの再配置(リバランス)が必要。素朴なハッシュ(mod N)はノード数変化でほぼ全キーが移動してしまう(一貫性ハッシュ のラボで83.6%移動を実証)。これを避けるのが一貫性ハッシュや固定数パーティション方式(パーティション数を固定し、ノード間でパーティションを移すだけ)です。

正しさ/運用の観点

なぜ分散だと難しいか(直観)

分割は「スケールは買えるが、またぎ操作が高くつく」取引。同一パーティション内なら単一マシン的に速く一貫的に扱えるが、パーティションをまたぐ集計・トランザクション・JOINは通信と調整を呼ぶ。だからアクセスパターンに合わせてキーを設計することが、後からは直しにくい最重要の設計判断になります。

⚠️ よくある誤解・落とし穴

対応ラボ

なし(概念回)。リバランス最小化は 一貫性ハッシュ のラボで定量実証します。

関連

第6章 レプリケーションとパーティショニング 目次