在CAP的背景下，Mongo和Cassandra？

Question

在google上阅读了几篇文章之后，我看到了像Mongo这样的NoSql DB 对于CP（在CAP中）而cassandra是为AP设计的（在CAP中）

这是我的问题： -

Mongo不能配置为提供AP而不是CP或者是否为CP设计严格？ Cassandra也是如此吗？

Answer 1

我们对CAP定理的理解自2000年首次出现以来已经有了很大的改变。对于＆＃34;选择2-out-of-3＆＃34;有很多困惑。概念，但Eric Brewer的article在2012年很好地消除了这些混淆（我猜）。

因此，CAP定理不是关于CA或AP或其他东西。它就是这样：网络分区可能一直在发生。这是不可避免的。当网络分区发生时，分布式数据库的体系结构应该允许其客户端按照自己的意愿调整一致性和可用性。

这是什么意思？假设您在群集中的3个节点（N1，N2和N3 - 复制因子= 3）之间复制一段数据。并且让我们说发生网络分区，它将N3与N1和N2分开：

因此，所有3个节点都可以运行，但它们之间的网络现在是有问题的。在这种情况下，客户端可能会向N1，N2或N3发出读取请求或写入请求。根据此客户端的一致性选择，群集的反应可能不同：

• 如果客户端向N1发出读取请求，N1可以立即使用自己的数据回答查询。或者N1可以将相同的查询转发给N2，并将其数据与N2的数据进行比较，并返回最新的数据。这里，集群的反应取决于客户端的一致性选择。客户根据其选择调整一致性。
• 客户端也可以做出不同的选择：它可以强制N1从所有3个节点读取数据（即用Cassandra术语读取ALL的一致性）。在这种情况下，群集会返回一个错误，我们说根据客户的选择，群集不可用。
• 另一种可能性是：客户可能已经将数据询问到N3。在这种情况下，N3仅返回其数据（读取一致性= ONE）或查询失败（读取一致性＆gt; 1）。

我不了解Mongo，但这就是Cassandra在考虑CAP定理时的工作原理。

Answer 2

Cassandra使用可调整的一致性，您可以在使用不同的一致性级别编写和/或读取数据时控制它。例如，如果您对两个写入使用QUORUM＆amp;读取，然后你会获得强大的一致性，虽然可用性可能会受到影响。

P.S。我不能说Mongo虽然......

Answer 3

你可以实现＆＃34; AP＆＃34;在MongoDB中允许裂脑。

你可以制作Cassandra＆＃34; CP＆＃34;通过设置读/写到＆＃34; ALL＆＃34;设置（存在QUORUM不足的边缘情况）。

但是，有一篇非常好的文章说明为什么调用数据库AP / CP是一个错误的术语。在CAP定理的背景下，对于可用性和一致性有非常强大而可靠的定义，并且大多数时候人们没有足够深入地理解它，并且顺便说一下数据库不适合作为AP或CP的严格CAP定理。

链接：https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html

Answer 4

MongoDB永远不会成为AP，因为它是基于领导者的系统。 可能有两种情况：

1. 领导者与集群断开连接时，选举新领导者需要10到12秒的时间，在此期间，MongoDB将无法进行写操作。
2. 由于客户端和领导者之间的网络分区，导致客户端驱动程序与领导者断开连接。除非MongoDB客户也参加领导者选举并保持领导者的心跳，否则我不确定mongo是否具有此功能。

就Cassandra而言，正如Alex所说，我们可以通过降低可用性来使Cassandra更加一致。

阅读this article，以获取详细说明。