シャーディングとパーティショニング

データ分割はなぜ必要か

データが数億行規模になると、1つのテーブル・1台のサーバーでは検索も更新も遅くなり、ディスクにも収まらなくなります。その解決策がデータを分割して持つことで、代表的な手法がパーティショニングとシャーディングです。

• パーティショニング — 1台のデータベース内でテーブルを内部的に分割する
• シャーディング — 複数台のサーバーにデータを分散して持たせる

「1台の中で分けるか、複数台に分けるか」が両者の違いです。

パーティショニング — 1台内の分割

テーブルを日付や地域などのルールで内部分割します。よく使うのが日付による範囲分割です。

• 「2025年1月のログはパーティション1、2月は2…」のように分ける
• 検索条件に日付があれば、該当パーティションだけを読むため速い
• 古いデータの削除が「パーティションごと切り離す」だけで一瞬で終わる — ログ系テーブルの運用で特に有効

[[リレーショナルデータベース]] の多く(MySQL、PostgreSQL など)が標準機能として持っています。

シャーディング — 複数台への分散

1台の性能限界を超えるため、シャードキー(分割の基準となる値)でデータを複数サーバーに振り分けます。たとえばユーザーIDを基準に「ID末尾0〜4はサーバーA、5〜9はサーバーB」のように分けます。

[[レプリケーション]] が「同じデータの複製で読み取りを分散」するのに対し、シャーディングは「違うデータを分担して書き込みも分散」します。[[MongoDB]] のようにシャーディングを標準機能で備えるデータベースもあります。

初学者向けポイント

• シャードキーの選択が最重要 — 特定のシャードだけにアクセスが集中する偏り(ホットスポット)が起きないキーを選ぶ
• シャーディングは運用が大幅に複雑になる最後の手段 — その前にインデックス最適化、キャッシュ、リードレプリカ、パーティショニングで凌げないか検討する([[スケーリング]] の段階論)
• 後からシャード数を変えるのは大仕事 — 導入時に再分割の方法まで考えておく

関連技術とのつながり

• [[レプリケーション]] — 複製で読みを分散。シャーディングは分担で書きも分散
• [[スケーリング]] — シャーディングは水平スケーリングの代表例
• [[MongoDB]] — シャーディングを標準機能で持つデータベース
• [[リレーショナルデータベース]] — パーティショニングは多くのRDBが標準搭載

Q: パーティショニングとシャーディングの違いとして正しいのはどれ?
- [x] パーティショニングは1台内の分割、シャーディングは複数台への分散
- [ ] パーティショニングは複数台への分散、シャーディングは1台内の分割
- [ ] 両者はまったく同じ意味の言葉
解説: 1台の中でテーブルを分けるのがパーティショニング、複数サーバーにデータを振り分けるのがシャーディングです。

Q: シャーディングで得られる効果はどれ?
- [ ] 複数シャードをまたぐ JOIN が速くなる
- [x] 書き込み性能と容量が台数分スケールする
- [ ] シャードキーを考えなくてよくなる
解説: 各サーバーが別のデータを分担するため書き込みも容量もスケールしますが、シャードをまたぐ処理は逆に困難になります。

Q: シャードキー選びで避けるべき状態はどれ?
- [ ] すべてのシャードにアクセスが均等に分かれる
- [x] 特定のシャードだけにアクセスが集中する(ホットスポット)
- [ ] シャード数と同じ数のキーを使う
解説: 偏ったキーを選ぶと1台に負荷が集中し、分散した意味がなくなります。均等に散るキー選びが最重要です。