什么是CouchDB复制协议？它是否像Git？ [英] What is the CouchDB replication protocol? Is it like Git?

问题描述

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

CouchDB复制的基本概述是什么？关于它的一些值得注意的特性是什么？

解决方案

不幸的是，没有描述复制协议的详细文档。 CouchDB中只有内置的参考实现，Filipe Manana重写相同的内容，可能会成为未来的新实现。

然而，这是总体思路：

要点

如果您了解Git，那么您就知道Couch复制的工作原理。 / strong>复制类似于使用分布式源代码管理器（如Git）进行推送或拉取。

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

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

一切从数据模型流出

复制算法是微不足道的，无趣。训练有素的猴子可以设计它。这很简单，因为聪明就是数据模型，它具有以下有用的特性：

1. CouchDB中的每条记录都完全独立于所有其他记录。如果你想要做一个 JOIN 或者一个事务，这很糟糕，但是如果你想写一个复制器，这真是太棒了。只需找出如何复制 one 记录，然后对每条记录重复 。
   
2. 就像Git一样，列表修订历史。记录的修订ID是其自己数据的校验和。除了应用程序数据（）之外，后续修订标识是新数据的校验和，以及前一版本的修订标识。 Jason，awesome：true} ），每个记录都存储所有先前版本ID的进化时间线。
   
3. 练习：花点时间静静思考。考虑任何两个不同的记录，A和B.如果A的修订ID出现在B的时间轴中，那么B肯定是从A发展而来。现在考虑Git的快速合并。你听到了吗？这是您的头脑被吹响的声音。
Git并不是一个真正的线性列表。它有叉，当一个父母有多个孩子时。 CouchDB也是如此。
A比较两个不同的记录A和B. ID不会出现在B的时间轴上;然而，一个版本ID C在 A和B的时间轴中。因此A不是从B发展而来的。B不是从A发展而来的。而是A和B有一个共同的祖先C.在Git中，这是一个分叉。在CouchDB中，这是一个冲突。 在Git中，如果两个孩子都继续独立开发时间表，那很酷。 Forks完全支持这一点。


4. 在CouchDB中，如果两个孩子都继续独立开发时间表，那也很酷。冲突完全支持这一点。


5. 有趣的事实3： CouchDB冲突不符合Git冲突。沙发冲突是一个不同的修订历史，Git称之为分叉。出于这个原因，CouchDB社区用无声的 n 发音为冲突：共同轻弹。




6. 当一个孩子有多个父母时，Git也会合并。 CouchDB 类的也有。

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

   最后笔记

   
   
   

   此书写中至少有一个句子（可能是这个）是完整的BS。

   
   

   Is there technical documentation describing how replication between two Couches works?

   What is the basic overview of CouchDB replication? What are some noteworthy characteristics about it?

   解决方案

   Unfortunately there is no detailed documentation describing the replication protocol. There is only the reference implementation built into CouchDB, and Filipe Manana's rewrite of the same which will probably become the new implmentation in the future.

   However, this is the general idea:

   Key points

   If you know Git, then you know how Couch replication works. Replicating is very similar to pushing or pulling with distributed source managers like Git.

   CouchDB replication does not have its own protocol. A replicator simply connects to two DBs as a client, then reads from one and writes to the other. Push replication is reading the local data and updating the remote DB; pull replication is vice versa.

   • Fun fact 1: The replicator is actually an independent Erlang application, in its own process. It connects to both couches, then reads records from one and writes them to the other.
   • Fun fact 2: CouchDB has no way of knowing who is a normal client and who is a replicator (let alone whether the replication is push or pull). It all looks like client connections. Some of them read records. Some of them write records.

   Everything flows from the data model

   The replication algorithm is trivial, uninteresting. A trained monkey could design it. It's simple because the cleverness is the data model, which has these useful characteristics:

   1. Every record in CouchDB is completely independent of all others. That sucks if you want to do a JOIN or a transaction, but it's awesome if you want to write a replicator. Just figure out how to replicate one record, and then repeat that for each record.
   2. Like Git, records have a linked-list revision history. A record's revision ID is the checksum of its own data. Subsequent revision IDs are checksums of: the new data, plus the revision ID of the previous.

   3. In addition to application data ({"name": "Jason", "awesome": true}), every record stores the evolutionary timeline of all previous revision IDs leading up to itself.

      • Exercise: Take a moment of quiet reflection. Consider any two different records, A and B. If A's revision ID appears in B's timeline, then B definitely evolved from A. Now consider Git's fast-forward merges. Do you hear that? That is the sound of your mind being blown.

   4. Git isn't really a linear list. It has forks, when one parent has multiple children. CouchDB has that too.

      • Exercise: Compare two different records, A and B. A's revision ID does not appear in B's timeline; however, one revision ID, C, is in both A's and B's timeline. Thus A didn't evolve from B. B didn't evolve from A. But rather, A and B have a common ancestor C. In Git, that is a "fork." In CouchDB, it's a "conflict."

      • In Git, if both children go on to develop their timelines independently, that's cool. Forks totally support that.

      • In CouchDB, if both children go on to develop their timelines independently, that cool too. Conflicts totally support that.
      • Fun fact 3: CouchDB "conflicts" do not correspond to Git "conflicts." A Couch conflict is a divergent revision history, what Git calls a "fork." For this reason the CouchDB community pronounces "conflict" with a silent n: "co-flicked."

   5. Git also has merges, when one child has multiple parents. CouchDB sort of has that too.

      • In the data model, there is no merge. The client simply marks one timeline as deleted and continues to work with the only extant timeline.
      • In the application, it feels like a merge. Typically, the client merges the data from each timeline in an application-specific way. Then it writes the new data to the timeline. In Git, this is like copying and pasting the changes from branch A into branch B, then commiting to branch B and deleting branch A. The data was merged, but there was no git merge.
      • These behaviors are different because, in Git, the timeline itself is important; but in CouchDB, the data is important and the timeline is incidental—it's just there to support replication. That is one reason why CouchDB's built-in revisioning is inappropriate for storing revision data like a wiki page.

   Final notes

   At least one sentence in this writeup (possibly this one) is complete BS.

   这篇关于什么是CouchDB复制协议？它是否像Git？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！