- Artikel von Daniel Coupal und Ken W. Alger
englischer Originalartikel
https://www.mongodb.com/blog/post/building-with-patterns-the-document-versioning-pattern
Übersetzung mit freundlicher Genehmigung von MongoDB
Datenbanken, wie MongoDB, sind sehr gut darin sehr große Datenmengen zu durchsuchen und gelegentlich zu updaten. In den meisten Fällen fragen wir jedoch lediglich den aktuellen Status eines Dokuments ab. Was aber, wenn wir vorherige Versionen eines Dokuments abfragen wollen? Was ist, wenn wir eine Versionierung oder Funktionalitäten für die Versionskontrolle unserer Dokumente benötigen? In diesem Fall können wir das "Dokument-Versionierungs-Pattern" einsetzen.
Bei diesem Pattern geht es darum die Versionshistorie eines Dokuments verfügbar und nutzbar zu halten. Wir sind damit in der Lage ein Versionskontrollsystem in MongoDB umzusetzen. Ein System für die wenigen, sich ändernden Dokument zu haben und MongoDB für die anderen zu nutzen, wäre ein ziemlich unhandliches Konstrukt. Mit dem "Dokument-Versionierungs-Pattern" können wir es vermeiden mehrere Systeme zu fahren, um aktuelle und frühere Versionen von Dokumenten zu managen. Wir behalten damit alle Daten in einer Datenbank.
- Das Dokument-Versionierungs-Pattern
Dieses Pattern adressiert das Problem, unterschiedliche Versionen von Dokumenten in MongoDB zu managen, anstatt diese auf unterschiedliche Systeme zu verteilen. Um das zu erreichen benötigen wir, in jedem Dokument, ein Feld, dass es uns ermöglicht einer Versionsnummer zu führen. In der Datenbank benötigen wir dann zwei Collections: eine für die aktuellen Dokumente (die auch am meisten abgefragt werden) und eine andere, in der alle Versionen der Dokumente abgelegt sind.
Das "Dokument-Versionierungs-Pattern" trifft einige Annahmen über die Daten in der Datenbank und die Datenzugriffe, die die Applikation macht.
- 1. Die Dokumente haben nicht zu viele Versionen
- 2. Es gibt nicht zu viele Dokumente, die Versioniert werden
- 3. Die Mehrzahl der Abfragen geht auf die aktuelle Version der Dokumente
Wenn sie der Meinung sind, dass eine dieser Annahmen nicht auf ihren jeweiligen Use Case passen, dann ist dieses Pattern wohl keine gute Idee. Eventuell hilft es bei der Implementierung der Versionierung einen anderen Weg zu beschreiten oder aber sie sehen sich nach einer anderen Lösung um.
- Beispiel Use-Case
Das "Dokument-Versionierungs-Pattern" ist sehr nützlich in Branchen, wo spezifische Point-In-Time Versionen eines Datensatzes benötigt werden. z.B. in der Finanz- und Gesundheitsindustrie sind gute Beispiele, aber auch Versicherungen und Rechtsberatungen kommen in Frage. Es gibt viele Use-Cases, in denen die Versionshistorie von Daten nützlich ist.
Denken sie nur mal daran, wie viele Versicherungen von diesem Pattern Gebrauch machen könnten. Jeder Kunde hat eine "Standard-Police" und dazu einen zweiten Teil der kundenspezifisch ist. Der zweite Teil enthält eine Liste von Zusatzleitungen zur Standard-Police und/oder eine Liste von speziellen Objekten, die versichert wurden. Wenn der Kunde nun ändert, welche Objekte versichert wurden, muss diese Liste geupdated werden, die historischen Informationen müssen aber auch erhalten bleiben. Dies ist in Hausbesitzer- oder Mieterversicherungspolicen ziemlich üblich. Wenn eine Kunde nun spezielle Objekte hat, die über die Standard-Police hinaus versichert werden sollen, werden diese zusätzlich ausgewiesen. Ein weiterer Use-Case könnte es sein, alle Versionen der Standard-Police aufzubewahren, die ein Kunde über die Zeit zugeschickt bekommen hat.
Wenn wir nun einen Blick auf die Anforderungen des "Dokument-Versionierungs-Patterns" werfen, dann ist genau das ein großartiger Anwendungsfall. Die Versicherung hat wahrscheinlich Millionen von Kunden, die Zusätze zu den Policen kommen nicht zu oft vor und der Großteil der Suchvorgänge wird auf den aktuellen Versionen der Standard-Policen stattfinden.
In unserer Datenbank werden wir wohl ein "current_policy" Dokument, welches die kundenspezifischen Informationen in einer "current_policies" Collection enthält, sowie "policy_revision" Dokumente in einer "policy_revisions" Collection haben. Zusätzlich gibt es eine "satndard_policy" Collection welche, für die meisten Kunden, die gleichen Daten enthält. Wenn ein Kunde nun ein neues Objekt hat, dass er einer existierenden Police hinzufügen möchte, dann wird ein neues "policy_revision" Dokument, unter Verwendung des "current_policy" Dokumentes, erstellt. Das Versionierungsfeld im Dokument wird inkrementiert, um es als aktuellste Version zu kennzeichnen, und das neue Versicherungsobjekt wird hinzugefügt.
{
_id: ObjectID<ObjechtId>,
name: "Bilbo Beutlin",
revision: 1,
items_insured: ["Elbenschwert"],
...
}
Original "current_policy" Dokument
{
_id: ObjectID<ObjechtId>,
name: "Bilbo Beutlin",
revision: 1,
items_insured: ["Elbenschwert"],
...
}
Neues "policy_revision" Dokument
{
_id: ObjectID<ObjechtId>,
name: "Bilbo Beutlin",
revision: 2,
items_insured: ["Elbenschwert", "Der eine Ring"],
...
}
Neues "current_policy" Dokument
Die aktuellste Revision wird in der "current_policies" Collection gespeichert und die alte Version wird in die "policiy_revisions" Collection gespeichert. Dadurch bleiben alle Abfragen auf die "current_policies" relativ einfach, da man sich hier nicht um die Versionierung kümmern muss. Die "policy_revisions" Collection kann auch nur eine bestimmte Anzahl früherer Versionen enthalten, das hängt ganz von den jeweiligen Anforderungen ab.
{
_id: ObjectID<ObjechtId>,
name: "Bilbo Beutlin",
revision: 2,
...
},
{
_id: ObjectID<ObjechtId>,
name: "Gandalf",
revision: 12,
...
}
Die "current_policies" Collection
{
_id: ObjectID<ObjechtId>,
name: "Bilbo Beutlin",
revision: 1,
...
},
{
_id: ObjectID<ObjechtId>,
name: "Gandalf",
revision: 11,
...
},
{
_id: ObjectID<ObjechtId>,
name: "Gandalf",
revision: 10,
...
},
{
_id: ObjectID<ObjechtId>,
name: "Gandalf",
revision: 9,
...
}
Die "policy_revisions" Collection
In diesem Beispiel bietet die "Mittelerde Versicherung" eine "standard_policy" für seine Kunden an. Alle Einwohner des Auenlandes haben ein solches spezifischen Policy-Dokument. Bilbo Beutlin hat einige spezifische Objekte, welche zusätzlich versichern möchte. Sein Elbenschwert "Stich" und sicher auch "Der eine Ring" werden seiner Police hinzugefügt. Diese Änderungen sind in der "current_policies" Collection verzeichnet, während die "policiy_revisions" Collection die historischen Dokumente enthält.
Das "Dokument-Versionierungs-Pattern" ist vergleichsweise einfach umzusetzen. Es kann auch auf bestehenden Systemen vergleichsweise einfach implementiert werden, ohne zu viele Änderungen an der Anwendung oder den bestehenden Dokumenten zu machen. Des weiteren bleiben die Zugriffe, auf die aktuellen Dokumente, performant.
Ein Nachteil des Patterns ist es, dass für Abfragen auf frühere Versionen auf eine andere Collection zugegriffen werden muss. Außerdem gibt es auf der Datenbank, durch das Pattern, viel mehr schreibende Vorgänge. Das ist auch der Grund warum es eine Anforderung des Patterns ist keine zu häufigen Änderungen zu haben.
- Zusammenfassung
Wenn man Dokumente versionieren möchte ist das "Dokument-Versionierungs-Pattern" eine großartige Option. Es ist vergleichsweise einfach zu implementieren und kann auf existierende Dokumente angewendet werden. Als weiterer Vorteil bleiben die Abfragen auf die aktuellen Dokumente performant. Das Pattern ersetzt allerdings kein spezialisiertes Versionskontrollsystem.
Wer mehr über Pattern und Versionierung in MongoDB erfahren möchte, dem sei der Qualiero Kurs für Datenbank Entwickler empfohlen https://www.qualiero.com/lerninhalte/classroom-trainings/mongodb-datenbank-entwickler-kurs.html
