在CAP原则的背景下，Mongo和Cassandra有何区别？

Question

在阅读了一些关于谷歌的文章后，我了解到像Mongo这样的NoSql数据库是为CP（在CAP中）而设计的，而Cassandra是为AP（在CAP中）而设计的。

我的问题是：

是否可以配置Mongo以提供AP而不是CP，或者它的设计非常严格只能提供CP？同样的情况也适用于Cassandra吗？

- emilly

Answer 1

我们对CAP定理的理解自2000年首次提出以来已经发生了相当大的变化。关于“选择3中的2”的概念存在许多混淆，但是Eric Brewer在2012年的文章很好地消除了这些混淆（我猜）。因此，CAP定理并不是关于CA或AP或其他什么的。它只是这样：网络分区可能随时发生，这是不可避免的。当网络分区发生时，分布式数据库的架构应该允许其客户端根据需要调整一致性和可用性。这意味着什么？假设您在群集中的3个节点（N1、N2和N3）之间复制了一段数据（因此复制因子= 3）。假设发生了网络分区，将N3与N1和N2分开：

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

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

我不知道Mongo是怎么工作的，但这就是考虑CAP定理后Cassandra的工作方式。

- burak ibrahim sevindi

Answer 2

Cassandra使用可调整一致性，您可以通过使用不同的一致性级别在写入和/或读取数据时进行控制。例如，如果您在写入和读取时都使用QUORUM，则可以获得强一致性，尽管可用性可能会受到影响。

附注：我无法对Mongo进行评论...

- Alex Ott

Answer 3

你可以通过允许分裂大脑在MongoDB中实现“AP”。

您可以通过将读/写设置为“ALL”设置来使Cassandra“CP”（在某些边缘情况下，QUORUM不足）。

但是，有一篇非常好的文章解释了为什么称数据库为AP / CP是错误的术语。在CAP定理的上下文中，可用性和一致性有非常强而有力的定义，大多数时候人们没有深入了解它，并且顺便说一句，大多数数据库都不能严格符合CAP定理，既不是AP也不是CP。

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

- nevsv

Answer 4

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

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

对于Cassandra而言，正如Alex所说，我们可以通过牺牲可用性来提高Cassandra的一致性。

阅读本文，了解详细解释。

- Bikas Katwal