为什么在CAP定理中没有RDBMS分区容忍以及为什么它可用?

时间:2016-04-04 13:58:51

标签: distributed-computing rdbms distributed-system cap-theorem nosql

关于RDBMS在CAP定理中是CA的两点我不明白:

1)它说RDBMS 分区容忍但是RDBMS 比其他技术(如MongoDB或Cassandra)更少分区容忍度如何?是否存在RDBMS设置,我们放弃CA以使其成为AP或CP?

2)CAP如何可用?是通过主从设置吗?就像主机死机时一样,奴隶接管写入?

我是DB架构和CAP定理的新手所以请耐心等待。

4 个答案:

答案 0 :(得分:17)

现在很多数据库实际上有不同的配置,根据你设置的设置,它可以是CA,CP,AP等,但不能同时实现这三个。有些数据库实际上会努力支持这三种数据库,但仍然以某种方式对它们进行优先排序。

例如,MySQL可以是CP和CA,具体取决于配置。默认情况下,它是CA,因为它遵循主从属范例,该数据被复制到从属数据库。如果一组从站失去与主站的连接,则会牺牲分区容差,因此决定选择一个新的主站创建两个具有自己的从站的主站。

但是,MySQL还有另一种配置,它是一种集群配置。它优先考虑CP的可用性,例如。如果没有足够的活动节点来提供所有数据,群集将关闭。

可能有更多的MySQL配置使其满足其他CAP定理组合,但总的来说,我只是想说它取决于你的系统需要什么。有时数据库对于一种配置比另一种配置更好,因此最好看看在使用某种配置时可能出现的问题类型。

关于实现CAP定理,我建议进一步研究不同的数据库以及它们如何实现CAP定理的优先级。实现它们的方式太多了,例如。通常,主从模型用于CA系统,哈希环用于AP系统等。

答案 1 :(得分:4)

很容易误解CAP属性,因此,我提供一些说明以简化操作。

一致性::查询 Q 将产生相同的答案 A ,无论处理请求的节点如何。为了保证完全一致性,我们需要确保所有节点始终都同意相同的值。不要与最终的一致性相混淆,在最终的一致性中,网络会朝着使所有数据保持一致的方向发展,但是在一定时期内会变得不一致。

可用性:如果分布式系统收到查询 Q ,它将始终为该查询生成答案。这不应与“高可用性”相混淆,这不是要具有处理更高查询量的能力,而是要拒绝回答。

分区容限::尽管存在分区,系统仍继续运行。这不是要具有“修复”分区的机制,而是要容忍该分区,即尽管存在分区也要继续操作。

请注意,以下示例并未涵盖所有可能的情况。请考虑以下标题:

enter image description here

CP 的示例:

enter image description here

该系统具有分区容忍性,因为尽管存在分区,它的节点仍继续接受请求;这是一致的,因为提供答案的唯一节点是那些与处理所有写请求的主节点保持连接的节点;它不可用,因为另一个分区中的节点未提供对它们收到的查询的答案。

AP的示例:

enter image description here

要么是因为(分别)我们有从属节点响应请求,而不管它们是否能够到达主节点,或者是因为另一个分区中的从属节点选择了一个新的主节点,或者是因为我们有了一个无主节点的集群,所以实现了可用性是因为所有问题正在得到答案-一致性下降,因为两个分区都在答复,同时可能产生不同的状态。

CA的示例:

enter image description here

如果在发生分区时断开节点的连接,我们可以确保最多有一个分区,这最终意味着网络不再分区,或者根本就没有服务。这与分区容限相反,因为系统会避免分区而不管其正常运行。在这些部分或完全断开连接的系统中,一致性和可用性保持不变,因为所有工作节点(如果有)都具有相同的状态,并且所有收到的查询(如果有)都将得到答案-关机节点不会收到查询。

回答问题:

  1. 在默认配置下,诸如Cassandra和MongoDB之类的数据库具有分区容忍性,因为它们不关闭节点以应付分区,而MySQL等RDBMS则可以。

  2. 可用性与主/从设置几乎没有关系,例如Cassandra是无主的,并且非常有用,因为哪个节点死亡并不重要。至于主/从设置中的可用性,没有理由在主服务器死后停止响应所有查询,但是您可能需要在选择新查询时暂停写操作。

答案 2 :(得分:0)

我同意RDBMS可以具有CAP的所有属性。我已经开始研究noSQL DB,并且具有IBM DB2的经验。

这是IBM DB2满足所有3个CAP属性的方式

  1. C:一致性:由于RDBMS的事务性,每个关系数据库都满足此要求。

  2. A:可用性:可用性是指对存在的数据进行查询时,应将其返回。再次,关系数据库被设计为容易做到这一点。

  3. P:分区容限:这是最有趣的分区。从DB2的角度来看,在我正在处理的应用程序中,我们有两个分布在不同数据中心的数据库。一个是主要对象,并通过心跳与次要对象进行通信。这些主数据库和辅助数据库中的每一个都有12个物理实例,这些数据是根据一些预定义的逻辑分配数据的。如果主服务器出现故障,则辅助服务器会检测到这一情况并取代主服务器。由于主要和次要始终保持同步,因此数据也保持一致。

这就是我认为RDBMS满足CAP定理的所有3个属性。

我可能是错的,并且可以对此进行讨论。

答案 3 :(得分:0)

CAP定理是有问题的,它仅适用于分布式数据库系统。当您具有分布式数据库时,则可能发生网络分区和节点崩溃。并且当发生网络分区时,您必须具有分区容限(CAP的P)。

因此,回答您的问题编号1)是CP或AP。可以按照Will所述进行配置。

有关为什么必须要有分区容限的更多信息: https://codahale.com/you-cant-sacrifice-partition-tolerance/

有关CAP定理的更多问题: https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html