什么是CouchDB复制协议？是不是像Git？

Question

是否有技术文档描述两个Couches之间的复制是如何工作的？

CouchDB复制的基本概述是什么？有什么值得注意的特点呢？

Answer 1

遗憾的是,没有详细的文档描述复制协议.CouchDB中只有参考实现,Filipe Manana对其进行了重写,这可能会成为未来的新实现.

但是,这是一般的想法:

关键点

如果您了解Git,那么您就知道Couch复制的工作原理.复制与使用像Git这样的分布式源管理器推送或拉动非常相似.

CouchDB复制没有自己的协议.复制器只是作为客户端连接到两个DB,然后从一个读取并写入另一个.推送复制是读取本地数据并更新远程数据库; 拉复制反之亦然.

• 有趣的事实1:复制器实际上是一个独立的Erlang应用程序,在它自己的过程中.它连接到两个沙发,然后从一个读取记录并将它们写入另一个.
• 有趣的事实2:CouchDB 无法知道谁是普通客户端以及谁是复制者(更不用说复制是推还是拉).这看起来像客户端连接.其中一些人读了记录.他们中的一些人写了记录.

一切都来自数据模型

复制算法是微不足道的,无趣的.受过训练的猴子可以设计它.它很简单,因为聪明才是数据模型,它具有以下有用的特性:

1. CouchDB中的每条记录都完全独立于其他记录.如果你想做一个JOIN或一个交易,这很糟糕,但如果你想写一个复制器,它真棒.只需弄清楚如何复制一条记录,然后为每条记录重复一次.
2. 与Git一样,记录具有链表修订历史记录.记录的修订ID是其自身数据的校验和.后续修订ID是以下校验和:新数据,以及前一个的修订ID.

3. 除了应用程序数据({"name": "Jason", "awesome": true})之外,每条记录还存储所有先前修订版ID的演化时间轴.

   • 练习:花一点时间静静思考.考虑任何两个不同的记录,A和B.如果A的修订ID出现在B的时间轴中,那么B肯定是从A演变而来.现在考虑Git的快进合并.你听到了吗？这就是你的心灵被吹的声音.

4. Git不是一个真正的线性列表.当一方父母有多个孩子时,它有分叉.CouchDB也有.

   • 练习:比较两个不同的记录,A和B. A的修订ID不会出现在B的时间轴中; 然而,一个修订ID,C,是在两个 A和B的时间线.因此A不是从B.进化而来的.B不是从A演化而来的.而是,A和B有一个共同的祖先C.在Git中,这是一个"分叉".在CouchDB中,这是一场"冲突".

   • 在Git,如果两个孩子都继续独立开发他们的时间表,这很酷.福克斯完全支持这一点.

   • 在CouchDB中,如果两个孩子继续独立开发他们的时间表,那也很酷.冲突完全支持这一点.
   • 有趣的事实3: CouchDB"冲突"与Git"冲突"不对应.Couch冲突是一个不同的修订历史,Git称之为"分叉".由于这个原因,CouchDB的社会宣告"冲突"与无声Ñ:"共同轻弹".

5. 当一个孩子有多个父母时,Git也有合并.CouchDB的那种具有太多.

   • 在数据模型中,没有合并.客户端只是将一个时间轴标记为已删除,并继续使用唯一的现有时间轴.
   • 在应用程序中,感觉就像合并.通常,客户端以特定于应用程序的方式合并来自每个时间轴的数据.然后它将新数据写入时间线.在Git中,这就像复制并粘贴从分支A到分支B的更改,然后提交到分支B并删除分支A. 数据已合并,但没有git merge.
   • 这些行为是不同的,因为在Git中,时间轴本身很重要; 但是在CouchDB中,数据非常重要,而且时间轴是偶然的 - 它只是支持复制.这就是为什么CouchDB的内置修订不适合存储维基页面等修订数据的原因之一.

最后的笔记

本文中至少有一个句子(可能是这一个)是完整的BS.

Answer 2

感谢杰森的出色概述!正在研究TouchDB及其Couchbase复制的Jens Alfke已经(非正式地)描述了CouchDB复制算法本身,如果您对"标准"CouchDB复制器协议如何工作的技术细节感兴趣.

总结他概述的步骤:

1. 弄清楚以前的复制有多远
2. _changes从那时起获取源数据库
3. 用于revs_diff批量更改以查看目标上需要哪些更改
4. 将任何缺少的修订元数据和当前文档数据+附件从源复制到目标,发布到bulk_docs两者以进行优化,以便以不同于通常的更高级别MVCC处理的方式存储文档PUT.

我在这里略过了许多细节,并建议阅读原始解释.

Answer 3

CouchDB v2.0.0的文档更广泛地涵盖了复制算法。他们有图表、示例中间响应和示例错误。他们使用 IETF RFC 的“MUST”、“SHALL”等语言。

2.0.0（截至 2016 年 1 月仍未发布）的细节与 1.x 略有不同，但基础仍然如@natevw 所述。