Co to jest protokół replikacji CouchDB? To jak Git?

Niestety nie ma szczegółowej dokumentacji opisującej protokół replikacji. W CouchDB jest wbudowana tylko implementacja referencyjna, a przepisanie tego samego przez Filipe Manana, które prawdopodobnie stanie się nową implmentacją w przyszłości.

Jest to jednak ogólna idea:

Kluczowe punkty

Jeśli znasz Gita, to wiesz jak działa replikacja Couch. replikacja jest bardzo podobna do pchania lub ciągnięcia z rozproszonym źródłem menedżerowie jak Git.

Replikacja CouchDB nie posiada własnego protokołu.Replikator po prostu łączy się z dwoma DBs jako klient, a następnie odczytuje z jednego i zapisuje do drugiego. Replikacja Push to odczyt lokalnych danych i aktualizacja zdalnego DB; replikacja pull jest odwrotnie.

• ciekawostka 1 : replikator jest w rzeczywistości niezależną aplikacją Erlanga, w swoim własnym procesie. Łączy się z obydwoma kanałami, następnie odczytuje rekordy z jednego i zapisuje je do drugi.
• ciekawostka 2 : CouchDB nie ma możliwości poznania, Kto jest zwykłym klientem, a kto replikatorem (nie mówiąc już o tym, czy replikacja jest push czy pull). To wszystko wygląda na powiązania z klientami. Niektórzy czytają płyty. Niektórzy piszą płyty.

Wszystko wypływa z modelu danych

Algorytm replikacji jest trywialny, nieciekawy. Wytrenowana małpa mogłaby to zaprojektować. To proste, ponieważ sprytem jest model danych, który posiada te użyteczne cechy:

Każdy zapis w CouchDB jest całkowicie niezależny od wszystkich innych. To jest do bani, jeśli chcesz zrobić JOIN lub transakcję, ale to jest niesamowite, jeśli chcesz napisać replikator. Po prostu wymyśl, jak odtworzyć jeden rekord , a następnie powtórz ten dla każdego rekordu.
1. podobnie jak Git, rekordy mają historię rewizji linked-list. Identyfikator rewizji rekordu jest sumą kontrolną jego własnych danych. Kolejne identyfikatory rewizji są sumami kontrolnymi: nowe dane oraz identyfikator wersji poprzedniej.

2. Oprócz danych aplikacji ({"name": "Jason", "awesome": true}), każdy rekord przechowuje ewolucyjną oś czasu wszystkich poprzednich identyfikatorów wersji prowadzących do siebie.

   • ćwiczenie : poświęć chwilę spokojnej refleksji. Rozważ dowolne dwa różne rekordy, A I B. Jeśli identyfikator rewizji A pojawi się w osi czasu B, to B zdecydowanie ewoluował od A. teraz rozważ szybkie scalanie Gita. Słyszysz to? To jest dźwięk twojego umysłu być spalonym.
3. Git nie jest liniową listą. Ma widelce, gdy jeden rodzic ma wiele dzieci. CouchDB też to ma.

   • ćwiczenie : Porównaj dwa różne rekordy, A I B. identyfikator rewizji A nie pojawia się w osi czasu B; jednak jeden identyfikator rewizji, C, znajduje się w zarówno, jak i w osi czasu B. Tak więc A nie wyewoluowało z B. B nie wyewoluowało z A. ale raczej, A i B mają wspólnego przodka C. W Git, to jest " widelec."W CouchDB, to " konflikt."

   • W Git, jeśli oboje dzieci rozwijają swoje linie czasowe niezależnie, to super. Widelce to popierają.

   • W CouchDB, jeśli oboje dzieci rozwijają swoje linie czasowe niezależnie, to też fajne. Konflikty całkowicie to popierają.
   • ciekawostka 3: CouchDB "konflikty" nie odpowiadają "konfliktom Git"."Konflikt kanapowy to rozbieżna historia rewizji, co Git nazywa "fork"."Z tego powodu CouchDB community wymawia " conflict "z cichym n:" co-flicked."

4. Git ma również połączenia, gdy jedno dziecko ma wielu rodziców. CouchDB tak jakby też tak ma.

   • w modelu danych nie ma scalania. klient po prostu zaznacza jedną oś czasu jako usuniętą i kontynuuje pracę z jedyną istniejącą osią czasu.
   • w aplikacji, czuje się jak połączenie. zazwyczaj klient łączy dane z każdej osi czasu w sposób specyficzny dla aplikacji. Następnie zapisuje nowe dane do osi czasu. W Git jest to jak kopiowanie i wklejanie zmian z gałęzi a do gałęzi B, a następnie dołączanie do gałęzi B i usuwanie gałęzi A. dane zostały scalone, ale nie było git merge.
   • te zachowania są różne, ponieważ w Git sama oś czasu jest ważna; ale w CouchDB dane są ważne, a oś czasu jest przypadkowa-jest po prostu tam, aby wspierać replikację. Jest to jeden z powodów, dla których wbudowana rewizja CouchDB jest nieodpowiednia do przechowywania danych rewizji, takich jak strona wiki.

Uwagi końcowe

Co najmniej jedno zdanie w tym writeup (prawdopodobnie to) jest pełne BS.