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

Question

从CouchDB指南 ：

对于大多数数据库而言，在单个数据库节点内维护一致性相对容易。 当您尝试维护多个数据库服务器之间的一致性时，真正的问题开始浮出水面。 如果客户端在服务器A上执行写操作，我们如何确保它与服务器B或C或D一致？ 对于关系数据库而言，这是一个非常复杂的问题，整本书都专门针对其解决方案。 您可以使用多主服务器，主/从服务器，分区，分片，直写式缓存以及各种其他复杂技术。

为什么在关系模型中很难维护数据库服务器之间的一致性？ 为什么CouchDB方法变得越来越简单？

Answer 1

Couch通过两种方式简化了这一过程。

首先，它具有系统内置并由系统强制执行的更高级别的复制模型。

其次，它的数据元素更粗糙，从而减少了乐观锁定和冲突解决方案模型的使用。

通常，RDBMS本身不支持乐观锁定。 建立在它们之上的许多框架都可以，但是DBMS本身却不能。 有些人可能会在内部支持它，但如果这样做，最终用户就不会知道。

Couch固有地支持开放式锁定/版本控制，并依赖其进行复制。

在RDBMS中，大多数较大顺序的数据项被分解为它们的标准化关系组件。 一个简单的订单很可能由六个表组成，每个表都有自己的行结构。 但是表及其关系的组合才构成“订单”。 考虑到订单的这种细粒度表示，数据库很难在更高级别上捕获“更改”的概念。 “订单已更改”是什么意思？ 数据库看到的是节点和关系的集合，而不是诸如“ orders”之类的高阶元对象。

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

现在，如果您要复制整个数据库，那么就不成问题了，但是如果要复制数据库的一部分，则要复杂得多。

例如，在Couch中，订单是整个文档。 更改文档，整个订单“更改”，因此整个订单被复制。 在RDBMS中，如果订单项发生更改，那么很容易检测到某行发生了更改，但这是否意味着“订单”已更改？ 如果订单所指的项目发生更改怎么办？ 您会看到情况变得越来越复杂。

所有这些都可以在RDBMS之上构建，但是，应用程序是在进行变更管理并促进复制，而不是数据库。

但是，无论CouchDB提供什么支持，它都只能走得那么远，并且在引号中突出了警告：

如果在复制过程中两个版本的文档发生冲突，则胜出版本将另存为文档历史记录中的最新版本。 CouchDB不会像您期望的那样丢掉丢失的版本，而是将其保存为文档历史记录中的先前版本，以便您可以在需要时访问它。 这是自动且一致地发生的，因此两个数据库将做出完全相同的选择。

由您决定以对您的应用程序有意义的方式来处理冲突 。 您可以将选定的文档版本保留在原位，还原为较旧的版本，或者尝试合并两个版本并保存结果。

在复制过程中，Couch仅具有确定性的规则即可使两个系统保持一致。 但是一致并不能使它们正确。 当Couch检测到两个有冲突的文档时，它将确定地选择一个，获胜者将在失败者身上脚。 但是就您的申请而言，失败者可能是“正确的”，或者正确的文档是两个文档的融合。

您必须编写该逻辑来处理那些合并。 这是所有主-主复制方案的基本问题。 确定“谁获胜”的技术。 当对数据的外观有不同的意见时，“现在是什么”问题到达了相同的十字路口。

没有系统可以为您解决这个问题。 系统所能做的就是选择遵循的规则集，或者让您配置以处理问题，因为问题几乎总是取决于应用程序。

如果Couch支持并为您设计的更简单的模型能够正常工作，那太好了。 如果不是这样，那么您就有点卡住了。 许多RDBMS都是主从复制的可靠支持，因为它是一个更简单的模型，有了这种支持，它对最终用户应用程序几乎是透明的。