mongodb - CAP 背景下的 Mongo 和 Cassandra？

Question

在谷歌上阅读了几篇文章后，我看到像 Mongo 这样的 NoSql DB 被设计 用于 CP(在 CAP 中)，而 cassandra 是为 AP(在 CAP 中)设计的

这是我的问题:-

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

Answer 1

自从 CAP 定理于 2000 年首次出现以来，我们对它的理解发生了很大变化。“三选二”概念存在很多混淆，但 Eric Brewer 的 article 2012 年很好地消除了这些困惑(我猜)。

因此，CAP 定理与成为 CA 或 AP 或其他什么无关。简单来说就是:网络分区随时可能发生。这是不可避免的。当发生网络分区时，分布式数据库的架构应该允许其客户端根据需要调整一致性和可用性。

这是什么意思？假设您在集群中的 3 个节点(N1、N2 和 N3 - 因此复制因子 = 3)之间复制一段数据。假设发生网络分区，将 N3 与 N1 和 N2 分开:

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

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

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