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

Question

来自CouchDB guide :

Maintaining consistency within a single database node is relatively easy for most databases. The real problems start to surface when you try to maintain consistency between multiple database servers. If a client makes a write operation on server A, how do we make sure that this is consistent with server B, or C, or D? For relational databases, this is a very complex problem with entire books devoted to its solution. You could use multi-master, master/slave, partitioning, sharding, write-through caches, and all sorts of other complex techniques.

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

Answer 1

Couch 通过两种方式简化了它。

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

其次，它的数据元素更粗糙，使得乐观锁定和冲突解决模型的工作量更少。

作为一般规则，RDBMS 本身并不支持乐观锁定。许多构建在它们之上的框架都这样做，但 DBMS 本身却不然。有些人可能会在内部支持它，但如果他们这样做，它不会暴露给最终用户。

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

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

应用程序可以定义更改，但数据库则不然。

现在，如果您要复制整个数据库，这并不是什么大问题，但如果您要复制数据库的一部分，则问题会严重得多。

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

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

但是，无论 CouchDB 提供什么支持，它也只能到此为止，并且在引用中强调了这一警告:

When two versions of a document conflict during replication, the winning version is saved as the most recent version in the document’s history. Instead of throwing the losing version away, as you might expect, CouchDB saves this as a previous version in the document’s history, so that you can access it if you need to. This happens automatically and consistently, so both databases will make exactly the same choice.

It is up to you to handle conflicts in a way that makes sense for your application. You can leave the chosen document versions in place, revert to the older version, or try to merge the two versions and save the result.

在复制过程中，Couch 仅具有确定性规则来使两个系统保持一致。但一致并不意味着它们就是正确的。当 Couch 检测到两份存在冲突的文档时，它会确定性地选择一份，然后胜者将败者踩在脚下。但就你的申请而言，失败者可能是“正确的”，或者正确的文件是两个文件的融合。

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

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

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