mongodbはCAP定理のどこに位置していますか？
私が見るところはどこでも、MongoDBはCPであることがわかります。しかし、掘り下げてみると、最終的には一貫していることがわかります。 safe = trueを使用するとCPになりますか？もしそうなら、それはsafe = trueで書いたとき、結果を得る前にすべてのレプリカが更新されることを意味しますか？
MongoDBはデフォルトで強い整合性があります-書き込みを行ってから読み取りを行うと、書き込みが成功したと仮定すると、常に読み取った書き込みの結果を読み取ることができます。これは、MongoDBがシングルマスターシステムであり、すべての読み取りがデフォルトでプライマリに送信されるためです。オプションでセカンダリからの読み取りを有効にすると、MongoDBは最終的に一貫性がなくなり、古い結果を読み取ることが可能になります。
MongoDBは、レプリカセットの自動フェールオーバーによって高可用性も実現します。 http://www.mongodb.org/display/DOCS/Replica+Sets
これは、他のNoSQLや他の永続ストレージシステムとともに、質問への回答に役立つはずです。
Luccasの投稿に同意します。 MongoDBがCP/AP/CAであると言うことはできません。実際にはデータベース/ドライバーの構成と災害の種類に応じて、C、A、Pのトレードオフ：ここにあります視覚的な要約、およびより詳細な説明の下。
Scenario | Main Focus | Description
---------------------------|------------|------------------------------------
No partition | CA | The system is available
| | and provides strong consistency
---------------------------|------------|------------------------------------
partition, | AP | Not synchronized writes
majority connected | | from the old primary are ignored
---------------------------|------------|------------------------------------
partition, | CP | only read access is provided
majority not connected | | to avoid separated and inconsistent systems
一貫性：
単一の接続または正しい Write / Read Concern Level （ 実行速度が低下します ）を使用する場合、MongoDBは非常に一貫しています。これらの条件を満たさないとすぐに（特にセカンダリレプリカから読み取る場合）、MongoDBは最終的に整合性を取ります。
可用性：
MongoDBは Replica-Sets を使用して高可用性を実現します。プライマリがダウンするか、他のユーザーが使用できなくなるとすぐに、セカンダリは再び使用可能になる新しいプライマリを決定します。これには不利な点があります：古いプライマリによって実行されたが、セカンダリに同期されていないすべての書き込みは、セットに再接続するとすぐに ロールバック になり、ロールバックファイルに保存されます（古いプライマリはセカンダリになりました）。したがって、この場合、可用性のために一定の一貫性が犠牲になります。
パーティション公差：
上記のレプリカセットを使用することで、MongoDBはパーティショントレランスも実現します。レプリカセットのサーバーの半分以上が相互に接続されている限り、 新しいプライマリを選択できます 。どうして？ 2つの分離されたネットワークが両方とも新しいプライマリを選択できないようにするため。十分なセカンダリが相互に接続されていない場合でも、それらから読み取ることができます（ただし、一貫性は保証されません）が、書き込みはできません。一貫性を保つため、このセットは実際には使用できません。
華麗な新しい記事 といくつかの Kyleによる素晴らしい実験 が現れたので、MongoDBや他のデータベースにCまたはAのラベルを付けるときは注意が必要です。
もちろんCAPは、データベースが支配していることを多くの言葉なしで追跡するのに役立ちますが、人々はしばしばCAPのCがアトミックな一貫性（線形化可能性）を意味することを忘れがちです。そして、これは私が分類しようとしたときに理解するために多くの痛みを引き起こしました。ですから、MongoDBが強い一貫性を提供することは、それがCであることを意味するわけではありません。
MongoのPについてはわかりません。状況を想像してください：
- レプリカは2つのパーティションに分割されます。
- 新しいマスターが選出されたので、書き込みは両側に続きます
- パーティションが解決されました-すべてのサーバーが再び接続されました
- 何が起こるかというと、新しいマスターが選択されます-oplogが最も高いマスターが、パーティションの前に他のマスターからのデータが共通状態に戻され、手動回復のためにファイルにダンプされます
- すべてのセカンダリが新しいマスターに追いつきます
ここでの問題は、ダンプファイルのサイズが制限されており、長期間パーティションを使用していると、データを永久に失う可能性があることです。
起こる可能性は低いと言えます-はい、クラウドで考えられるよりも一般的でない限りはそうです。
この例が、データベースに文字を割り当てる前に非常に注意する理由です。非常に多くのシナリオがあり、実装は完全ではありません。
Mongoの今後のリリースでこのシナリオが解決されたかどうかを知っている人はコメントしてください！ （私はしばらくの間起こっていたすべてをフォローしていません。）
Mongodbはセカンダリへの書き込みを許可しません。セカンダリからのオプションの読み取りは許可されますが、書き込みは許可されません。したがって、プライマリがダウンした場合、セカンダリが再びプライマリになるまで書き込むことはできません。これが、CAP定理で高可用性を犠牲にする方法です。プライマリからの読み取りのみを保持することにより、強力な一貫性を確保できます。