нет подробной документации, описывающей протокол репликации. В CouchDB встроена только эталонная реализация, и Филип Манана переписал ее, что, вероятно, станет новым воплощением в будущем.

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

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

Если вы знаете Git, то знаете, как работает репликация Couch. Репликацияочень похоже на push или pull с распределенными менеджерами исходного кода, такими как Git.

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

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

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

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

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

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

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

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

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

В CouchDB, если оба ребенка продолжают самостоятельно разрабатывать временные рамки, это тоже здорово. Конфликты полностью поддерживают это.Интересный факт 3: "Конфликты" в CouchDB не соответствуют "конфликтам" в Git. Конфликт Couch - это расходящаяся история ревизий, которую Git называет «форком». По этой причине сообщество CouchDB объявляет «конфликт» с молчаливымn: "щелкнуло".

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

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

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