Wann sich die Einbettung von Daten und wann sich der Verweis auf Daten empfiehlt

  • 2 Minuten

In der vorherigen Lerneinheit wurden die Kundenadressdaten und die Kennwortdaten in ein neues Kundendokument eingebettet. Durch diese Maßnahme wird die Anzahl der Anforderungen reduziert. Dies bewirkt wiederum, dass Leistungsverbesserungen und Kostensenkungen erzielt werden. Daten können jedoch nicht immer eingebettet werden. Es gibt Regeln dafür, wann Sie Daten in ein Dokument einbetten sollten, statt in einer anderen Zeile auf sie zu verweisen.

Wann empfiehlt sich das Einbetten von Daten?

Betten Sie Daten in ein Dokument ein, wenn die folgenden Kriterien für die Daten gelten:

  • Zusammen lesen oder aktualisieren: Jeweils zusammen gelesene oder aktualisierte Daten werden fast immer als einzelnes Dokument modelliert. Dies reduziert die Anzahl der Anforderungen und erfüllt damit das Ziel von mehr Effizienz. Im vorliegenden Szenario werden alle Kundenentitäten gemeinsam gelesen oder geschrieben.
  • 1:1-Beziehung: Zum Beispiel verfügen Customer und CustomerPassword über eine 1:1-Beziehung.
  • 1:Wenige-Beziehung: In einer NoSQL-Datenbank ist es erforderlich, zwischen begrenzten und unbegrenzten 1:n-Beziehungen zu unterscheiden. Zwischen Customer und CustomerAddress besteht eine begrenzte 1:n-Beziehung, da Kunden in einer E-Commerce-Anwendung normalerweise nur wenige Lieferadressen haben. Wenn die Beziehung begrenzt ist, wird dies als 1:Wenige-Beziehung bezeichnet.

Wann empfiehlt es sich, auf Daten zu verweisen?

Auf Daten sollte als separate Dokumente verwiesen werden, wenn die folgenden Kriterien für die Daten gelten:

  • Unabhängig lesen oder aktualisieren: Dies gilt insbesondere, wenn Entitäten kombiniert werden, die zu großen Dokumenten führen würden. Bei Aktualisierungen in Azure Cosmos DB muss das betreffende Element insgesamt ersetzt werden. Wenn ein Dokument über ein paar Eigenschaften verfügt, die häufig zusammen mit einer großen Anzahl von weitgehend statischen Eigenschaften aktualisiert werden, ist es viel effizienter, das Dokument in zwei Teile aufzugliedern. Ein Dokument enthält dann den kleineren Satz der Eigenschaften, die häufig aktualisiert werden. Das andere Dokument enthält die statischen, unveränderlichen Werte.

  • 1:n-Beziehung: Dies gilt insbesondere, wenn die Beziehung nicht begrenzt ist. Wenn Sie über ein Dokument verfügen, das über einen unbekannten oder unbegrenzten Zeitraum größer wird, erhöhen sich auch die Kosten und Wartezeiten für diese Updates. Dies liegt daran, dass die zunehmende Größe des Updates mehr RU/s kostet und die Nutzdaten das Netzwerk durchlaufen, was ebenfalls ineffizient ist.

  • m:n-Beziehung: Ein Beispiel für diese Art der Beziehung wird in einer späteren Lerneinheit mit Produkttags erläutert.

    Durch das Trennen dieser Eigenschaften wird der Durchsatzverbrauch reduziert, um die Effizienz zu steigern. Außerdem wird die Wartezeit reduziert, um die Leistung zu verbessern.