Ответ 1
К сожалению, нет подробной документации, описывающей протокол репликации. В CouchDB есть только эталонная реализация, и Filipe Manana переписывает то же самое, что, вероятно, станет новым внедрением в будущем.
Однако, это общая идея:
Ключевые моменты
Если вы знаете Git, то знаете, как работает репликация Couch. Репликация очень похожа на нажатие или вытягивание с помощью распределенных исходных менеджеров, таких как Git.
Репликация CouchDB не имеет собственного протокола. Репликатор просто подключается к двум БД в качестве клиента, затем читает с одного и записывает в другой. Репликация Push - это чтение локальных данных и обновление удаленного БД; репликация тиража - это наоборот.
- Забавный факт 1. Репликатор на самом деле является независимым приложением Erlang в своем собственном процессе. Он подключается к обеим кушеткам, затем считывает записи из одного и записывает их в другой.
- Забавный факт 2: CouchDB не имеет возможности узнать, кто является обычным клиентом и кто является репликатором (не говоря уже о том, является ли репликация толчком или тягой). Все это похоже на клиентские подключения. Некоторые из них читают записи. Некоторые из них записывают записи.
Все течет из модели данных
Алгоритм репликации тривиальный, неинтересный. Обученная обезьяна могла его спроектировать. Это просто, потому что умность - это модель данных, которая имеет эти полезные характеристики:
- Каждая запись в CouchDB полностью независима от всех остальных. Это отстой, если вы хотите сделать
JOINили транзакцию, но это потрясающе, если вы хотите написать репликатор. Просто выясните, как копировать одну запись, а затем повторите это для каждой записи. - Как и Git, записи имеют историю изменений связанного списка. Идентификатор ревизии записи - это контрольная сумма его собственных данных. Последующие идентификаторы ревизий представляют собой контрольные суммы: новых данных, а также идентификатор ревизии предыдущего.
-
В дополнение к данным приложения (
{"name": "Jason", "awesome": true}) каждая запись хранит эволюционную шкалу всех предыдущих идентификаторов ревизий, ведущих к себе.- Упражнение: Сделайте минутку спокойного размышления. Рассмотрим любые две разные записи: A и B. Если идентификатор ревизии появляется на временной шкале B, то B определенно эволюционировал от A. Теперь рассмотрим Git сглаживание быстрой перемотки вперед. Ты слышал это? Это звук вашего разума.
-
Git на самом деле не является линейным списком. У него есть вилки, когда у одного родителя есть несколько детей. У CouchDB тоже есть.
-
Упражнение: Сравните две разные записи: A и B. Идентификатор версии не отображается на временной шкале B; однако, один идентификатор ревизии, C, находится как в временной шкале A, так и в B. Таким образом, A не эволюционировал из B. B не эволюционировал от A. Но скорее, A и B имеют общего предка C. В Git, это "вилка". В CouchDB это "конфликт".
-
В Git, если оба ребенка продолжат разрабатывать свои временные рамки самостоятельно, это круто. Форки полностью поддерживают это.
- В CouchDB, если оба ребенка продолжат развивать свои временные рамки самостоятельно, это тоже круто. Конфликты полностью поддерживают это.
- Интересный факт 3: CouchDB "конфликты" не соответствуют конфликтам Git ". Контекст Couch - это расходящаяся история изменений, что Git вызывает" fork". По этой причине сообщество CouchDB произносит "конфликт" с молчаливым n: "co-flicked".
-
-
Git также имеет слияния, когда у одного ребенка есть несколько родителей. У CouchDB тоже есть это.
- В модели данных нет слияния. Клиент просто отмечает одну временную шкалу как удаленную и продолжает работать с единственной временной шкалой.
- В приложении это похоже на слияние. Обычно клиент объединяет данные с каждой временной шкалы в зависимости от приложения. Затем он записывает новые данные на график. В Git это похоже на копирование и вставку изменений из ветки A в ветвь B, затем переход к ветки B и удаление ветки A. Данные были объединены, но не было
git merge. - Эти поведения различны, потому что в Git важна сама шкала времени; но в CouchDB данные важны, а временная шкала - случайная, она просто поддерживает репликацию. Это одна из причин, почему встроенная ревизия CouchDB не подходит для хранения данных ревизий, таких как страница вики.
Заключительные примечания
По крайней мере одно предложение в этой записи (возможно, это одно) является полным BS.