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 Berechnungs-Pattern

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

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

      Bisher haben wir uns in den Patterns hauptsächlich darauf konzentriert, wie man die Daten optimal abspeichert. In diesem Teil wollen wir uns mal mit einem anderen Aspekt des Schema Design beschäftigen. Daten einfach nur abzuspeichern und wieder verfügbar zu haben ist zwar nett, aber nicht besonders spannend. Wer eigentliche Wert der Daten liegt darin sie auszuwerten und Berechnungen anzustellen. Typische Fragestellungen, die man versucht zu beantworten, sind z.B. Wir hoch war der Gewinn von Amazon Alex im letzten Quartal? Wie viele Leute haben den aktuellsten Blockbuster Film gesehen? Um diese Fragen beantworten zu können, müssen mit den Daten in der Datenbank Berechnungen angestellt werden.

      Wenn man diese Fragestellungen bei jeder Anfrage neu berechnet, dann ist das eine sehr Ressourcen-intensive Angelegenheit. Dies gilt in besonderem Maße bei großen Datensätzen wo CPU cycles, Festplattenzugriff und Arbeitsspeicher eine Rolle spielen.

      Stellen wir uns eine Web-Anwendung vor auf der Filminformationen zu finden sind. Jedes Mal, wenn wir die Anwendung aufrufen um einen Film nachzusehen bekommen wir Informationen über die Anzahl der Kinos in denen der Film gelaufen ist, die Anzahl der Besucher die den Film gesehen haben und die Einnahmen die der Film erzielt hat. Wenn die Anwendung diese Zahlen, für jeden Seitenaufruf laufend berechnen müßte, dann brächten wir, vor allem bei beliebten Filmen, eine ganze Menge Rechen-Power.

      Die meiste Zeit brauchen wir jedoch gar nicht die ganz genauen Zahlen. Wir können die Berechnungen in den Hintergrund verlagern und das Haupt-Dokument des Filmes regelmäßig updaten. Diese "Berechnungen" erlauben es uns aktuelle Zahlen anzuzeigen ohne ständig zusätzliche Last auf dem CPU zu erzeugen.

      • Das Berechnungs-Pattern

        • Das "Berechnungs-Pattern" wird dann angewendet, wenn Daten in einer Anwendung regalmäßig berechnet werden müssen. Das "Berechnungs-Pattern" findet außerdem Anwendung, wenn der Datenzugriff sehr leseintensiv ist, z.B. wenn wir in der Stunde 1.000.000 lesende aber nur 1.000 schreibende Zugriffe haben. Die Berechnungen bei jedem schreibendem Zugriff, statt den lesenden zu machen, würde Anzahl der Berechnungen um den Faktor 1.000 reduzieren.

          In dem Beispiel mit unserer Filmdatenbank führen wir Berechnungen basierend auf den Informationen bezüglich der Vorführungen durch, die wir für einen bestimmten Film haben. Die Ergebnisse werden erstellt und zusammen den Daten des Films abgelegt. In einer Anwendung mit wenigen Schreibvorgängen, können die Updates zusammen mit den Updates der Rohdaten gemacht werden. Wenn es mehr regelmäßige Schreibvorgänge gibt, dann können die Berechnungen in definierten Intervallen durchgeführt werden, z.B. jede Stunde. Da die Daten für die Anzeige und die Rohdaten für die Berechnungen unabhängig voneinander gehalten und genutzt werden können wir jederzeit existierende oder neue Berechnungen anstoßen und wissen das wir korrekte Ergebnisse bekommen werden.

          Andere Strategien für die Berechnung könnten z.B. das Hinzufügen eines Timestamps zu den Dokumenten sein, um festzustellen wann diese zuletzt geupdatet wurden. Die Anwendung kann dann ermitteln, wann und ob es notwendig ist eine Berechnung durchzuführen. Eine andere Möglichkeit könnte es sein, die noch zu berechnenden Daten zu queuen. Welche Strategie man verwendet sollte, am besten, den Entwicklern der Applikation überlassen werden.

          • Beispiel Use-Case

            • Das "Berechnungs-Pattern" kann immer dann angewendet werden, wenn Berechnungen gegen Daten erfolgen sollen. Datensätze, die Summierungen, wie z.B. Umsätze oder Zuseher benötigen sind ein gutes Beispiel. Aber auch Daten mit Zeitserien, Produktkataloge, Single-View Anwendungen (oder Dashboards für die Nicht-Techniker) und Event-Daten z.B. von Maschinen oder Sensoren sind ebenso hervorragende Kandidaten für dieses Pattern.

              Das Pattern wurde schon von einer Vielzahl von MongoDB Nutzern angewendet. Es gibt Anwendungen die massive Aggregationen auf den Daten von Fahrzeugen machen um die Ergebnisse für einige Stunden anzuzeigen. Ein Verlag häuft alle möglichen Arten von Datensammlungen an um z.B. "Top 100 Listen" für alle möglichen Themenbereiche zu erstellen. Diese Daten müssen nur ab- und zu neu berechnet werden, während die Datenbasis häufiger geupdatet wird.

              • Zusammenfassung

                • Dieses mächtige Design Pattern erlaubt es die CPU Workload zu reduzieren und gleichzeitig die Geschwindigkeit der Anwendung zu erhöhen. Es kann eingesetzt werden um Berechnungen oder andere Operationen auf Daten einer Collection anzuwenden und das Ergebnis in einem Dokument zu speichern. Damit wird verhindert, daß die gleiche Berechnung mehrfach erfolgen muß. Wann auch immer in einem System Berechnungen mehrfach ausgeführt werden müssen oder eine hohe Lese-Schreib-Rate besteht sollte das "Berechnungs-Pattern" in Betracht gezogen werden.

                  Die Rechte für die verwendete Grafik liegen bei 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

Latest member activities

Recommend this community post