Sposoby wdrażania wersjonowania danych w MongoDB

Czy możesz podzielić się swoimi przemyśleniami, jak zaimplementować przechowywanie wersji danych w MongoDB. (Zadałem podobne pytanie dotyczące Cassandry . Jeśli masz jakieś przemyślenia, która db jest lepsza, proszę podziel się)

Załóżmy, że muszę zaktualizować rekordy w prostej książce adresowej. (Rekordy książki adresowej są przechowywane jako płaskie obiekty Json). Oczekuję, że historia:

• będą używane rzadko
• zostaną wykorzystane naraz, aby przedstawić go w sposób „maszyny czasu”
• na jeden rekord nie będzie więcej niż kilkaset wersji. historia nie wygasa.

Rozważam następujące podejścia:

• Utwórz nową kolekcję obiektów do przechowywania historii rekordów lub zmian w rekordach. Będzie przechowywać jeden obiekt na wersję z odniesieniem do pozycji książki adresowej. Takie zapisy wyglądałyby następująco:

  {
   „_id”: „nowy identyfikator”,
   „użytkownik”: identyfikator_użytkownika,
   „timestamp”: timestamp,
   „address_book_id”: „identyfikator rekordu książki adresowej” 
   „old_record”: {„first_name”: „Jon”, „last_name”: „Doe” ...}
  }
  

  To podejście można zmodyfikować, aby przechowywać tablicę wersji na dokument. Ale wydaje się, że jest to wolniejsze podejście bez żadnych korzyści.

• Przechowuj wersje jako obiekt serializowany (JSON) dołączony do pozycji książki adresowej. Nie jestem pewien, jak dołączyć takie obiekty do dokumentów MongoDB. Być może jako tablica ciągów. ( Modelowane na podstawie prostej wersji dokumentów za pomocą CouchDB )

Pierwszym ważnym pytaniem podczas nurkowania jest „jak chcesz przechowywać zestawy zmian” ?

1. Różnice?
2. Całe kopie płyt?

Moim osobistym podejściem byłoby przechowywanie różnic. Ponieważ wyświetlanie tych różnic jest naprawdę specjalną akcją, umieściłbym różnice w innej kolekcji „historii”.

Chciałbym użyć innej kolekcji, aby zaoszczędzić miejsce w pamięci. Zwykle nie potrzebujesz pełnej historii dla prostego zapytania. Tak więc, utrzymując historię poza obiektem, możesz również trzymać ją poza pamięcią, do której często uzyskiwany jest dostęp, gdy dane są sprawdzane.

Aby ułatwić moje życie, stworzyłbym dokument historyczny zawierający słownik różnic znaczników czasu. Coś takiego:

{
    _id : "id of address book record",
    changes : { 
                1234567 : { "city" : "Omaha", "state" : "Nebraska" },
                1234568 : { "city" : "Kansas City", "state" : "Missouri" }
               }
}

Aby moje życie było naprawdę łatwe, uczyniłbym tę część moich obiektów DataObject (EntityWrapper, cokolwiek), których używam do uzyskiwania dostępu do moich danych. Zasadniczo obiekty te mają pewną formę historii, dzięki czemu można łatwo zastąpić save()metodę, aby wprowadzić tę zmianę w tym samym czasie.

AKTUALIZACJA: 2015-10

Wygląda na to, że istnieje teraz specyfikacja do obsługi różnic JSON . To wydaje się być bardziej niezawodnym sposobem przechowywania różnic / zmian.

Istnieje schemat kontroli wersji o nazwie „Vermongo”, który dotyczy niektórych aspektów, które nie zostały omówione w innych odpowiedziach.

Jednym z tych problemów są jednoczesne aktualizacje, drugim jest usuwanie dokumentów.

Vermongo przechowuje kompletne kopie dokumentów w kolekcji cieni. W niektórych przypadkach może to powodować zbyt duże obciążenie, ale myślę, że upraszcza to również wiele rzeczy.

https://github.com/thiloplanz/v7files/wiki/Vermongo

Oto inne rozwiązanie wykorzystujące jeden dokument dla bieżącej wersji i wszystkich starych wersji:

