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 Preallocation-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-preallocation-pattern
      Übersetzung mit freundlicher Genehmigung von MongoDB


      Eines der großartigen Dinge an der MongoDB ist das Document Data Model. Es bietet eine Menge Flexibilität, nicht nur für das Schema Design, sondern auch für den Entwicklungsprozess. Nicht zu wissen, welche Felder in der Zukunft vielleicht benötigt werden ist mit MongoDB Dokumenten eine Kleinigkeit. Es gibt jedoch auch genug Fälle, in denen die Struktur bekannt ist und die Möglichkeit diese aufzufüllen oder wachsen zu lassen das Design wesentlich einfacher macht. In solchen Fällen kann man auf das "Preallocation-Pattern" zurückgreifen.

      Speicherzuweisung wird oft blockweise gemacht, um Performanceprobleme zu vermeiden. In älteren Versionen von MongoDB (vor Version 3.2), als die MMAPv1 Storage Engine genutzt wurde, war es eine übliche Optimierungsstrategie Arbeitsspeicher zu allokieren, um diesen zur Verfügung zu haben, wenn ein Dokument anwächst. Updates, die zum Anwachsen eines Dokuments geführt haben, führten zu einer Verschiebung des Dokuments im Arbeitsspeicher, auf Kosten von Serverperformance. Mit seinen nicht blockierenden "rewrite on update" Algorithmen ist so etwas mit der WiredTiger Engine nicht mehr notwendig.

      Mit der Abkündigung vom MMAPv1 in MongoDB 4.0, schien das "Preallocation-Pattern" seine Notwendigkeit und seinen Sinn zu verlieren. Es gibt jedoch immer noch Anwendungsfälle für das Patter, auch unter WiredTiger. Wie auch schon bei anderen Patterns, sind dazu ein paar Vorüberlegungen notwendig.

      • Das Preallocation-Pattern

        • Das Pattern schreibt ganz einfach nur vor, initial eine leere Struktur zu generieren, die später mit Daten befüllt wird. Das hört sich zunächst mal ganz einfach an, aber man muss dabei einen Ausgleich zwischen dem erwünschten Ergebnis und den zusätzlichen Ressourcen finden, die von System benötigt werden. Größere Dokumente erzeugen ein größeres Working Set, welches wiederum dem Arbeitsspeicherverbrauch anwachsen lässt.

          Wenn es einfacher wird die Applikation zu schreiben und zu verwalten, indem man leere Elemente in den Dokumenten vorhält, dann kann dies schnell den zusätzlichen Arbeitsspeicherverbrauch rechtfertigen. Nehmen wir mal als Beispiel an, dass wir die Sitzplätze in einem Theater, als zweidimensionales Array abbilden sollen, in dem jeder Sitz eine Reihe und eine Nummer hat. z.B. der Sitz "C7". Manche Reihen haben möglicherweise weniger Sitze, trotzdem ist es einfache einen Sitz in einem zweidimensionalen Array zu finden, als mit einer komplizierten Formel in einem eindimensionalen Array, welches nur Zellen für existierende Sitze hat, danach zu suchen. Es ist auch einfache herauszufinden, welche Sitze noch frei sind indem man ein separates Array dafür erstellt.


          Eindimensionale Darstellung eines Theaterparkets. Verfügbare Sitze haben einen blauen Rand.


          Zweidimensionale Repräsentation eines Theaterparkets. Gültige Sitze sind grün markiert, verfügbare Sitze haben einen blauen Rand.

          • Beispiel Use-Case

            • Wie wir schon gesehen haben, sind alle zweidimensionalen Strukturen wie z.B. ein Theaterparkett oder ein Kino gute Use Cases. Ein anderes Beispiel wäre ein Reservierungssystem, wo es täglich wechselnde blockierte oder reservierte Ressourcen geben kann. Eine Zelle für einen verfügbaren Tag zur Verfügung zu haben macht Berechnungen und Überprüfungen schneller, als z.B. Nummernblöcke zu verwalten.

              {
              _id: <ObjechtId>,
              month: "April",
              year: "2019",
              work_days:
              [
              1, 2, 3, 4, 5,
              8, 9, 10, 11, 12,
              15, 16, 17, 18, 19,
              22, 23, 24, 25, 26,
              29, 30
              ]
              }

              Der Monat April 2019 mit allen Arbeitstagen als Array

              {
              _id: <ObjechtId>,
              month: "April",
              year: "2019",
              work_days:
              [
              (1, 5),
              (8, 12),
              (15, 19),
              (22, 26),
              (29, 30)
              ]
              }

              Der Monat April 2019 mit allen Arbeitstagen als Liste von "Ranges"

              • Zusammenfassung

                • Dieses Pattern war zu Zeiten MMAPv1 Storage Engine eines der am Meisten verwendeten in MongoDB. Durch die Abkündigung der Engine hat es einen Großteil seiner generischen Use Cases verloren, aber es gibt noch immer Situationen, wo dieses Pattern angewendet werden kann. Wie auch bei anderen Pattern muss man immer den Trade-off zwischen Einfachheit und Performance im Auge behalten.

                  Alle Rechte für die verwendeten Grafiken liegen bei MongoDB https://www.mongodb.com
                  Wer mehr über das Schema Design 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

Neueste Mitgliederaktivitäten

Diesen Community Beitrag weiterempfehlen