1

Web サイトのバックエンド用にスケーラブルなデータベース ソリューションを構築したいと考えています。最近、データベースの設計について読んでいて、うまくいくかもしれないアイデアを自分で開発したようです。これは同期されたデータで n 個のデータベースを維持する斬新な方法だと思いますが、間違っている可能性があります。だから私はSOにアイデアを評価して、それがクレイジーかどうか教えてくれるように頼んでいます. (または、既に存在し、実装されている場合)

このスキームには、サーバーノードのグループがあります。1 つのノードはクエリ ロード バランサを実行し (これをAと呼びましょう)、残りは一般的な dbms を実行しています。これらのノードをまとめてNと呼びましょう。

各 N は他から切り離されています。つまり、Nのノードは他のノードと通信する必要はありません。各NはAのみに接続されます。

プロセスは次のように機能します

  • すべてのデータベース クエリはAを介して渡されます。(ここでは、 Aが無限のスループットと処理能力を持っていると仮定しましょう)
  • Aは各クエリ ( Q ) を検査し、それがデータベースから読み取る操作か、データベースに書き込むクエリかを判断します。(SQL では、読み取りは選択になり、書き込みは更新になります)
  • Qが読み取り操作の場合、 N内のノードの1 つに転送します
  • Qが書き込み操作の場合、それをNのすべてのノードに転送します

適切に実装されていると仮定すると、これにより、N内のすべてのノードが同期されたデータベース コンテンツを持つことになります。データの読み取りのみを行うクエリは、1 つのノードに送信する必要があります。

私のシステムでは書き込み操作が非常に少なく、1% 未満であるため、このアイデアは特にうまく機能しているようです。

このアイデアについていくつか質問があります

  • このようなスキームは、理論的な観点から理にかなっていますか?
  • これが理にかなっている場合、商用または無料のソリューションが既に実装されていますか?
4

3 に答える 3

7

読み取り数が多く書き込みが少ない場合の典型的なセットアップは、読み取り/書き込みマスター データベースと、読み取り専用の複製された n 個のスレーブ データベースを持つことです。レプリケーションは RBDMS によって処理されます。読み取り専用クエリは、n 個の読み取り専用ノードすべてで負荷分散できます。読み取り/書き込みマスターが一時的にダウンした場合でも、少なくともアプリは読み取り操作を処理できます。クエリが読み取りか書き込みかを判断するために、中央の "A" プロキシは必要ありません。クエリを発行するクライアントは、それが読み取りまたは書き込みのどちらであるかを認識できるほど賢くある必要があります。そうすれば、「A」サーバーでボトルネックになることはありません。

提案されたセットアップには、n 個のノードに同時に書き込みを行っている場合、それらの書き込みの 1 つ以上が失敗した場合はどうなるかという明確な欠陥があります。

于 2009-09-15T23:58:29.633 に答える
1

あなたのスキームは、無限に利用可能なノードでのみ機能します。ノードのダウンタイムにどのように対処しますか? ノードが何らかの理由でダウンし、更新を逃した場合、次に要求されたときにダーティ データを提供します。

于 2009-09-15T23:55:07.130 に答える
1

あなたの質問に対する直接的な回答ではありませんが、SQL Server 2008 は、あなたが説明しているものと同等のものを既にサポートしています。それはPeer-to-Peer Transactional Replicationと呼ばれます。他のRDBMSも同様だと思います。MySQL ではマスター マスター レプリケーションと呼んでいると思います。

于 2009-09-16T00:37:11.277 に答える