19

Nathan Hurst のVisual Guide to NoSQL Systems を読んで、彼はCAP三角形を含めました。

  • C一貫性
  • A有効性
  • Pアーティショントレランス

ここに画像の説明を入力

SQL Server がACシステムであり、MongoDB がCPシステムです。

これらの定義は、カリフォルニア大学バークレー校の Eric Brewer 教授と、PODC 2000 (分散コンピューティングの原則) での彼の講演に由来します。

可用性

可用性とは、サービスが利用可能であることを意味します (上記のように完全に動作するかどうか)。本を購入するとき、ウェブサイトが通信不能であるというブラウザのメッセージではなく、応答を得たいと考えています。Gilbert と Lynch は、CAP 定理の証明で、最も必要なときに可用性が失われることがよくあることを適切に指摘しています。利用可能であるがアクセスされていないサービスは、誰にとっても何のメリットもありません。

MongoDB または BigTable のコンテキストで、システムが「利用できない」とはどういう意味ですか?

接続しようとしましたが (TCP/IP などで)、サーバーが応答しませんか? クエリを実行しようとしましたが、クエリが返されませんか、またはエラーが返されますか?

利用できないとはどういう意味ですか?

4

2 に答える 2

13

この場合の可用性とは、ネットワーク パーティションが発生した場合に、クライアントが接続するサーバーが、クライアントが期待する (またはシステムが提供するように構成されている) 一貫性のレベルを保証できない可能性があることを意味します。

架空の分散システムに 3 つのノード A、B、および C があると仮定します。A、B、および C はそれぞれ独自のサーバー ラックで実行されており、その間に 2 つのスイッチがあります。

[Node A] <- Switch #1 -> [Node B] <- Switch #2 -> [ Node C ]

ここで、書き込みがコミットされたと見なされる前に、少なくとも 2 つのノードに書き込みが行われることが保証されるように、上記のシステムが設定されていると仮定します。ここで、スイッチ #2 が取り外され、一部のクライアントがノード C に接続されていると仮定します。

[Node A] <- Switch #1 -> [Node B]                 [ Node C ] <-- Some client

そのクライアントは、分散システムが現在分割された状態にあるため、一貫性のある書き込みを発行できません (つまり、ノード C は、必要な 2 ノードの一貫性を保証するのに十分な数の他のノードに接続できません)。

これに加えて、一部の NoSQL データベースでは CAP 属性を非常に動的に選択できることを付け加えておきます。たとえば、Cassandra では、クライアントは、書き込みがコミットされる前に、書き込みごとに送信する必要があるサーバーの数を指定できます。単一のサーバーへの書き込みは「AP」であり、クォーラム (またはすべての) サーバーへの書き込みはより「CA」です。

編集 - 以下のコメントから:

MongoDB では、レプリカ セット内でのみマスター/スレーブ構成を持つことができます。これが意味することは、AP と CP の選択はクエリ時にクライアントによって行われるということです。クライアントは、slaveOk を指定できます。これは、任意に選択されたスレーブ (古いデータを持っている可能性があります) から読み取ります: mongodb.org/display/DOCS/…. クライアントが古いデータに問題がある場合は、slaveOk を指定しないでください。クエリはマスターに送信されます。クライアントがマスターに到達できない場合、エラーが発生します。そのエラーが何であるか正確にはわかりません。

于 2011-09-07T19:41:16.977 に答える
6

CAP の定理は、分散コンピューター システムに適用されます。MongoDB は、分散コンピューティングの 2 つの異なる形式をサポートしています。水平スケーリング用のシャーディングと、フェイルオーバー/高可用性用のレプリカ セットです。この 2 つは、一緒に使用することも、単独で使用することもできます。CAP の定理は、2 つの形式に少し異なって適用されると思います。

シャーディング レベル- MongoDB は、最大 1 つの信頼できるシャードにデータを格納します。

  • 強整合性: データの一部は、最大で 1 つのシャードに存在します。正しくない/古いデータは存在しません。

  • 強力なパーティション耐性: ネットワークがパーティション化されていても、リクエストが正しくないデータや古いデータを返すことはありません。シャードは、他のシャードから独立して機能し続けます。

  • 弱い可用性: ダウンしたシャードでのデータの読み取り/書き込みは失敗します。

レプリカ セット レベル- MongoDB はシャード内でデータを複製し、単一の権限のあるプライマリ ノードを介して一貫性を確保します。

  • 強い整合性: プライマリ ノードによって処理されるすべての読み取り/書き込み。

  • 強力なパーティション耐性: 十分な数のノードが到達不能になると、新しいプライマリが選出されます。選出プロセスにより、プライマリ ノードは常に 1 つに制限されます。

  • 可用性が低い: セカンダリ ノードを介してデータにアクセスできたとしても、プライマリが存在しない場合、読み取り/書き込みは失敗します。

slaveOK/ReadPreference.SECONDARY オプションは、パフォーマンスと可用性を向上させるために、ある程度の一貫性を犠牲にします (古いデータを読み取ることができます)。

于 2012-02-02T08:12:02.487 に答える