rdbms - 在 CAP 定理中,缩放的关系数据库会落在什么地方?

标签 rdbms cap-theorem

如果您使用一个 DB 用于写入,多个 DB 用于读取来扩展 SQL Server。将数据从写数据库复制到其他读数据库不会有延迟吗?在什么情况下数据不一致?

那么,在 CAP 定理中,缩放关系数据库会落在什么地方?

更新:

在关系数据库中,一致性意味着不会有部分更新。例如,如果有人将钱从一个账户转移到另一个账户,并且整个过程是一次交易的一部分,那么您不会从一个账户中取出钱,但不会出现在另一个账户中。

在 CAP 定理中,一致性意味着所有组件都看到相同的数据。这种一致性不同于 ACID 中的一致性。

据我所知,像 SQL Server 这样的关系数据库应该是 CA(一致且可用)。如果只有一个数据库,这是有意义的。因为每个人都会看到相同的数据。但是,如果 SQL Server 是用多个数据库扩展的呢?在那种情况下,所有数据库仍然会看到相同的数据吗?如果不是,它是否一致(在 CAP 定理中)?

我的感觉是扩展关系数据库是 AP(可用且分区容错)而不是 CA(一致且可用)。

最佳答案

我读过有关 CAP 定理的一致性的不同定义。

  1. 一致性的一些定义说,一旦某些数据持久化在系统中,所有读取都将读取最近写入的数据。在此定义中,如果复制是异步的,则复制数据库(您称其为“缩放”但我不会使用该术语)有返回不一致数据的风险。

    为了减轻这种风险,一些系统确保复制是同步的,或者尽可能接近同步。例如,Galera 将事务写入集同步发送到其副本。如果您尝试从副本读取,并且它检测到有待处理但尚未应用的写入集,它会阻止您的读取,直到它 catch 了待处理的写入集(此行为是可配置的)。因此,您永远不会读取过时的数据。

    以这种方式在分布式系统上维护完全一致的读取的成本通常比用户想要的要高。在更新率高的系统中会成为性能瓶颈。因此,出于实际原因,大多数项目都承认“复制滞后”是一种必要的妥协。

  2. 一致性的其他定义更接近于原子性,即事务不会以部分完成的状态持久化。因此,无论您是在应用事务之前还是之后读取数据,当您读取数据时,所有约束都将得到满足。在这个定义中,很容易想象副本数据库实例保持一致,如果它使用与主实例相同的事务语义来应用更新。如果您从副本读取数据,您可能会读取尚未应用最新更新的数据,但它永远不会处于约束条件不一致的状态。

关于rdbms - 在 CAP 定理中,缩放的关系数据库会落在什么地方?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56332288/

相关文章:

mysql - 我应该在删除行之前每次都使用 MySQL TRIGGER 语句吗?

database - CAP定理或简单英语的布鲁尔定理?

redis - 是否可以检测到客户端断开连接?

database - 是否有用于 ERD 图的 ASCII 生成器?

database - Cloud Foundry 中的数据库实例是什么?

mysql - 什么情况下外键不能为空?

mongodb - mongodb 在 CAP 定理中处于什么位置?

apache-zookeeper - ZooKeeper 在 CAP 定理方面总是一致的吗?

distributed-system - CAP 定理中可用性的一致性

mysql - 复合主键中只有一个键作为外键