{
    _id: ObjectId("..."),
    data: [
        { vid: 1, content: "foo" },
        { vid: 2, content: "bar" }
    ]
}

datazawiera wszystkie wersje. dataTablica jest uporządkowane , nowe wersje dostanie tylko $pushed do końca tablicy. data.vidto identyfikator wersji, który jest liczbą rosnącą.

Pobierz najnowszą wersję:

find(
    { "_id":ObjectId("...") },
    { "data":{ $slice:-1 } }
)

Uzyskaj konkretną wersję przez vid:

find(
    { "_id":ObjectId("...") },
    { "data":{ $elemMatch:{ "vid":1 } } }
)

Zwróć tylko określone pola:

find(
    { "_id":ObjectId("...") },
    { "data":{ $elemMatch:{ "vid":1 } }, "data.content":1 }
)

Wstaw nową wersję: (i zapobiegaj jednoczesnemu wstawianiu / aktualizacji)

update(
    {
        "_id":ObjectId("..."),
        $and:[
            { "data.vid":{ $not:{ $gt:2 } } },
            { "data.vid":2 }
        ]
    },
    { $push:{ "data":{ "vid":3, "content":"baz" } } }
)

2jest vidbieżącą najnowszą wersją i 3jest wstawiana nowa wersja. Bo trzeba najnowsza wersja użytkownika vid, jest to łatwe do zrobienia dostać kolejna wersja na vid: nextVID = oldVID + 1.

$andWarunek zapewni, że 2jest ostatni vid.

W ten sposób nie ma potrzeby tworzenia unikalnego indeksu, ale logika aplikacji musi zadbać o zwiększenie vidwkładki.

Usuń określoną wersję:

update(
    { "_id":ObjectId("...") },
    { $pull:{ "data":{ "vid":2 } } }
)

Otóż ​​to!

(pamiętaj limit 16 MB na dokument)

Jeśli szukasz gotowego rozwiązania -

Mongoid ma wbudowaną prostą wersję

http://mongoid.org/en/mongoid/docs/extras.html#versioning

mongoid-history to wtyczka Ruby, która zapewnia znacznie bardziej skomplikowane rozwiązanie z inspekcją, cofaniem i ponawianiem

https://github.com/aq1018/mongoid-history

Pracowałem nad tym rozwiązaniem, które obejmuje opublikowane, szkice i historyczne wersje danych:

{
  published: {},
  draft: {},
  history: {
    "1" : {
      metadata: <value>,
      document: {}
    },
    ...
  }
}

Wyjaśnię ten model tutaj: http://software.danielwatrous.com/representing-revision-data-in-mongodb/

Dla tych, którzy mogą implementować coś takiego w Javie , oto przykład:

http://software.danielwatrous.com/using-java-to-work-with-versoted-data/

W tym cały kod, który możesz rozwidlić, jeśli chcesz

https://github.com/dwatrous/mongodb-revision-objects

Jeśli używasz mangusty, znalazłem następującą wtyczkę, która jest przydatną implementacją formatu łatki JSON

mongoose-patch-history

Inną opcją jest użycie wtyczki mongoose-history .

let mongoose = require('mongoose');
let mongooseHistory = require('mongoose-history');
let Schema = mongoose.Schema;

let MySchema = Post = new Schema({
    title: String,
    status: Boolean
});

MySchema.plugin(mongooseHistory);
// The plugin will automatically create a new collection with the schema name + "_history".
// In this case, collection with name "my_schema_history" will be created.

Użyłem poniższego pakietu do projektu Mete / MongoDB i działa dobrze, główną zaletą jest to, że przechowuje historię / zmiany w tablicy w tym samym dokumencie, dlatego nie ma potrzeby dodatkowych publikacji lub oprogramowania pośredniego, aby uzyskać dostęp do historii zmian . Może obsługiwać ograniczoną liczbę poprzednich wersji (np. Ostatnich dziesięciu wersji), obsługuje także konkatenację zmian (więc wszystkie zmiany dokonane w określonym okresie zostaną objęte jedną wersją).

wersje nicklozon / meteor-collection-rewizje

Inną opcją dźwiękową jest użycie Meteor Vermongo ( tutaj )