Versionierung von CouchDB und Dokumenten

12

Ich arbeite derzeit an einer Wiki-ähnlichen Anwendung mit CouchDB und versuche, ein Dokumentversionsschema zu implementieren. So wie ich es sehe, gibt es zwei Möglichkeiten, dies zu tun:

Speichern Sie jede Version als separates Dokument
Speichern Sie ältere Versionen als Anhänge an ein einzelnes Dokument.

Im Moment arbeite ich in der ersten Form. Wenn ein Benutzer ein Dokument bearbeitet und speichert, kopiert das Back-End zuerst die vorherige Revision in ein neues Dokument und speichert dann die neue Version. Jedes Dokument hat ein 'history'-Array, das Daten zu jeder Version enthält (die Dokument-ID der alten Version, einen Zeitstempel, den Editor usw.).

Da dieses Verlaufsarray für ein häufig aktualisiertes Dokument sehr lang werden kann, wird in einer Ansicht beim normalen Lesen ein Dokument ohne Verlauf abgerufen (und in einer anderen Ansicht wird der Verlauf abgerufen).

Meine Frage lautet: Ich bin mir nicht sicher, was ich derzeit tue, und habe darüber nachgedacht, auf die Methode des „Anhaftens“ umzusteigen. Aber ich bin mir nicht sicher. Ich hoffe, dass jemand, der CouchDB besser kennt als ich (ich bin erst seit ein paar Wochen dabei - und dies ist mein erstes Projekt, das CouchDB ... und NoSQL verwendet), mir die Vor- und Nachteile jedes einzelnen Projekts erklären kann Ansatz. Oder gibt es vielleicht ein anderes Versionsschema, das ich übersehen habe?

database-design couchdb

— James Adam
quelle

2

Ich kann zwar überhaupt nicht mit den Auswirkungen auf die Leistung sprechen, aber das von Ihnen verwendete System entspricht "geistig" der CouchDB. Das Speichern von Vorgängerversionen als Antworthierarchie ist idiomatisch, da es sich um den "spirituellen Vorfahren" von CouchDB handelt, der Lotus Notes-Dokumentendatenbank (NSF) (Damien Katz hat intensiv an der einen gearbeitet, bevor er die andere entwickelt und das Beste daraus beibehalten und verbessert hat Viele der grundlegenderen strukturellen Fragen werden im Anhang beantwortet sein, während die Anforderungen an die Kompatibilität von Cruft und Abwärts- / Bugward-Kompatibilität geklärt werden.)

2

Das Speichern nur von Änderungen ist eine gute Idee, da das Speichern älterer Dokumente als separate Dokumente oder Anhänge zur endgültigen Überarbeitung der Datenbank einen Overhead für den Datenbankserver verursacht.

Wenn Sie einen Schlüsselwert in Ihrem Dokument ändern, fügen Sie einen neuen Schlüssel mit dem Namen hinzu _h_i_s_<key_name>. Fügen Sie in dem neu erstellten (oder während des letzten Updates erstellten) Objekt nach jeder Bearbeitung / Aktualisierung die folgenden Objekte hinzu:

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

oder

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

Dieser Ansatz spart auf lange Sicht viel Speicherplatz und Replikationsbandbreite.

— Ravinder Payal
quelle

0

Ohne Kenntnis von CouchDB. Es ist jedoch eine Verschwendung von Speicherplatz, wenn jede Version nur unwesentlich von der Vorgängerversion abweicht. Ich würde nur das Speichern von Änderungen empfehlen.

Vielleicht möchten Sie hier einen Blick darauf werfen oder nach Datenversionierung suchen.

— xuma202
quelle

In dieser Antwort wird nicht angegeben, welche der Optionen 1 (separate Dokumente) oder 2 (als Teil des Dokuments) besser ist.

— binki

0

Jahre später ;-)

Sie müssen die Änderungen nicht speichern, da CouchDB dies für Sie erledigt. Wenn ein Dokument geändert wird, wird eine neue Revision erstellt. Beachten Sie, dass dies physisch ein anderes Dokument ist, das dasselbe Dokument enthält, _idjedoch neu ist _rev(überarbeitet) und Speicherplatz auf Ihrer Festplatte belegt.

Sicher müssten Sie alle Revisionen behalten, was bedeuten würde, dass Sie eine sehr große Festplatte benötigen.

— awenkhh
quelle