Modi per implementare il versioning dei dati in MongoDB

Puoi condividere i tuoi pensieri su come implementeresti il ​​versioning dei dati in MongoDB. (Ho fatto una domanda simile riguardo a Cassandra . Se hai qualche idea su quale db è meglio per favore, condividi)

Supponiamo che io abbia bisogno dei record di versione in una semplice rubrica. (I record della rubrica sono memorizzati come oggetti json piatti). Mi aspetto che la storia:

• sarà usato raramente
• sarà usato tutto in una volta per presentarlo in modo "macchina del tempo"
• non ci saranno più versioni di poche centinaia in un singolo record. la storia non scadrà.

Sto considerando i seguenti approcci:

• Creare una nuova raccolta di oggetti per archiviare la cronologia dei record o le modifiche ai record. Memorizzerebbe un oggetto per versione con un riferimento alla voce della rubrica. Tali registrazioni sarebbero le seguenti:

  {
   "_id": "nuovo ID",
   'user': user_id,
   "timestamp": timestamp,
   'address_book_id': 'id del record della rubrica' 
   'old_record': {'first_name': 'Jon', 'last_name': 'Doe' ...}
  }
  

  Questo approccio può essere modificato per memorizzare una matrice di versioni per documento. Ma questo sembra essere un approccio più lento senza alcun vantaggio.

• Memorizzare le versioni come oggetto serializzato (JSON) associato alle voci della rubrica. Non sono sicuro di come allegare tali oggetti ai documenti MongoDB. Forse come una serie di stringhe. ( Modellato sulla versione semplice del documento con CouchDB )

La prima grande domanda quando ci si immerge in questo è "come si desidera memorizzare i changeset" ?

1. Diffs?
2. Intere copie dei dischi?

Il mio approccio personale sarebbe quello di memorizzare le differenze. Poiché la visualizzazione di questi diff è davvero un'azione speciale, inserirei i diff in una diversa raccolta "storica".

Vorrei utilizzare la diversa raccolta per risparmiare spazio di memoria. In genere non si desidera una cronologia completa per una query semplice. Quindi, mantenendo la cronologia fuori dall'oggetto, è anche possibile tenerla fuori dalla memoria a cui si accede comunemente quando vengono interrogati quei dati.

Per semplificarmi la vita, farei in modo che un documento di storia contenga un dizionario di differenze con data e ora. Qualcosa come questo:

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

Per semplificarmi la vita, renderei questa parte dei miei DataObjects (EntityWrapper, qualunque cosa) che utilizzo per accedere ai miei dati. Generalmente questi oggetti hanno una qualche forma di storia, in modo da poter facilmente sostituire il save()metodo per apportare questa modifica allo stesso tempo.

AGGIORNAMENTO: 2015-10

Sembra che ora ci sia una specifica per la gestione dei diff JSON . Questo sembra un modo più robusto per memorizzare le differenze / modifiche.

Esiste uno schema di controllo delle versioni chiamato "Vermongo" che affronta alcuni aspetti che non sono stati trattati nelle altre risposte.

Uno di questi problemi sono gli aggiornamenti simultanei, un altro è l'eliminazione dei documenti.

Vermongo archivia copie complete di documenti in una collezione shadow. Per alcuni casi d'uso ciò potrebbe causare un sovraccarico eccessivo, ma penso che semplifichi anche molte cose.

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

Ecco un'altra soluzione che utilizza un singolo documento per la versione corrente e tutte le versioni precedenti:

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

datacontiene tutte le versioni. L' dataarray è ordinato , le nuove versioni verranno edite solo $pushalla fine dell'array. data.vidè l'ID versione, che è un numero crescente.

Ottieni la versione più recente:

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

Ottieni una versione specifica di vid:

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

Restituisce solo i campi specificati:

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

Inserisci nuova versione: (e impedisce l'inserimento / aggiornamento simultaneo)

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

2è l' vidattuale versione più recente ed 3è la nuova versione che viene inserita. Poiché hai bisogno delle versioni più recenti vid, è facile ottenere le versioni successive vid:nextVID = oldVID + 1 .

La $andcondizione garantirà, che 2è l'ultimavid .

In questo modo non è necessario un indice univoco, ma la logica dell'applicazione deve occuparsi di incrementare l' vidinserimento on.

Rimuovi una versione specifica:

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

Questo è tutto!

(ricorda il limite di 16 MB per documento)

Se stai cercando una soluzione pronta per l'uso -

Mongoid ha integrato un semplice controllo delle versioni

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

mongoid-history è un plug-in Ruby che fornisce una soluzione significativamente più complicata con controllo, annullamento e ripetizione

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

Ho lavorato su questa soluzione che ospita versioni pubblicate, bozze e storiche dei dati:

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

Spiego ulteriormente il modello qui: http://software.danielwatrous.com/representing-revision-data-in-mongodb/

Per quelli che potrebbero implementare qualcosa di simile in Java , ecco un esempio:

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

Incluso tutto il codice che puoi fork, se vuoi

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

Se stai usando mongoose, ho trovato il seguente plugin come un'implementazione utile del formato JSON Patch

mangusta-patch-storia

Un'altra opzione è quella di utilizzare il plugin 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.

Ho usato il pacchetto seguente per un progetto meteor / MongoDB e funziona bene, il vantaggio principale è che memorizza la cronologia / le revisioni all'interno di un array nello stesso documento, quindi non è necessario aggiungere pubblicazioni o middleware per accedere alla cronologia delle modifiche . Può supportare un numero limitato di versioni precedenti (es. Ultime dieci versioni), supporta anche la concatenazione di modifiche (quindi tutte le modifiche avvenute in un determinato periodo saranno coperte da una revisione).

nicklozon / meteora-raccolta-revisioni

Un'altra opzione audio è utilizzare Meteor Vermongo ( qui )