我看到的每个地方,我都看到MongoDB是CP。 但是当我深入挖掘时,我发现它最终是一致的。 当你使用safe = true时它是CP吗?如果是这样,这是否意味着当我使用safe = true写入时,所有副本将在获得结果之前更新?
答案 0 :(得分:111)
这应该有助于回答这个问题,以及其他NoSQL和其他持久性存储系统。
答案 1 :(得分:84)
默认情况下,MongoDB非常一致 - 如果您执行写操作然后执行读操作,假设写操作成功,您将始终能够读取刚刚读取的写操作结果。这是因为MongoDB是一个单主系统,默认情况下所有读取都转到主系统。如果您可以选择启用辅助数据,那么MongoDB最终会在可以读取过期结果的地方保持一致。
MongoDB还通过副本集中的自动故障转移获得高可用性:http://www.mongodb.org/display/DOCS/Replica+Sets
答案 2 :(得分:25)
我同意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(Which will cost you execution speed)时,MongoDB非常一致。一旦你不满足这些条件(特别是当你从二次复制品中读取时),MongoDB就会变得最终一致。
MongoDB通过Replica-Sets获得高可用性。一旦主服务器关闭或其他服务器不可用,那么辅助服务器将确定新的主服务器再次可用。这样做有一个缺点:旧的主要执行但未与辅助节点同步的每个写入都将rolled back并保存到回滚文件中,只要它重新连接到该集合(旧的主要的)现在是次要的)。所以在这种情况下,为了可用性,牺牲了一些一致性。
通过使用所述副本集MongoDB也实现了分区容错:只要副本集的一半以上服务器相互连接,a new primary can be chosen。为什么?要确保两个独立的网络不能同时选择新的主要网络。如果没有足够的辅助设备彼此连接,您仍然可以从它们读取(但不保证一致性),但不能写入。为了保持一致性,该组几乎不可用。
答案 3 :(得分:16)
当brilliant new article出现并且此字段中还有一些awesome experiments by Kyle时,在将MongoDB和其他数据库标记为C或A时应该小心。
当然CAP有助于追踪数据库普遍存在的含义,但人们经常忘记CAP中的C意味着原子一致性(线性化)。在尝试分类时,这让我很难理解。因此,除了MongoDB提供强大的一致性,这并不意味着是C.这样,如果进行这种分类,我建议还要更深入地了解它实际上是如何工作的,不要怀疑。
答案 4 :(得分:10)
答案 5 :(得分:4)
我不确定P对Mongo来说。想象一下情况:
这里的问题是转储文件的大小是有限的,如果你有一个分区很长一段时间,你可以永远丢失你的数据。
你可以说它不可能发生 - 是的,除非在云中比人们想象的更常见。
这个例子就是为什么在将任何字母分配给任何数据库之前我会非常小心。有很多场景和实现并不完美。
如果有人知道在Mongo的后续版本中是否已解决此问题,请发表评论! (我一直没有关注所发生的一切......)
答案 6 :(得分:2)
只要有分区,MongoDB就会在可用性上选择一致性。意思是,当有分区(P)时,它选择一致性(C)而不是可用性(A)。
要了解这一点,让我们了解MongoDB如何执行副本集。副本集具有单个“主”节点。提交数据的唯一“安全”方法是先写入该节点,然后等待该数据提交到集合中的大多数节点。 (发送写操作时,您将看到w =多数的标志)
在以下两种情况下可能会发生分区:
基本上,每当发生分区并且MongoDB需要决定要做什么时,它将选择一致性而不是可用性。它将停止接受对系统的写入操作,直到它认为可以安全完成这些写入操作为止。
答案 7 :(得分:1)
Mongodb提供了一致性和分区容限。
在分布式(NoSQL)数据库的上下文中,这意味着始终需要在一致性和可用性之间进行权衡。这是因为分布式系统总是必须具有分区容忍性(即,如果它不具有分区容忍性,它将根本不是分布式数据库。)
一致性-系统最终将变得一致。数据迟早会传播到任何地方,但是系统将继续接收输入,并且在移至下一个事务之前不会检查每个事务的一致性。
可用性-默认情况下,Mongo DB Client(MongoDB驱动程序)将所有读/写请求发送到领导者/主节点。它使系统保持一致,但由于- 如果领导者与集群断开连接,则需要几秒钟的时间来选举新的领导者。因此,在这段时间内无法进行读写操作。
答案 8 :(得分:0)
Mongodb永远不允许写入辅助文件。它允许从辅助目录进行可选读取,但不允许写入。因此,如果您的主服务器出现故障,您将无法编写,直到辅助服务器再次成为主服务器。这样,您就牺牲了CAP定理中的高可用性。通过仅保留主要内容的读物,您可以拥有很强的一致性。