CouchDB与关系数据库的分布式一致性？

Question

来自CouchDB指南

对于大多数数据库来说，在单个数据库节点内保持一致性相对容易。当您试图维护多个数据库服务器之间的一致性时，真正的问题就会浮出水面。如果客户端在服务器A上执行写操作，我们如何确保这与服务器B、C或D一致？对于关系数据库来说，这是一个非常复杂的问题，整本书都致力于解决这个问题。您可以使用多主、主/从、分区、切分、写入缓存和其他各种复杂技术。

为什么在关系模型中很难保持数据库服务器之间的一致性？为什么CouchDB方法更简单更容易呢？

Answer 1

沙发以两种方式简化了它。

首先，它有一个更高级别的复制模型，它是在系统中构建和执行的。

其次，它的数据元素更粗，提供了更少使用的乐观锁定和冲突解决模型。

通常情况下，RDBMS不支持乐观锁定。许多构建在它们之上的框架是这样做的，但不是DBMS本身。有些人可能在内部支持它，但如果他们支持，它就不会暴露给最终用户。

长沙发从本质上支持乐观锁定/版本控制，并依赖于此进行复制。

在RDBMS中，大多数较大的顺序数据项被分解为它们的规范化关系组件。一个简单的顺序很可能由六个表组成，每个表都有自己的行结构。但是，表格和它们之间的关系的结合构成了“一个秩序”。考虑到订单的这种更精细的粒度表示，数据库很难在更高的级别捕获“更改”的概念。“命令改变”是什么意思？数据库看到的是节点和关系的集合，而不是像"orders“这样的高阶元对象。

应用程序可以定义更改，但不能很容易地定义数据库。

如果要复制整个数据库，这不是什么问题，但如果要复制数据库的一部分，则要复杂得多。

例如，在Couch中，订单是一个完整的文档。更改文档，整个订单“更改”，从而复制整个订单。在RDBMS中，如果一行项发生了更改，那么很容易检测到一行发生了变化，但这是否意味着“顺序”发生了变化？如果订单所指的项目发生了变化，这会改变订单吗？你可以看到事情是如何变得更加复杂的。

所有这些都可以建立在RDBMS之上，但是接下来是应用程序进行更改管理和促进复制，而不是数据库。

然而，无论CouchDB提供了什么支持，它都只能做到这一点，这一点在引文中得到了强调：

当两个版本的文档在复制期间发生冲突时，获胜版本将保存为文档历史记录中的最新版本。CouchDB没有像您预期的那样丢弃丢失的版本，而是将其保存为文档历史记录中的前一个版本，以便在需要时可以访问它。这是自动和一致的，因此这两个数据库将作出完全相同的选择。 --这取决于您以一种对您的应用程序有意义的方式来处理冲突。您可以保留所选的文档版本，恢复到旧版本，或者尝试合并这两个版本并保存结果。

在复制过程中，Couch简单地使用确定性规则来使两个系统一致。但一致性并不能证明它们是正确的。当Couch检测到两个冲突文件时，它会果断地选择一个，而胜利者则会踩到输家。但就你的申请而言，失败者可能是“正确的”，或者正确的文件是两份文件的融合。

你必须写那个逻辑来处理那些合并。这是所有主主复制方案的一个基本问题。决定“谁赢”的技术。“现在是什么”的问题，当对数据应该是什么样子的不同意见到达相同的十字路口。

没有系统能帮你处理这件事。一个系统所能做的就是选择一些它遵循的规则，或者让您配置来处理这个问题，因为问题几乎总是依赖于应用程序。

如果Couch支持并为您设计的更简单的模型有效，那就太好了。如果没有，那你就被困住了。许多RDBMS对主从复制有坚实的支持，因为它是一个更简单的模型，有了这种支持，它对最终用户应用程序几乎是透明的。