データベースshardingとは? データをマシン間で分割する

データベースshardingは、一つのデータセットを複数のデータベースに分割し、各データベースがshard keyで選ばれたデータの部分集合を保持します。

レプリカは読み取りをスケールしますが書き込みはスケールせず、すべての書き込みは依然として一つのプライマリに当たります。shardingはデータそのものを分割することで書き込みをスケールします。各shardはデータの一部を保持する別々のデータベースで、shard keyによって選ばれます。強力ですが侵襲的で、クエリ・トランザクション・運用のすべてが難しくなるため、通常は最後の手段です。

shardingがデータを分割する方法

shard key (ユーザーID、リージョン、テナント) が、ある行がどのshardに存在するかを決めます。各shardは独立したデータベースです。一人のユーザーへのクエリは一つのshardに触れ、全ユーザーへのクエリはすべてのshardにファンアウトして結果を統合しなければなりません。

得られるもの

単一のプライマリを超えた書き込みのスケーリング。
shardごとの小さなデータセットで、クエリとインデックスが高速。
障害の隔離: 一つのshardのダウンは、そのデータの一部にのみ影響します。
単一マシンの限界を超える道。

追加されるコスト

shardをまたぐクエリやトランザクションは難しいか不可能です。悪いshard keyを選ぶとホットスポットが生まれます。shardを追加する際のデータのリバランスは大きな作業です。これらのコストが、より単純な選択肢を出し尽くすまでshardingが避けられる理由です。

shardingされたシステムのテスト

単一データベースのテストでは、shardのルーティングのバグやshardをまたぐクエリの誤りを捕まえられません。CIは複数shardの構成に対してテストし、ルーティング、ファンアウト、リバランスのロジックが仮定ではなく実際に実行されるようにすべきです。

デプロイと移行がより難しくなる

スキーマ移行はすべてのshardで実行しなければならず、resharding操作は慎重で段階的なプロセスです。部分的な移行はshardを不整合な状態にするため、パイプラインはこれらの複数shardの変更を調整し検証します。

複数shardのテストセットアップ

CI実行ごとに複数のshardインスタンスを立ち上げるのはリソースを大量に使います。適切にサイズされたウォームなrunner (Latchkeyが提供するもの) は、それらの現実的な複数shardのテストがパイプラインを引きずらないようにします。

重要なポイント

shardingは、書き込みをスケールするために、shard keyでデータを独立したデータベースに分割します。
shardをまたぐクエリ、トランザクション、リバランスを著しく難しくします。
移行とテストは、代表的な単一データベースではなく、すべてのshardをカバーしなければなりません。