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 Erweiterte-Referenz-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-extended-reference-pattern
      Übersetzung mit freundlicher Genehmigung von MongoDB


      Das verwendete Schema wir in der Regel durch die Charakteristik der Datenzugriffe bestimmt. Gibt es eine gewisse Anzahl an gleichen Feldern, dann könnte das "Attribute Pattern" eine gute Wahl sein
      https://www.qualiero.com/community/mongodb/mongodb-theorie/mongodb-patterns-das-attribute-pattern.html
      Wird die Anwendung durch den Zugriff auf wenige Datensätze ausgebremst, dann könnte man das "Ausreiser Pattern" in Betracht ziehen
      https://www.qualiero.com/community/mongodb/mongodb-theorie/mongodb-patterns-das-ausreisser-pattern.html
      Manche Patterns, wie z.B. das "Subset Pattern", erzeugen Verweise auf andere Collections und setzen auf JOIN-Operationen, um die Daten wieder zusammenzuführen
      https://www.qualiero.com/community/mongodb/mongodb-theorie/mongodb-patterns-das-subset-pattern.html
      Was aber, wenn wir viele JOIN-Operationen benötigen, um häufig abgerufene Daten zusammen zu bringen? An dieser Stelle können wir das "Erweiterte Referenz Pattern" einsetzen.

      • Das Erweiterte Referenz Pattern

        • Es gibt Fälle, da macht es Sinn Daten auf unterschiedliche Collections aufzuteilen. z.B. wenn man einzelne Entitäten als Unterschiedliche Einheiten betrachtet und behandelt. Das könnte in einer E-Commerce Anwendung so der Fall sein, dort hat man Bestellungen und dazu Kunden. Jedes davon ist eine logisch unterschiedliche Einheit.

          • Bestellungen Collection

            • {
              _id: ObjectId("507f1f77bcf86cd799439011"),
              date: ISODate("2019-02-18"),
              customer_id: 123,
              order: [
              {
              product: "widget",
              qty: 5,
              cost: {
              value: NumberDecimal("11.99"),
              currency: "USD"
              }
              }
              ]
              }

              • Kunden Collection

                • {
                  _id: 123,
                  name: "Katarina Pope",
                  street: "123 Main St.",
                  city: "Somewhere",
                  country: "Someplace",
                  ...
                  }


                  Vom Performance-Standpunkt betrachtet kann das zu einem Problem werden, wenn wir die einzelnen Informationen zusammenfügen und in einer speziellen Reihenfolge anzeigen sollen. Ein Kunde kann N Bestellungen haben, was eine 1-N Beziehung erzeugt. Wenn wir das von der anderen Seite, der Bestellung, betrachten dann gibt es eine N-1 Beziehung zum Kunden. Wenn wir nun die Kundeninformationen in jede Bestellung schreiben, nur um die Anzahl der JOINS zu reduzieren, dann erzeugen wir eine ganze Menge redundanter Informationen. Dazu kommt noch, dass wir evtl. gar nicht alle Informationen, über einen Kunden, in einer Bestellung brauchen.

                  Das "Erweiterte Referenz Pattern" bietet eine großartige Möglichkeit, um diese Konstellationen zu behandeln. Anstatt alle Informationen des Kunden zu duplizieren, kopieren wir nur diejenigen, die regelmäßig benötigt werden. Es werden als nicht alle Felder oder eine Referenz gespeichert, sondern die Felder mit der höchsten Priorität, die auch regelmäßig verwendet werden. z.B. Name und Adresse.

                  • Bestellungen Collection

                    • {
                      _id: ObjectId("507f1f77bcf86cd799439011"),
                      date: ISODate("2019-02-18"),
                      customer_id: 123,
                      shipping_adress: {
                      name: "Katarina Pope",
                      street: "123 Main St.",
                      city: "Somewhere",
                      country: "Someplace"
                      },
                      order: [
                      {
                      product: "widget",
                      qty: 5,
                      cost: {
                      value: NumberDecimal("11.99"),
                      currency: "USD"
                      }
                      }
                      ]
                      }


                      Was man sich dabei bewusst machen muss, ist dass die daten dupliziert werden. Aus diesem Grund funktioniert das am besten mit Feldern, das Hauptdokuments, die sich nicht regelmäßig ändern. Die "user_id" oder der "name" sind deshalb Felder, die sich normalerweise gut eignen.

                      Wir kopieren also nur die Felder, die wir für den jeweiligen Anwendungsfall benötigen. Wenn wir z.B. an eine Rechnung denken, brauchen wir dort eine zweite Telefonnummer oder eine Adresse, die nichts mit der Bestellung zu tun hat? Höchstwahrscheinlich nicht, deshalb können wir diese im Kundendatensatz belassen und bei Bedarf auf diesen referenzieren.

                      Wenn Daten geupdated werden, dann müssen wir das natürlich vorsehen. Welche erweiterten Referenzen haben sich geändert? Wann müssen diese geupdated werden? Wenn es sich z.B. um die Rechnungsadresse handelt, macht es dann Sinn diese für historische Datensätze zu ändern oder können wir diese einfach so belassen? In diesen Fällen macht eine Vervielfältigung der Daten durchaus Sinn, denn der historische Kontext geht nicht verloren, die Rechnung wurde ja damals an diese Adresse geschickt.

                      • Beispiel Use Case

                        • Eine Bestell-Verwaltung ist der Klassiker unter den Use-Cases für dieses Pattern. Gerade bei der N-1 Beziehung zwischen Bestellungen und Kunden bringt uns das reduzieren von JOINS einen Performancegewinn. Durch das Hinzufügen der häufig benötigten Informationen sparen wir uns einen Verarbeitungsschritt.

                          Wenn wir das Beispiel weiterdenken, auf einer Rechnung für einen Amboss könnte z.B. Acme Inc. als Lieferant aufgeführt sein. Die Kontaktinformationen für Acme Inc. für die Rechnung nicht besonders wichtig. Diese Information währe in einer separaten Lieferanten-Collection besser aufgehoben und kann referenziert werden.

                          • Zusammenfassung

                            • Das "Erweiterte Referenz Pattern" ist eine wunderbare Lösung, wenn eine Applikation häufig gleiche JOIN Operationen benötigt. Durch das identifizieren der häufig verwendeten Felder auf der Lookup-Seite, und das Duplizieren in das Hauptdokument, kann ein deutlicher Performancegewinn erreicht werden. Der Grund dafür sind weniger Read-Operationen auf der Datenbankseite. Ein Seiteneffekt des Patterns, den man nicht aus dem Auge verlieren sollte, ist dass die Daten vervielfältigt werden und evtl. künftig an mehreren Stellen gepflegt werden müssen.

                              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