CouchDBレプリケーションプロトコルとは何ですか？ Gitのようなものですか？

Question

2つのCouche間のレプリケーションがどのように機能するかを説明する技術文書はありますか？

CouchDBレプリケーションの基本的な概要は何ですか？それについていくつかの注目すべき特徴は何ですか？

JasonSmith · Accepted Answer

残念ながら、レプリケーションプロトコルを説明する詳細なドキュメントはありません。 CouchDBに組み込まれているリファレンス実装と、Filipe Mananaによる同じものの書き直しだけがあり、これはおそらく将来的には新しい実装になるでしょう。

ただし、これは一般的な考え方です。

キーポイント

Gitを知っているなら、Couchレプリケーションがどのように機能するかを知っています。レプリケーションは非常に分散ソースマネージャーでプッシュまたはプルするのと似ていますGitのように。

CouchDBレプリケーションには独自のプロトコルがありません。レプリケーターは、クライアントとして2つのDBに接続し、一方から読み取り、もう一方に書き込みます。プッシュレプリケーションは、ローカルデータを読み取り、リモートDBを更新します。プルレプリケーションはその逆です。

おもしろい事実1：レプリケーターは、実際には独自のプロセスで独立したErlangアプリケーションです。両方のソファに接続し、一方からレコードを読み取り、もう一方に書き込みます。
楽しい事実2：CouchDBには誰が通常のクライアントで誰がレプリケーターであるかを知る方法がありませんレプリケーションはプッシュまたはプルです）。それはすべてクライアント接続のように見えます。それらのいくつかはレコードを読みます。それらのいくつかはレコードを書き込みます。

すべてがデータモデルから流れます

レプリケーションアルゴリズムは簡単で、面白くありません。訓練された猿がそれを設計することができます。賢さはデータモデルであり、次のような便利な特性があるため、簡単です。

CouchDBのすべてのレコードは、他のすべてのレコードから完全に独立しています。 JOINまたはトランザクションを実行する場合は問題がありますが、レプリケーターを作成する場合はすばらしいです。 oneレコードを複製する方法を理解してから、それを繰り返します各レコード。
Gitと同様に、レコードにはリンクリストの改訂履歴があります。レコードのリビジョンIDは、それ自体のデータのチェックサムです。後続のリビジョンIDは、新しいデータと前のリビジョンIDのチェックサムです。
アプリケーションデータ（{"name": "Jason", "awesome": true}）に加えて、すべてのレコードには、それ自体に至るまでのすべての以前のリビジョンIDの進化のタイムラインが格納されます。
- 演習：静かに振り返ります。 AとBの2つの異なるレコードについて考えてみます。AのリビジョンIDがBのタイムラインに表示される場合、Bは間違いなくAから進化しています。Gitの早送りマージについて考えてみましょう。聞こえますか？それはあなたの心が吹き飛ばされる音です。
Gitは実際には線形リストではありません。 1人の親に複数の子がある場合、フォークがあります。 CouchDBにもそれがあります。
- Exercise：2つの異なるレコードAとBを比較します。AのリビジョンIDはBのタイムラインに表示されません。ただし、1つのリビジョンID Cは、AとBの両方のタイムラインにあります。したがって、AはBから進化しませんでした。BはAから進化しませんでした。むしろ、AとBには共通の祖先Cがあります。Gitでは、これは「フォーク」です。 CouchDBでは、これは「競合」です。
- Gitでは、両方の子供が独立してタイムラインを作成し続けるのであれば、それはすばらしいことです。フォークはそれを完全にサポートします。
- CouchDBでは、両方の子供が独立してタイムラインを作成し続けると、それもクールです。紛争はそれを完全に裏付けています。
- おもしろ情報3： CouchDBの「競合」はGitの「競合」に対応していません。 Couchの競合は、Gitが「フォーク」と呼んでいる発散的な改訂履歴です。このため、CouchDBコミュニティは「競合」をサイレントn：「co-flicked」と発音します。
1人の子供に複数の親がいる場合、Gitにもマージがあります。 CouchDBsort ofにもそれがあります。
- データモデルでは、マージはありません。クライアントは、1つのタイムラインを削除済みとしてマークするだけで、既存のタイムラインのみで作業を続けます。
- アプリケーションでは、マージのように感じます。通常、クライアントは、アプリケーション固有の各タイムラインからのデータをマージします。仕方。次に、新しいdataをタイムラインに書き込みます。 Gitでは、これはブランチAからブランチBに変更をコピーして貼り付け、次にブランチBにコミットしてブランチAを削除するようなものです。dataがマージされました、しかしgit mergeはありませんでした。
- Gitではタイムライン自体が重要であるため、これらの動作は異なります。しかし、CouchDBでは、データは重要であり、タイムラインは偶発的です。レプリケーションをサポートするためだけにあります。これが、CouchDBの組み込みリビジョンがwikiページのようなリビジョンデータの保存に不適切である理由の1つです。

最終メモ

この記事の少なくとも1つの文（おそらくこれ）は完全なBSです。

natevw · Answer

素晴らしい概要を提供してくれたJasonに感謝します。 TouchDBとCouchbaseのレプリケーションに取り組んでいるJensAlfkeは、「標準」のCouchDBレプリケータープロトコルの傾向の技術的な詳細に興味がある場合は、（非公式に） CouchDBレプリケーションアルゴリズム自体について説明しています。働くために。

彼が概説したステップを要約すると：

以前のレプリケーションがどこまで進んだかを把握する
その時点からソースデータベース_changesを取得します
変更のバッチでrevs_diffを使用して、ターゲットで必要なものを確認します
不足しているリビジョンメタデータと現在のドキュメントデータ+添付ファイルをソースからターゲットにコピーし、最適化とPUTでの通常の高レベルMVCC処理とは異なる方法でドキュメントを保存するためにbulk_docsに投稿します。。