mongodb - レプリカセットとMongoDB、オプション {w:1} はシステムのAPをCAP的にしますか?

Question

CAP 定理に関しては、MongoDB は通常デフォルトでCPとして定義されます。レプリカセットのシナリオで、次は正しいですか? オプションwは書き込みの懸念事項です。

{ w: 1 }: プライマリからの確認のみを待ちます。二次メンバーから読み取ると、システムは最終的に一貫性があり、次にAPです。
{ w: 3 }: 3 人のメンバーからの確認を待ちます。レプリカが 3 つのメンバーで構成されている場合、システムは一貫性があり(強力ですか?)、したがってCPです。

score 2 · Accepted Answer

Mongodbレプリケーションガイドを見ると、デフォルトではすべてのクエリがプライマリサーバーに送られます。「A」が必要な場合は、セカンダリサーバーでも読み取る必要があります。これは AP である必要があります。そして、サーバーごとに結果が異なる可能性があるため、C を失います。

質問もこのように見えますが、答えが役立つ場合があります。

score 2 · Accepted Answer

Asyaのためにコメントを削除する前に、この件に関する私の最初の懸念を裏付けるために、証拠の一部（K氏が投稿したように： MongodbはCAP定理のどこに立っていますか？）のためにこれを答えとして置きます。

MongoDB の CAP への準拠は、どの書き込み懸念がどの読み取り懸念に置かれているかに基づいているようです。

例を見てみましょう。プライマリからの読み取りのデフォルト構成では、次の{w:1}ようになります。

MongoDB 自体は、書き込みに関係なく (パーティショニングによって書き込みが失われたとしても)、完全に問題なくパーティショントレラントになります (各側に偶数のサーバーがない限り)。

ただし、MongoDB は最終的に一貫性があり、メンバーから古いデータが返されるため、この書き込み懸念のあるセカンダリからの読み取りは、実際には A の原因になります。

3 メンバーの 2 番目の例では、{w:3}完全に CAP になる可能性があります。

C すべてのメンバーに渡されるため
A すべてのメンバーで利用できるため
P は、レプリカセットのどちらの側にも偶数のメンバーが含まれてはならないためです。これと矛盾するのは、即時フェイルオーバーが発生し、2 つのサーバーが反対側にある場合です。この場合、MongoDB はどちら側から読み取り/書き込みを行うかがわからず、ユーザーの介入が必要になるため、P が失われますが、abitriers を追加するだけで済みます。フォーラム。CAP のこの部分については、ウィキペディアにあるリンクで詳しく説明されています。 of 3" は誤解を招く". 例外は、MongoDB が C または A を失わないことを選択し、代わりにユーザーの介入を必要とすることです。

編集: 実際、この場合、MongoDB が停止するだけなので、CAP は完全に失われます。

もう一度編集: Asya が指摘したように、MongoDB はまだ読み取りを受け入れますが、書き込みは受け付けません。つまり、C のままですが、A を失います。これは標準によく適合します。

すべての読み取りに関する懸念があります。

そこで、ここで読み取り懸念と書き込み懸念が関与していることについて最初に述べたことに戻ります (正直なところ、どちらも関与していると思います)。これが私の答えです。

2 に答える 2