いつシャーディングすべきですか？

単一のデータベースが負荷 (CPU、メモリ、ディスク、IOPS) やデータ量に耐えられなくなったときです。垂直スケーリング (サーバーの増強) のほうが簡単なので、まずはそれを試してください。垂直スケーリングの限界に達したとき、または地理的なデータ分散が必要なときにシャーディングします。シャーディングは大幅な複雑さを追加するため、早まってシャード化しないでください。

シャードキーはどう選べばよいですか？

次のようなキーを選んでください：データを均等に分散させる (高いカーディナリティ)、ほとんどのクエリに含まれる (シャードルーティングが可能)、めったに変わらない (再シャーディングを最小化)、関連データをグループ化する (シャード横断 JOIN を回避)。よく使われるのは user_id、tenant_id、地理リージョンです。トラフィックが 1 つのシャードに集中するホットキーは避けてください。

水平スケーリングのためにデータベースシャーディングを使う

シャーディングは、シャードキーによってデータを複数のデータベースへ分散します。シャーディング戦略、シャードをまたぐクエリ、トレードオフを学びましょう。

1

シャーディングは大きなデータベースを複数の小さなシャードに分割し、各シャードがデータの部分集合を保持します。シャードキーが、各行をどのシャードが保持するかを決定します。戦略：レンジ (シャード 1 に A-M、シャード 2 に N-Z)、ハッシュ (hash(key) % num_shards)、ディレクトリ (参照テーブル)。シャーディングは水平スケーリングを可能にしますが、シャードをまたぐクエリ、JOIN、トランザクションが複雑になります。
2

ハッシュ計算ツール →
ハッシュ関数でシャードを決定します：shard = hash(shard_key) % num_shards。これによりデータが均等に分散されます。シャードの追加/削除時のデータ移動を最小限にするには、コンシステントハッシュ (consistent hashing を参照) を使ってください。ハッシュツールは、指定されたキーのシャード割り当てを計算します。
3

SQL フォーマッター →
特定のシャードを対象とするクエリを整形します。各シャードは同じスキーマを持ち、アプリケーションはシャードキーに基づいてクエリを正しいシャードにルーティングします。シャードキーを含まないシャード横断クエリは、すべてのシャードに問い合わせて結果をマージする必要があります。性能のため、これらは避けてください。

よくある質問

いつシャーディングすべきですか？: 単一のデータベースが負荷 (CPU、メモリ、ディスク、IOPS) やデータ量に耐えられなくなったときです。垂直スケーリング (サーバーの増強) のほうが簡単なので、まずはそれを試してください。垂直スケーリングの限界に達したとき、または地理的なデータ分散が必要なときにシャーディングします。シャーディングは大幅な複雑さを追加するため、早まってシャード化しないでください。
シャードキーはどう選べばよいですか？: 次のようなキーを選んでください：データを均等に分散させる (高いカーディナリティ)、ほとんどのクエリに含まれる (シャードルーティングが可能)、めったに変わらない (再シャーディングを最小化)、関連データをグループ化する (シャード横断 JOIN を回避)。よく使われるのは user_id、tenant_id、地理リージョンです。トラフィックが 1 つのシャードに集中するホットキーは避けてください。