NoSQL：MongoDB 或 BigTable 并不总是“可用”意味着什么

Question

阅读 Nathan Hurst 的 Visual Guide to NoSQL Systems，他包含了 CAP 三角形：

• Consistency
• Availibility
• Partition Tolerance

SQL Server 是 AC 系统，MongoDB 是 CP 系统。

这些定义来自UC Berkley professor Eric Brewer, and his talk at PODC 2000（分布式计算原理）：

可用性

可用性意味着 - 服务可用 （完全或不按上述方式操作）。当你买了你想买的书 得到响应，而不是一些关于该网站的浏览器消息 不善交际。 Gilbert & Lynch 在他们的 CAP 定理证明中使 优点是可用性通常会在您需要时抛弃您 它最 - 网站往往会在繁忙时期关闭，正是因为它们 很忙。可用但未被访问的服务是不可用的 造福于任何人。

在 MongoDB 或 BigTable 的上下文中，系统不“可用”是什么意思？

您是否进行连接（例如通过 TCP/IP），但服务器没有响应？您是否尝试执行查询，但查询从不返回 - 或返回错误？

不可用是什么意思？

Answer 1

在这种情况下的可用性意味着在网络分区的情况下，客户​​端连接的服务器可能无法保证客户端期望的一致性级别（或系统配置为提供）。

假设您在假设的分布式系统中有 3 个节点 A、B 和 C。 A、B 和 C 各自运行在自己的服务器机架中，它们之间有 2 个交换机：

[Node A] <- Switch #1 -> [Node B] <- Switch #2 -> [ Node C ]

现在假设所述系统已设置为保证任何写入在被视为已提交之前将至少到达 2 个节点。现在，让我们假设交换机#2 被拔掉，并且一些客户端连接到节点 C：

[Node A] <- Switch #1 -> [Node B]                 [ Node C ] <-- Some client

该客户端将无法发出一致性写入，因为分布式系统当前处于分区状态（即节点 C 无法联系足够多的其他节点以保证所需的 2 节点一致性）。

我要补充一点，一些 NoSQL 数据库允许非常动态地选择 CAP 属性。例如，Cassandra 允许客户端指定在每次写入之前写入必须到达的服务器数量。写入单个服务器是“AP”，写入仲裁（或所有）服务器更多的是“CA”。

编辑 - 来自下面的 cmets：

在 MongoDB 中，您只能在副本集中进行主/从配置。这意味着 AP 与 CP 的选择是由客户端在查询时做出的。客户端可以指定slaveOk，它将从任意选择的slave（可能有陈旧数据）中读取：mongodb.org/display/DOCS/…。如果客户端对陈旧数据不满意，请不要指定 slaveOk，查询将转到主服务器。如果客户端无法访问主服务器，那么您将收到错误消息。我不确定这个错误到底是什么。

Answer 2

CAP 定理适用于分布式计算机系统。 MongoDB 支持两种不同形式的分布式计算：用于水平扩展的分片和用于故障转移/高可用性的副本集。两者可以一起使用，也可以单独使用。我认为 CAP 定理对这两种形式的应用略有不同：

分片级别 - MongoDB 最多将数据存储在一个权威分片上。

• 强一致性：一条数据最多存在一个分片上。不存在不正确/陈旧的数据。

• 强大的分区容错性：即使网络分区，请求也永远不会返回不正确/陈旧的数据。分片继续独立于其他分片工作。

• 弱可用性：在停机分片上读取/写入数据将失败。

副本集级别 - MongoDB 在分片内复制数据，通过单个权威主节点确保一致性。

• 强一致性：主节点处理的所有读/写。

• Strong Partition-tolerance：如果有足够多的节点无法访问，则会选出一个新的主节点。选举过程确保始终最多有一个主节点。

• 弱可用性：当不存在主节点时，即使可以通过辅助节点访问数据，读/写操作也会失败。

---

slaveOK/ReadPreference.SECONDARY 选项牺牲了一些一致性（可以读取陈旧数据）以提高性能和可用性。