К сожалению, нет подробной документации, описывающей протокол репликации.В CouchDB встроена только эталонная реализация, и Филипе Манана переписывает ее, что, вероятно, станет новым воплощением в будущем.
Однако это общая идея:
Ключевые моменты
Если вы знаете Git, то знаете, как работает репликация Couch. Репликация очень похожа на передачу или извлечение с распределенными менеджерами исходного кода, такими как Git.
Репликация CouchDB не имеет своего собственного протокола. Репликатор просто подключается к двум БД в качестве клиента, затем читает из одной и записывает в другую.Push-репликация читает локальные данные и обновляет удаленную БД;pull-репликация выполняется наоборот.
- Интересный факт 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 временной шкалы.Таким образом, A не развился из B. B не развился из A. Но, скорее, A и B имеют общего предка C. В Git это «вилка».В CouchDB это «конфликт».
В Git, если оба ребенка продолжают самостоятельно разрабатывать временные рамки, это круто.Вилы полностью поддерживают это.
- В CouchDB, если оба ребенка продолжают самостоятельно разрабатывать временные рамки, это тоже здорово.Конфликты полностью поддерживают это.
- Забавный факт 3:"конфликты" CouchDB не соответствуют Git "конфликты".Конфликт Couch - это расходящаяся история ревизий, которую Git называет «форком».По этой причине сообщество CouchDB объявляет «конфликт» с тихим n : «co-flicked».
Git также имеет слияния, когда один ребенокимеет несколько родителей.CouchDB вроде также имеет это.
- В модели данных нет слияния. Клиент просто помечает одну временную шкалу как удаленную и продолжает работатьс единственной существующей временной шкалой.
- В приложении это похоже на слияние. Обычно клиент объединяет данные из каждой временной шкалы для конкретного приложения. Затем он записывает новые данные на временную шкалу. В Git это похоже на копирование и вставку изменений из ветви A в ветку B, затем фиксация в ветке B и удаление ветки A. Данные были объединены, но
git merge.
- Это поведение отличается, потому что в Git важна сама временная шкала; но в CouchDB данные важны, а временная шкала является случайной - она просто поддерживает репликацию. Это одна из причин, почему встроенная версия CouchDB не подходит для хранения данных о ревизиях, таких как вики-страница.
Заключительные замечания
По крайней мере одно предложение в этой записи (возможно, это) является полным BS.