CouchDB i wersjonowanie dokumentów

12

Obecnie pracuję nad aplikacją typu wiki za pomocą CouchDB i próbuję wdrożyć schemat wersjonowania dokumentów. Widzę to na dwa sposoby:

  1. Przechowuj każdą wersję jako osobny dokument
  2. Przechowuj starsze wersje jako załączniki do jednego dokumentu.

W tej chwili mam formę # 1 działającą. Gdy użytkownik edytuje dokument i zapisuje go, zaplecze najpierw kopiuje poprzednią wersję do nowego dokumentu, a następnie zapisuje nową wersję. Każdy dokument ma tablicę „historii”, która zawiera dane dotyczące każdej wersji (identyfikator _id starej wersji, znacznik czasu, edytor itp.).

Ponieważ ta tablica historii może być dość długa dla często aktualizowanego dokumentu, mam widok, który pobiera dokument bez historii podczas normalnego odczytu (i inny widok do pobierania historii).

Moje pytanie brzmi: czuję się zaniepokojony moim obecnym podejściem i zastanawiałem się nad przejściem na metodę „przywiązania”. Ale nie jestem pewien. Mam nadzieję, że ktoś, kto zna CouchDB lepiej niż ja (pracuję nad tym dopiero od kilku tygodni - i to jest mój pierwszy projekt z wykorzystaniem CouchDB ... i NoSQL) może mi powiedzieć, jakie są zalety i wady każdego z nich podejście. A może przeoczyłem jakiś inny schemat kontroli wersji?

database-design couchdb James Adam
źródło
2
Chociaż nie mogę w ogóle mówić o wpływie na wydajność, używany system jest „duchowo” zgodny z CouchDB. Przechowywanie poprzednich wersji jako hierarchii odpowiedzi jest idiomatyczne, podobnie jak w „duchowym przodku” CouchDB, bazie danych dokumentów Lotus Notes (NSF) (Damien Katz głęboko pracował nad jedną z nich, zanim opracował drugą, zachowując i ulepszając to, co najlepsze podrzucając wymagania dotyczące cruft i kompatybilności wstecznej / błędnej, tak wiele bardziej podstawowych pytań strukturalnych będzie zawierało odpowiedzi w Notatkach.)

Odpowiedzi:

2

Zachowywanie tylko zmian będzie dobrym pomysłem, ponieważ przechowywanie starszych dokumentów jako osobnych dokumentów lub załączników do ostatecznej wersji bazy danych spowoduje narzut na serwer bazy danych.

Po każdej zmianie wartości klucza w dokumencie dodaj nowy klucz o nazwie _h_i_s_<key_name>. W nowo utworzonym (lub utworzonym podczas ostatniej aktualizacji) dołączaj obiekty takie jak poniżej po każdej edycji / aktualizacji: -

{
key_name: "Hello",
_h_i_s_key_name:{time_of_update:value_of_key_name_before_update},
....
}

lub

    {
    key_name: "Hello",
    _h_i_s_key_name:[{time:time_of_update,value:value_of_key_name_before_update}, {time:time_of_last_update,value:value_of_key_name_before_last_update}],
    ....
    }

Takie podejście pozwoli zaoszczędzić dużo miejsca na dysku i przepustowości replikacji na dłuższą metę.

Ravinder Payal
źródło
0

Bez znajomości CouchDB. Przechowywanie każdej wersji może jednak różnić się tylko nieznacznie od poprzednika, co jest marnotrawstwem pamięci. Polecam tylko przechowywanie zmian.

Możesz zajrzeć tutaj lub wyszukać wersjonowanie danych.

xuma202
źródło
Ta odpowiedź nie mówi, która z opcji 1 (osobne dokumenty) lub 2 (jako część dokumentu) jest lepsza.
binki
0

lata później ;-)

nie musisz przechowywać zmian, ponieważ CouchDB zrobi to za Ciebie. Jeśli dokument zostanie zmieniony, zostanie utworzona nowa wersja. Pamiętaj, że jest to fizycznie kolejny dokument z tym samym, _idale nowym _rev(rewizja) i zajmie miejsce na dysku.

Na pewno będziesz musiał zachować wszystkie wersje, co oznaczałoby, że potrzebujesz bardzo dużego dysku.

awenkhh
źródło