シャーディング(水平分割)
Sharding
1つの巨大テーブルを行で分割し、複数のDB(シャード)に分散する手法。各シャードはデータの一部だけを持つ。例: 姓の頭文字や地域で分ける。書き込みもスケールできる。
たとえ話: 名簿を頭文字で分冊する
1冊の巨大な名簿(=テーブル)が分厚すぎて扱えないとき、『あ〜さ行』『た〜は行』『ま〜わ行』と複数の冊子(=シャード)に分けます。各冊子は名簿の一部だけを持ち、薄くて扱いやすい。『佐藤さん』を探すなら最初の冊子だけ見ればいい。
図を描画中...
Federation との決定的な違い(再確認)
- Federation = テーブルの種類で分ける(users用DB、products用DB)= 縦割り。
- Sharding = 同じテーブルの行で分ける(usersを頭文字で複数DBに)= 横割り。
だからShardingは『1つのテーブルが巨大すぎる』問題に効きます。Federationでは解けないケースの切り札です。
メリット
- 各シャードが小さい → インデックス縮小、検索高速化。
- 書き込みも分散 → 別シャードへの書き込みは並行に走る(書き込みスケール)。
- 障害分離 → 1シャードが落ちても、他のシャードのデータは使える。
3大つまずきポイント
1. データの偏り(ホットスポット)
分割キーが悪いと、特定シャードにアクセスが集中します。
例: フォロワー数で分けたら、有名人のいるシャードだけアクセス殺到。
均等に散らばる分割キー(ハッシュなど)を選ぶことが重要です。
2. リバランスの難しさ
シャードを増やすとき、単純な方法(IDを台数で割った余り)だと、台数が変わった瞬間にほぼ全データの再配置が必要になります。
図を描画中...
これを consistent hashing(コンシステントハッシュ) で緩和します。台数変更時に動かすデータ量を最小限に抑える賢い割り当て方式です。
3. シャードまたぎのJOIN・トランザクション
別シャードにあるデータ同士を結合・同時更新するのが難しい。アプリ側で複数シャードに問い合わせて結合する、といった手間が増えます。
つまずきポイント総括
- ShardingとFederationは『縦割りか横割りか』で区別する。
- 分割キー選びが命。偏ると意味がない。
- 一度シャーディングすると後戻りが大変。導入は本当に必要になってから。