Что такое протокол репликации CouchDB? Это как Git?

к сожалению, нет подробной документации, описывающей протокол репликации. Существует только эталонная реализация, встроенная в CouchDB, и переписывание Filipe Manana того же самого, которое, вероятно, станет новой имплментацией в будущем.

однако, это общая идея:

ключевые моменты

если вы знаете Git, то вы знаете, как работает репликация дивана. репликация-это очень подобный нажимать или тянет с распределенными менеджерами источников, такими как Git.

репликация CouchDB не имеет собственного протокола. репликатор просто подключается к двум DBs в качестве клиента, затем читает из одного и записывает в другой. Push-репликация считывает локальные данные и обновляет удаленную БД; pull-репликация-наоборот.

• забавный факт 1: репликатор на самом деле является независимым приложением Erlang, в своем собственном процессе. Он соединяется с оба дивана, затем считывает записи с одного и записывает их на другой.
• забавный факт 2: в CouchDB имеет не знал кто является обычным клиентом, а кто репликатором (не говоря уже о том, является ли репликация push или pull). Все это похоже на клиентские связи. Некоторые читали записи. Некоторые из них пишут отчеты.

все вытекает из модели данных

алгоритм репликации тривиален, неинтересен. Ля дрессированная обезьяна могла бы создать его. Это просто потому, что умность-это модель данных, которая имеет следующие полезные характеристики:

1. каждая запись в CouchDB полностью независима от всех других. Это отстой, если вы хотите сделать JOIN или транзакция, но это потрясающе, если вы хотите написать репликатор. Просто выяснить, как реплицировать один и повторить для каждой записи.
2. как Git, записи имеют история изменений связанного списка. Идентификатор ревизии записи-это контрольная сумма собственных данных. Последующие идентификаторы ревизий являются контрольными суммами: новых данных плюс идентификатор предыдущей ревизии.

3. В дополнение к данным приложения ({"name": "Jason", "awesome": true}), каждая запись хранит эволюционную временную шкалу всех предыдущих идентификаторов версий, ведущих к себе.

   • упражнение: возьмите момент Тихого размышления. Рассмотрим любые две разные записи, A и B. Если A идентификатор ревизии появляется на временной шкале B, затем B определенно эволюционировал из A. Теперь рассмотрим быстрые слияния Git. Ты слышишь? Это звук взрыва твоего разума.

4. Git на самом деле не линейный список. У него есть вилки, когда у одного родителя несколько детей. У CouchDB тоже есть это.

   • упражнение: сравните две разные записи, идентификатор ревизии A и B. A не отображается на временной шкале B; однако один идентификатор редакции, C, находится в и и график "Б". Таким образом, а не эволюционировало из в. б не эволюционировало из А. а скорее, А и В имеют общего предка С. В Git, то есть "вилку"."В CouchDB это" конфликт."

   • в Git, если оба ребенка продолжают развивать свои временные рамки независимо, это круто. Вилки полностью поддерживают это.

   • в CouchDB, если оба ребенка продолжают развивать свои временные рамки независимо, это тоже круто. Рознь полностью поддерживаю.
   • забавный факт 3: CouchDB "конфликты"не соответствуют конфликтам Git."Конфликт дивана-это дивергентная история изменений, которую Git называет "вилкой"."По этой причине сообщество CouchDB произносит "конфликт" с молчаливым n: "co-flicked."

5. Git также имеет слияния, когда один ребенок имеет нескольких родителей. В CouchDB вроде есть что тоже.

   • в модели данных, нет слияния. клиент просто отмечает одну временную шкалу как удаленную и продолжает работать с единственной существующей временной шкалой.
   • в приложения, это похоже на слияние. как правило, клиент сливает сведения из каждой шкале в зависимости от приложения. Тогда он пишет Новое сведения к временной шкале. В Git это похоже на копирование и вставку изменений из ветвь A в ветвь B, затем фиксация в ветвь B и удаление ветви A. сведения слился, но не было git merge.
   • это поведение отличается тем, что в Git важна сама временная шкала; но в CouchDB данные важны, а временная шкала случайна-она просто поддерживает репликацию. Это одна из причин, почему встроенный пересмотр CouchDB не подходит для хранения данных ревизии, таких как wiki страница.

конечные ноты

по крайней мере одно предложение в этой записи (возможно, это) является полным BS.