良い解決策は、仮想シャードを使用することだと思います。1 つのサーバーから始めて、すべての仮想シャードを 1 つのサーバーに向けることができます。増分 ID でモジュールを使用して、仮想シャード間で行を均等に分散します。Amazon RDS では、スレーブをマスターにするオプションがあるため、シャーディング設定を変更する (新しいサーバーにさらに多くの仮想シャードを向ける) 前に、スレーブをマスターにして、設定ファイルを更新してから削除する必要があります。新しいインスタンスに使用するシャード範囲に準拠しない modulu を使用する新しいマスターのすべてのレコード。
また、元のサーバーから行を削除する必要がありますが、これまでのところ、新しい仮想シャード範囲に基づいたモジュラス ID を持つすべての新しいデータが新しいサーバーを指しています。したがって、実際にデータを移動する必要はありませんが、Amazon RDS サーバーの昇格機能を利用できます。
その後、元のサーバーからレプリカを作成できます。一意の ID を次のように作成します: シャード ID + テーブル タイプ ID + 増分番号。したがって、データベースにクエリを実行すると、どのシャードに移動してデータをフェッチするかがわかります。
RavenDB でどのようにそれを行うことができるかはわかりませんが、Amazon RDS ではかなりうまく機能します。Amazon は既にレプリケーションとサーバー プロモーション機能を提供しているためです。
それらは、最初からシームレスな社交性を提供し、問題が発生したときに開発者に問題を解決するように指示しないソリューションであるべきであることに同意します. さらに、シャード全体にデータを均等に分散する多くの NoSQL ソリューションは、低レイテンシーのクラスター内で動作する必要があることがわかりました。したがって、それを考慮に入れる必要があります。2 台の異なる EC2 マシン (専用の Amazon クラスターではない) で Couchbase を使用しようとしましたが、データ バランシングが非常に遅くなりました。それも全体的なコストに追加されます。
また、4096 個の仮想シャードを使用して、スケーラビリティの問題を解決するために pinterest が行ったことを追加したいと思います。
多くの NoSQL データベースでのページングの問題についても調べる必要があります。このアプローチを使用すると、データを非常に簡単にページングできますが、最も効率的な方法ではない可能性があります。これは、複数のデータベースにクエリを実行する必要がある場合があるためです。もう 1 つの問題は、スキーマの変更です。Pinterest は、すべてのデータを MySQL の JSON Blob に入れることでこれを解決しました。新しい列を追加したい場合は、新しい列データ + キーで新しいテーブルを作成し、その列で Index を使用できます。たとえば、メールでデータをクエリする必要がある場合は、メールと ID を含む別のテーブルを作成し、メール列にインデックスを配置できます。カウンターは別の問題です。つまり、アトミックカウンターです。そのため、これらのカウンターを JSON から取り出して列に配置し、カウンター値をインクリメントできるようにすることをお勧めします。
優れたソリューションがありますが、結局のところ、それらは非常に高価になる可能性があることがわかります。私は時間をかけて独自のシャーディング ソリューションを構築し、後で頭痛の種にならないようにすることを好みました。他の道を選ぶと、あなたがトラブルに巻き込まれ、問題を解決するためにかなりのお金を要求するのを待っている会社がたくさんあります. あなたが彼らを必要とする瞬間に、彼らはあなたがあなたのプロジェクトを再び機能させるためにすべてを支払うことを知っているからです. それは私自身の経験からのものです。そのため、あなたのアプローチを使用して独自のシャーディングソリューションを構築することに頭を悩ませています。これもはるかに安価です。
もう 1 つのオプションは、ScaleBase や DBshards などの MySQL 用のミドルウェア ソリューションを使用することです。そのため、MySQL を引き続き使用できますが、スケーリングが必要になった時点で、十分に証明されたソリューションが用意されています。また、コストは代替案よりもはるかに低くなる可能性があります。
もう 1 つのヒント: シャードの構成を作成するときは、false または true を受け入れる write_lock 属性を設定します。false の場合、データはそのシャードに書き込まれないため、特定のテーブル タイプ (ユーザーなど) のシャードのリストを取得すると、同じタイプの他のシャードにのみ書き込まれます。これはバックアップにも適しているため、すべてのデータをバックアップしてすべてのシャードの特定時点のスナップショットを取得するときにすべてのシャードをロックしたい場合に、ビジターに分かりやすいエラーを表示できます。Amazon RDS を使用してすべてのデータベースのスナップショットを作成し、ポイントインタイム バックアップを使用するためのグローバル リクエストを送信できると思いますが。
問題は、ほとんどの企業が DIY シャーディング ソリューションの使用に時間を費やすことはなく、ScaleBase への支払いを好むことです。これらのソリューションは、最初からスケーラブルなソリューションを購入する余裕がある単一の開発者から提供されますが、必要なポイントに到達したときにソリューションがあることを確信したいと考えています。そこにある価格を見るだけで、かなりの費用がかかることがわかります。完了したら、コードを喜んで共有します。私の意見では、あなたは最善の道を進んでいます。それはすべて、アプリケーションのロジックに依存します。私は自分のデータベースを単純で、結合がなく、複雑な集計クエリではないようにモデル化しています。これにより、多くの問題が解決されます。将来的には、Map Reduce を使用して、これらのビッグ データ クエリのニーズを解決できます。