Sposoby implementacji wersji danych w MongoDB

Question

Czy możesz podzielić się swoimi przemyśleniami na temat implementacji wersji danych w MongoDB? (Pytałem: similar question regarding Cassandra. Jeśli masz jakieś przemyślenia, które db jest lepsze, podziel się tym tematem)

Załóżmy, że potrzebuję wersji rekordów w prostej książce adresowej. (Rekordy książki adresowej są przechowywane jako płaskie obiekty json). Spodziewam się, że historia:

• będą wykorzystywane rzadko
• zostaną wykorzystane wszystkie naraz, aby przedstawić go w „Time Machine” moda
• nie będzie więcej niż wersje kilkuset do pojedynczy rekord. historia nie wygaśnie.

Zastanawiam następujące podejścia:

• Utwórz nową kolekcję obiektów do przechowywania historii zmian do rejestrów lub ewidencji. Będzie przechowywać jeden obiekt na wersję z odniesieniem do wpisu książki adresowej. Takie zapisy wyglądają następująco:

   
  { 
  '_id': 'new id', 
  'user': user_id, 
  'timestamp': timestamp, 
  'address_book_id': 'id of the address book record' 
  'old_record': {'first_name': 'Jon', 'last_name':'Doe' ...} 
  } 
  

  To podejście można zmodyfikować, aby przechowywać tablicę wersji dla każdego dokumentu. Ale wydaje się to wolniejszym podejściem bez żadnych korzyści.

• Zapisuje wersje jako obiekt serializowany (JSON) dołączony do wpisów w książce adresowej. Nie wiem, jak dołączyć takie obiekty do dokumentów MongoDB. Być może jako tablica ciągów. (Modelled after Simple Document Versioning with CouchDB)

Answer 1

Pierwszy duży problem podczas nurkowania na tym komputerze jest „jak chcesz przechowywać Zestawienia zmian”?

1. Diffs?
2. Całe kopie nagrań?

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ć różnych kolekcji, aby zaoszczędzić miejsce w pamięci. Zwykle nie chcesz pełnej historii dla prostego zapytania. Tak więc, utrzymując historię poza obiektem, możesz także zachować ją poza powszechnie dostępną pamięcią, gdy dane są sprawdzane.

Aby moje życie było łatwe, chciałbym, aby dokument historii zawierał słownik znaczników czasu. Coś takiego:

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

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

UPDATE: 2015-10

Wygląda na to, że jest teraz a spec for handling JSON diffs.Wydaje się to być bardziej niezawodnym sposobem przechowywania różnic/zmian.

Answer 2

Jeśli szukasz gotowej rolki rozwiązania -

Mongoid ma wbudowany prosty wersjonowanie

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

mongoid-historia jest plugin Ruby, który zapewnia znacznie bardziej skomplikowane rozwiązanie z badania, cofanie i powtarzanie

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

Answer 3

jest versi program "Vermongo", który dotyczy niektórych aspektów, które nie zostały uwzględnione w innych odpowiedziach.

Jednym z tych problemów są aktualizacje równoczesne, kolejnym jest usuwanie dokumentów.

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

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

Answer 4

pracowałem za pośrednictwem tego rozwiązania, które pomieścić opublikowany, projekt i wersje historycznych danych:

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

wyjaśnię modelu dalej tutaj: http://software.danielwatrous.com/representing-revision-data-in-mongodb/

dla osób, które zaimplementować coś takiego w Java, oto przykład:

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

Łącznie cały kod, który można widelcem, jeśli chcesz

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

Answer 5

Oto kolejny rozwiązanie za pomocą jednego dokumentu dla bieżącej wersji i wszystkie stare wersje:

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

data zawiera wszystkie wersje. Macierz data jest zamówiona, nowe wersje otrzymają tylko $push ed na końcu tablicy. data.vid jest identyfikatorem wersji, który jest numerem narastającym.

Pobierz najnowszą wersję:

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

uzyskać konkretną wersję przez vid:

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

Return tylko określonych dziedzinach:

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

Włóż nową wersję: (i zapobiec współbieżne insert/update)

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

2 jest vid obecnej najnowszej wersji i 3 jest nowa wersja dodaje coraz. Ponieważ potrzebujesz najnowszej wersji vid, łatwo jest uzyskać następną wersję: vid: nextVID = oldVID + 1.

Stan zapewnia, że ​​ jest najnowszym vid.

W ten sposób nie ma potrzeby stosowania unikalnego indeksu, ale logika aplikacji musi dbać o zwiększenie numeru vid na wkładce.

usunąć konkretną wersję:

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

to jest to!

(pamiętaj 16MB za granicę dokumentu)

Answer 6

Jeśli używasz mangusty, znalazłem następujące wtyczki aby być użytecznym realizacja formacie

mongoose-patch-history

Answer 7

Inną opcją na JSON Patch 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. 

Answer 8

Użyłem pakietu poniżej dla meteor/projektu MongoDB, i to działa dobrze, główną zaletą jest to, że przechowuje historię/rewizje wewnątrz tablicy w tym samym dokumencie, stąd nie ma potrzeby stosowania dodatkowego publikacji lub oprogramowanie pośrednie, aby uzyskać dostęp do historii zmian. Może obsługiwać ograniczoną liczbę wcześniejszych wersji (na przykład dziesięć ostatnich wersji), obsługuje również łączenie zmian (więc wszystkie zmiany dokonane w określonym czasie będą objęte jedną wersją).

nicklozon/meteor-collection-revisions

Inną opcją jest użycie dźwięku Meteor Vermongo (here)

Answer 9

Spróbuj użyć Javers. Dobra biblioteka.