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

Experte
Eine immer wieder gestellte Frage zu MongoDB ist: "Wie strukturiere ich das Datenschema für meine Applikation?" Die ehrliche Antwort darauf lautet, wie bei eigentlich allen anderen Datenbanken auch: "Es kommt darauf an!" Gibt es in der Applikation mehr Lese- oder Schreiboperationen? Welche Daten werden zusammen abgefragt? Welche Anforderungen an die Performance gibt es? Wie groß sind die Dokumente? Wie groß können die Dokumente werden? Wie antizipiert man das Wachstum der Daten am besten?

Alle diese Fragen, und auch noch viele weitere, sind Faktoren die das Design des Datenbankschemas beeinflussen. Es wird häufig gesagt dass MongoDB schemalos ist, in der Realität ist das Schemadesign in MongoDB aber sehr wichtig. Wie in den meisten Datenbanksystemen kann man Performanceprobleme fast immer auf schlechtes Datenbankdesign zurückführen.

Wir versuchen daher mal, die gängigsten Schema Design Pattern, für MongoDB, etwas näher zu beleuchten. Damit sollte es auch möglich sein, in die allgemeinen Methodiken und das Vokabular zu Schema Design einzusteigen. Mit diesen Grundlagen-Bausteinen sollte das Erstellen eines Datenbankschemas künftig mehr methodisch funktionieren als, wie bisher oft, eine Kunstform sein.

MongoDB nutzt ein dokumentenbasiertes Datenmodell, das von Natur aus flexibel ist und auf die speziellen Anforderungen einer Applikation angepaßt werden kann. Die Flexibilität kann aber auch dazu führen, daß ein Schema komplexer wird als nötig. Beim Erstellen eines Datenbankschemas sollte man immer die Punkte Performance, Skalierbarkeit und Einfachheit im Auge behalten.

Beginnen wir den Ausflug in das Schema Design mit dem wahrscheinlich grundlegendsten aller Pattern, dem Polymorphie Pattern. Dieses Pattern kommt zum Einsatz, wenn, wenn die Dokumente haben, die mehr Gemeinsamkeiten als Unterschiede aufweisen. Auch paßt es sehr gut, wenn wir die Dokumente in einer einzelnen Collection halten möchten.

  • Polymorphie Pattern

    • Wenn alle Dokumente einer Collection eine ähnliche, nicht zwangsläufig gleiche, Struktur haben dann nennen wir das das Polymorphie Pattern. Dieses Pattern ist nützlich, wenn wie Daten aus einer einzelnen Collection abfragen (query) möchten. Dafür dient es der Performance, wenn man Dokumente, basierend auf den Abfragen darauf, gruppiert. Also genau das Gegenteil, was man in einer relationalen Datenbank mit der Normalisierung von Daten machen würde.

      Nehmen wir, für ein Beispiel an, daß wir eine Datenbank mit Athleten aus verschiedenen Sportarten erstellen möchten. Wir möchten auf alle Athleten zugreifen können, aber die Attribute der Datensätze sind sehr unterschiedlich. An dieser Stelle kann das Polymorphie Pattern glänzen. Unsere Beispieldaten müssen nicht die gleichen Felder haben, obwohl sie in der selben Collection gespeichert sind.

      {
      "sport" : "Darts",
      "athlete_name": "Michael van Gerwen",
      "career_earnings": {
      "value": NumberDecimal("1441061"),
      "currency": "USD"
      },
      "perfect_games": 129,
      "career_titles": 43,
      "other_sports": "football"
      },
      {
      "sport" : "Tennis",
      "athlete_name": "Martina Navratilova",
      "career_earnings": {
      "value": NumberDecimal("216226089"),
      "currency": "USD"
      },
      "event": {
      "type": "singles",
      "career_tournaments": 390,
      "career_titles": 167
      }
      },


      Die Rekorde von professionellen Sportlern weisen Übereinstimmungen, aber auch Unterschiede auf. Durch das Polymorphie Pattern können wir diese Unterschiede einfach unterbringen. Könnten wir das nicht, bräuchten wir eine Vielzahl von Collections für die unterschiedlichen Sportarten. Wenn wir diese dann Abfragen wollten, müßten wir eine langsame und potentiell sehr komplexe Abfrage mit komplizierten Joins erstellen. Dank des Polymorphie Pattern können wir alle Athleten in einer Collection unterbringen und können diese auch jederzeit, mit einer vergleichsweise einfachen Abfrage, auslesen.

      Das Design Pattern läßt sich auch auf eingebettete Unterdokumente anwenden. Da Martina Navratilova, aus dem obigen Beispiel, nicht nur im Einzel angetreten ist, kann man ihren Datensatz folgendermaßen erweitern:

      {
      "sport" : "Tennis",
      "athlete_name": "Martina Navratilova",
      "career_earnings": {
      "value": NumberDecimal("216226089"),
      "currency": "USD"
      },
      "event": [{
      "type": "singles",
      "career_tournaments": 390,
      "career_titles": 167
      },
      {
      "type": "doubles",
      "career_tournaments": 233,
      "career_titles": 177,
      "partner": ["Tomanova", "Fernandez", "Morozova", ...]
      }]
      },


      • Beispiel Use Case

        • Ein Beispiel Use Case für das Polymorphie Pattern sind "Single View" Anwendungen. Wenn man sich vorstellt, daß man in einer Firma arbeitet, die immer wieder mal eine andere Firma, mit all ihren Technologien und Pattern, übernimmt. Jede Firma hat z.B. die Kundendaten in einem eigenen Format und einer eigenen Datenbank gespeichert. Diese Systeme zu integrieren und zu einem einheitlichen SQL Schema zusammenzuführen ist enorm zeitaufwendig und teuer.

          Eine Single View Applikation ist ein Anwendungsfall für das Polymorphie Pattern. Es funktioniert außerdem sehr gut für Anwendungen wie Produktkataloge, wo Produkte ganz unterschiedliche Attribute haben.

          • Zusammenfassung

            • Das Polymorphie Pattern kommt zum Einsatz, wenn Dokumente mehr Gemeinsamkeiten als Unterschiede haben.
              Typische Use Cases sind:
              • Single View Anwendungen
              • Content Management
              • Mobile Apps
              • Produktkataloge

Neueste Mitgliederaktivitäten

Diesen Community Beitrag weiterempfehlen