CouchDB e versione dei documenti

12

Attualmente sto lavorando ad un'applicazione wiki-esque usando CouchDB e sto cercando di implementare uno schema di versioning dei documenti. Per come la vedo io ci sono due modi per farlo:

Memorizzare ogni versione come documento separato
Archivia le versioni precedenti come allegati a un singolo documento.

In questo momento, ho una forma di lavoro n. 1. Quando un utente modifica un documento e lo salva, il back-end prima copia la revisione precedente in un nuovo documento e quindi salva la nuova versione. Ogni documento ha un array 'history' che contiene dati su ogni versione (il documento _id della vecchia versione, un timestamp, l'editor, ecc.).

Poiché questo array di cronologia potrebbe diventare piuttosto lungo per un documento aggiornato di frequente, ho una vista che recupera un documento senza cronologia durante una lettura normale (e un'altra vista per recuperare la cronologia).

La mia domanda è questa: mi sento a disagio per il mio approccio attuale e ho pensato di cambiare il metodo dell '"attaccamento". Ma non sono sicuro. Spero che qualcuno che conosca CouchDB meglio di me (ci sono stato solo per un paio di settimane - e questo è il mio primo progetto con CouchDB ... e NoSQL) può dirmi quali sono i pro e i contro di ciascuno approccio. O c'è forse qualche altro schema di versione che sto trascurando?

database-design couchdb

— James Adam
fonte

2

Anche se non posso assolutamente parlare dell'impatto sulle prestazioni, il sistema che stai utilizzando è "spiritualmente" in linea con CouchDB. Memorizzare le versioni precedenti come gerarchia di risposta è idiomatico, come lo è nell'antenato spirituale di CouchDB, il database dei documenti di Lotus Notes (NSF) (Damien Katz ha lavorato profondamente sull'uno prima di sviluppare l'altro, mantenendo e migliorando il meglio di esso mentre getta i requisiti di compatibilità di cruft e backward / bugward, così molte delle domande strutturali più basilari avranno risposte in Note.)

2

Memorizzare solo le modifiche sarà una buona idea, perché la memorizzazione di documenti più vecchi come documenti separati o allegati alla revisione finale del database creerà un sovraccarico al server del database.

Ogni volta che cambi un valore chiave nel documento, aggiungi una nuova chiave denominata _h_i_s_<key_name>. Nel nuovo creato (o creato durante l'ultimo aggiornamento), aggiungere oggetti come di seguito dopo ogni modifica / aggiornamento: -

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

o

    {
    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}],
    ....
    }

Questo approccio consente di risparmiare molto spazio su disco e larghezza di banda di replica a lungo termine.

— Ravinder Payal
fonte

0

Senza alcuna conoscenza di CouchDB. La memorizzazione di ogni versione, sebbene possa differire solo marginalmente dal suo predecessore, è uno spreco di spazio. Consiglierei di memorizzare solo le modifiche.

Potresti dare un'occhiata qui o cercare il versioning dei dati.

— xuma202
fonte

Questa risposta non riesce a dire quale delle opzioni 1 (documenti separati) o 2 (come parte del documento) sia migliore.

— binki,

0

anni dopo ;-)

non è necessario archiviare le modifiche perché CouchDB lo farà per te. Se un documento viene modificato, verrà creata una nuova revisione. Essere consapevoli del fatto che questo è fisicamente un altro documento con lo stesso _idma un nuovo _rev(revison) e consumerà spazio sul disco.

Di sicuro dovresti mantenere tutte le revisioni che cosa significherebbe, che hai bisogno di un disco molto grande.

— awenkhh
fonte