在单个数据库节点内保持一致性是相对的 大多数数据库都很容易当你真正的问题开始出现 尝试保持多个数据库服务器之间的一致性如果一个 客户端在服务器A上进行写操作，我们如何确保 这与服务器B，或C或D一致？对于关系 数据库，这是一个非常复杂的问题，整本书都致力于 它的解决方案你可以使用多主，主/从，分区， 分片，直写缓存和各种其他复杂的 技术。
为什么在关系模型中维护数据库服务器之间的一致性很困难？为什么CouchDB的方法更简单，更容易？
答案 0 :(得分：1)
Couch以两种方式简化了它。
首先，它具有内置并由系统强制执行的更高级别的复制模型。
其次，它的数据元素更粗糙，使得乐观锁定和冲突解决模型的使用更少。
作为一般规则，RDBMS本身不支持乐观锁定。构建在它们之上的许多框架都可以，但不是DBMS本身。有些人可能会在内部支持它，但如果他们这样做，则不会向最终用户公开。
Couch本质上支持乐观锁定/版本控制，并依赖于它的复制。
在RDBMS中，大多数较大的订单数据项被分解为其规范化的关系组件。一个简单的订单可能由六个表组成，每个表都有自己的行结构。但是表格及其关系的组合构成了“订单”。鉴于订单的这种更精细的颗粒表示，数据库很难在更高层次上捕获“变化”的概念。 “订单变更”是什么意思？数据库看到节点和关系的集合，而不是“订单”等高阶元对象。
应用程序可以定义更改，但不容易定义数据库。
现在，如果您要复制整个数据库，这不是一个问题，但如果您复制数据库的一部分，则会更加复杂。
例如，在Couch中，订单是整个文档。更改文档，整个订单“更改”，从而复制整个订单。在RDBMS中，如果订单项发生变化，那么很容易检测到一行发生了变化，但这是否意味着“订单”发生了变化？如果订单所指的商品发生了变化，这会改变订单吗？你可以看到这变得更加复杂。
所有这些都可以构建在RDBMS之上，但是应用程序正在进行变更管理并促进复制，而不是数据库。
然而，无论CouchDB提供什么支持，它都只能到目前为止，并且引用中突出显示了这一点：
当复制期间文档的两个版本发生冲突时， 获胜版本将保存为文档中的最新版本 历史。而不是像你一样把丢失的版本扔掉 期待，CouchDB将此保存为文档中的先前版本 历史记录，以便您可以在需要时访问它。有时候是这样的 自动且一致，因此两个数据库都将完全准确 同样的选择。
由您自己处理冲突的方式对您有意义 应用。您可以保留所选的文档版本， 恢复到旧版本，或尝试合并两个版本并保存 结果。
在复制过程中，Couch只有确定性规则才能使两个系统保持一致。但一致并不能使它们正确。当Couch检测到两个冲突的文件时，它会确定地选择一个，并且胜利者会对失败者进行踩踏。但就你的申请而言，失败者可能是“正确的”，或者正确的文件是两个文件的融合。
你必须编写那些逻辑处理那些合并。这是所有主 - 主复制方案的基本问题。确定“谁赢”的技术。对于数据应该是什么样的不同意见何时到达相同的十字路口的“现在什么”问题。
没有系统可以为您处理。系统可以做的就是选择它遵循的一些规则，或者让你配置来处理问题，因为问题几乎总是依赖于应用程序。
如果Couch支持的简单模型和适合您的项目有效，那就太棒了。如果没有，那你就有点卡住了。许多RDBMS都支持Master-Slave复制，因为它是一个更简单的模型，并且通过这种支持，它对最终用户应用程序非常透明。