NoSQL:MongoDB或BigTable并不总是"可用"是什么意思

Ian*_*oyd 17 bigtable consistency mongodb nosql

阅读Nathan Hurst的NoSQL系统视觉指南,他包括CAP三角形:

  • Consistency
  • Availibility
  • Partition Tolerance

在此输入图像描述

SQL Server是一个AC系统,而MongoDB是一个CP系统.

这些定义来自加州大学伯克利分校教授埃里克·布鲁尔,以及他在PODC 2000(分布式计算原理)上的讲话:

可用性

可用性意味着 - 服务可用(完全运行或不运行).当您购买该书时,您希望获得回复,而不是某些关于该网站的浏览器消息是无法通信的.吉尔伯特和林奇在他们的CAP定理证明中提出了一个很好的观点,即当你最需要的时候,可用性最常让你失望 - 网站往往在繁忙的时期因为他们忙碌而瘫痪.可用但未被访问的服务对任何人都没有好处.

在MongoDB或BigTable的上下文中,系统不"可用"是什么意思?

你去连接(例如通过TCP/IP),服务器没有响应?您是否尝试执行查询,但查询永远不会返回 - 或返回错误?

不可用是什么意思

Chr*_*ain 13

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

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

[Node A] <- Switch #1 -> [Node B] <- Switch #2 -> [ Node C ]
Run Code Online (Sandbox Code Playgroud)

现在假设已经设置了所述系统,以便保证在被认为是已提交之前,任何写入将至少发送到2个节点.现在,让我们假设交换机#2被拔掉,一些客户端连接到节点C:

[Node A] <- Switch #1 -> [Node B]                 [ Node C ] <-- Some client
Run Code Online (Sandbox Code Playgroud)

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

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

编辑 - 来自以下评论:

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

  • 它不可用于写入,因为无法执行一致写入.它不适用于读取,因为可以在节点A和B上执行一致读取*,并且对C的任何读取都不一定会返回当前正确的(一致地提交)值. (3认同)

Lef*_*ium 6

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

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

  • 强一致性:一条数据最多存在一个分片.不存在不正确/过时的数据.
  • 强分区容忍度:即使网络已分区,请求也不会返回错误/陈旧数据.碎片继续独立于其他碎片工作.

  • 可用性低:在已故的分片上读取/写入数据将失败.

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

  • 强一致性:主节点处理的所有读/写操作.
  • 强分区容忍度:如果有足够的节点无法访问,则选择新的主节点.选举过程确保始终最多只有一个主节点.

  • 可用性低:即使可以通过辅助节点访问数据,当没有主数据库时,读/写也会失败.


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