MySQLをスケールさせるとき、partitioningとshardingをそれぞれいつ選びますか。

Question

IT Interview Practice · Accepted Answer

どちらも大きなテーブルを分割しますが、そのレベルが異なります。**partitioning**は、**単一のMySQLサーバー内で**1つのテーブルを複数のファイルに分割します。**sharding**は、**複数の独立したサーバー**にデータを分割します。partitioningは1ファイルに収まらないほど大きなテーブルに役立ち、shardingは1台のマシンに収まらないほど大きなワークロードに役立ちます。

## partitioning（1台のサーバー）

```sql
CREATE TABLE events (
  id BIGINT, created_at DATETIME, payload JSON,
  PRIMARY KEY (id, created_at)          -- partition key must be in every unique key
) PARTITION BY RANGE (YEAR(created_at)) (
  PARTITION p2024 VALUES LESS THAN (2025),
  PARTITION p2025 VALUES LESS THAN (2026),
  PARTITION p2026 VALUES LESS THAN (2027)
);
-- Queries filtering on created_at hit ONE partition (partition pruning);
-- dropping old data is an instant ALTER TABLE ... DROP PARTITION p2024.
```

時系列データや容易なアーカイブには最適ですが、依然として1台のサーバーです。CPU、RAM、書き込みスループットの総量が増えるわけではありません。

## sharding（複数のサーバー）

**shard key**（例: `user_id`）を選び、ハッシュまたは範囲によって各行をシャードにルーティングします。

```
shard = hash(user_id) % N
  user 42 -> shard 2 (server B)     user 99 -> shard 0 (server A)
```

- **利点** — 書き込み、ストレージ、接続数のほぼ線形なスケーリング。
- **欠点** — シャードをまたぐJOINやトランザクションは困難または不可能。不適切なshard keyはホットスポットを生む。サーバー追加時の**resharding**は苦痛。カーディナリティが高く均等に分散するキーを選び、全シャードにファンアウトが必要なクエリは避ける。

## 対応の順序

まずは安上がりな手を出し尽くします。インデックス、クエリチューニング、read replica、キャッシュ、そしてpartitioning。単一のprimaryが**書き込み**量をもはや吸収できなくなったときだけshardingに手を伸ばします。運用の複雑さが最も大きく跳ね上がる選択だからです。

## なぜ重要なのか

スケーリングの決定は、おおむね不可逆で高コストです。partitioningが単一サーバー内の整理のための道具であるのに対し、shardingはshard keyやシャードをまたぐコストを伴う分散システムへのコミットメントだと知っていれば、チームが時期尚早にshardingしたり、partitioningに解決できない書き込みスループットの上限の解消を期待したりせずに済みます。

partitioning（1台のサーバー）

sharding（複数のサーバー）

対応の順序

なぜ重要なのか

関連する質問