MongoDB

MongoDB ist die führende Open-Source, Document Datenbank die für einfache Entwicklung und Skalierung aber auch für Big Data Szenarien entwickelt wurde.

MongoDB Patterns: Das Schema Versionierungs Pattern

Marc-David Militz
Experte
  • Artikel von Daniel Coupal und Ken W. Alger

    • englischer Originalartikel
      https://www.mongodb.com/blog/post/building-with-patterns-the-schema-versioning-pattern
      Übersetzung mit freundlicher Genehmigung von MongoDB


      Ein Sprichwort sagt: "Das einzig Konstante im Leben ist die Veränderung." Diese Weisheit lässt sich auch auf Datenbank-Schemas anwenden. Informationen, von denen wir gedacht haben, wir würden sie nie benötigen, wollen wir plötzlich abfragen. Oder neue Dienste sind plötzlich verfügbar und müssen in einem Datenbank-Eintrag eingebunden werden. Unabhängig davon, was der Grund für die Änderung ist, nach einer Weile wird es immer wieder notwendig werden, das unter einer Applikation liegende Datenbankschema anzupassen. Dies führ nicht selten zu Herausforderungen und möglicherweise auch zu so manchen Kopfschmerzen in einem alten tabularen Datenbanksystem. In der MongoDB können das Schema Versionierungs Pattern nutzen, um die Änderungen einfacher zu machen.

      Das Updaten eines Datenbank-Schemas in einer relationalen Datenbank kann, wie erwähnt, herausfordernd sein. In der Regel muss die Anwendung angehalten werden, die Datenbank muss migriert werden, anschließend muss die Anwendung wieder gestartet werden. Diese Downtimes führen zu schlechten Kundenerfahrungen. Noch schlimmer, wenn während der Migration etwas schief geht, ist es oft eine noch größere Herausforderung die vorherige Version wiederherzustellen.

      Das Schema Versionierungs Pattern nutzt auf die Vorzüge der Eigenschaft von MongoDB, die es zulässt unterschiedliche Dokumente in derselben Collection zu haben. Dieser polymorphische Aspekt von MongoDB ist extrem mächtig. Dokumente können unterschiedliche Felder oder auch unterschiedliche Feldtypen für das gleiche Feld haben, die friedlich nebeneinander existieren.

      • Das Schema Versionierungs Pattern

        • Die Implementierung des Patterns ist vergleichsweise einfach. Die Anwendung startet mit einem Original Schema, das irgendwann verändert wird. Wenn dieser Fall eintritt, dann fügen wir den Dokumenten ein "schema_version" Feld hinzu. Dieses Feld sagt der Applikation, wie es dieses spezielle Dokument zu behandeln hat. Alternativ kann man die Version auch am Vorhandensein oder nicht Vorhandensein spezieller Felder ermitteln, aber die erste Methode sollte bevorzugt werden. Wir können davon ausgehen, dass alle Felder, die dieses Feld nicht haben zur Version 1 gehören. Jede neue Version würde das "schema_version" Feld inkrementieren und könnte in der Anwendung entsprechend verarbeitet werden.

          Wenn neue Informationen gespeichert werden, nutzen wir die aktuellste Schema Version. Abhängig von unseren Anwendungsfällen und dem Design unserer Applikation können wir entscheiden alle Dokumente an das neue Schema anzupassen oder das nur bei Dokumenten zu tun, auf die wir zugreifen. Innerhalb der Anwendung müssen die unterschiedlichen Versionen verarbeitet werden.

          • Beispiel Use-Case

            • Wie bereits erwähnt, muss jede Datenbank irgendwann mal angepasst werden, deshalb ist dieses Pattern in vielen Situationen hilfreich. Werfen wir einen Blick auf den Use Case eines Benutzerprofils. Wir beginnen mit den Kontaktinformationen, bevor es so viele Unterschiedliche Kommunikationsmethoden gab. Unsere Kontakte können nur in der Arbeit und zuhause erreicht werden.

              {
              "_id": "<ObjectId>",
              "name": "Anakin Skywalker",
              "home": "503-555-0000",
              "work": "503-555-0010"
              }


              Während die Zeit voranschreitet und die Anzahl an Benutzerprofilen wächst, stellen wir fest, dass es nötig ist Mobiltelefon Nummern hinzuzufügen. Das Feld zu ergänzen ist relativ simpel.

              {
              "_id": "<ObjectId>",
              "name": "Darth Vader",
              "home": "503-555-0100",
              "work": "503-555-0110",
              "mobile": "503-555-0120",
              }


              Es vergeht weitere Zeit und wir stellen irgendwann fest, dass kaum noch Leute ein Telefon zuhause haben. Zugleich werden andere Kontaktmethoden immer wichtiger, in den Datensätzen. Dienste wie Skype, Twitter und Google Hangouts werden immer populärer und waren unter Umständen noch gar nicht erfunden, als wir angefangen haben Kontaktinformationen zu sammeln. Wir wollen unsere Anwendung nun aber auch Zukunftssicher machen, deshalb können wir das "Attribute Pattern" anwenden und implementieren dieses in "contact_method" Array von Werten. https://www.qualiero.com/community/mongodb/mongodb-theorie/mongodb-patterns-das-attribute-pattern.html Dadurch erzeugen wir auch eine neue Schema Version.

              {
              "_id": "<ObjectId>",
              "schema_version": "2",
              "name": "Anakin Skywalker (in Rente)",
              "contact_method": [
              { "work": "503-555-0110" },
              { "mobile": "503-555-0120" },
              { "twitter": "@anakinskywalker" },
              { "skype": "AlwaysWithYou" }
              ]
              }


              Die Flexibilität des MongoDB Dokumenten Models erlaubt es all dies ohne eine Downtime der Datenbank zu machen. Vom Standpunkt der Applikation aus, kann diese so erstellt werden, dass sie auch zwei verschiedene Versionen der Daten verarbeiten kann. Die Änderungen in der Applikation sollte ebenso keine Downtime erfordern, wenn man davon ausgeht dass mehr als ein Server für die Anwendung zur Verfügung steht.

              • Zusammenfassung

                • Das Schema Versionierungs Pattern ist eine großartige Möglichkeit für Anwendungen, bei denen eine Downtime keine Option ist, wenn das Updaten von vielen Dokumenten Stunden, Tage oder Wochen beanspruchen würde, dat Updaten von älteren Dokumenten keine notwendige Anforderung ist, oder eine Kombination von diesen Anforderungen auftritt. Es ermöglicht das einfache Hinzufügen eines "schema_version" Feldes um die Änderungen zu verwalten. Zusätzlich gibt es den Entwicklern die Möglichkeit besser und flexibler zu entscheiden wann und wie die Migration der Daten stattfindet. All diese Punkte führen zu weniger technischen Aufwänden in der Zukunft, was ein weiterer großer Vorteil dieses Patterns ist.

                  Wie auch schon bei anderen Pattern, so sollte man auch hier etwas zu beachten. Währen der Migration kann es notwendig sein, Indexe für unterschiedliche Versionen der Dokumente mehrfach zu verwalten.

                  Einer der Hauptvorteile dieses Patterns der sehr kleine Eingriff im eigentlichen Datenmodell. Alles was man tun muss ist ein einziges Feld hinzuzufügen. Dann kann die Anwendung die unterschiedlichen Versionen der Dokumente handhaben.

                  Des Weiteren, wie in den Use Case gezeigt wurde, lässt sich dieses Pattern sehr einfach mit anderen Pattern kombinieren. Das alles auch noch ohne Downtimes der Datenbank. Das sollten alleine schon genügend Argumente sein, um künftig nicht mehr über alte tabellarische Datenbanken nachzudenken.

Neueste Mitgliederaktivitäten

Diesen Community Beitrag weiterempfehlen