Partitionierung und horizontale Skalierung in Azure Cosmos DB

Azure Cosmos DB verwendet Partitionierung zum Skalieren von Containern in einer Datenbank, um die Leistungsanforderungen Ihrer Anwendung zu erfüllen. Die Elemente werden in einem Container in eindeutige Teilgruppen unterteilt, die als logische Partitionen bezeichnet werden. Das Formular für logische Partitionen basiert auf dem Wert eines Partitionsschlüssels , der jedem Element in einem Container zugeordnet ist. Alle Elemente in einer logischen Partition haben denselben Partitionsschlüsselwert.

Angenommen, ein Container enthält Elemente. Jedes Element hat für die UserID-Eigenschaft einen eindeutigen Wert. Wenn UserID als Partitionsschlüssel für die Elemente in einem Container dient und es 1.000 eindeutige UserID-Werte gibt, werden für den Container 1.000 logische Partitionen erstellt.

Jedes Element in einem Container verfügt über einen Partitionsschlüssel , der seine logische Partition und eine innerhalb dieser Partition eindeutige Element-ID bestimmt. Durch die Kombination des Partitionsschlüssels und der Element-ID wird der Index des Elements erstellt, der das Element eindeutig identifiziert. Die Auswahl eines Partitionsschlüssels ist eine wichtige Entscheidung, die sich auf die Leistung Ihrer Anwendung auswirkt.

In diesem Artikel wird die Beziehung zwischen logischen und physischen Partitionen erläutert, bewährte Methoden für die Partitionierung erläutert und eine ausführliche Übersicht darüber bereitgestellt, wie die horizontale Skalierung in Azure Cosmos DB funktioniert. Sie müssen diese internen Details nicht verstehen, um Ihren Partitionsschlüssel auszuwählen, aber in diesem Artikel wird erläutert, wie Azure Cosmos DB funktioniert.

Logische Partitionen

Eine logische Partition ist eine Gruppe von Elementen, die denselben Partitionsschlüssel gemeinsam verwenden. Beispielsweise enthalten alle Elemente in einem Container mit Daten über Nahrungsmittel eine foodGroup-Eigenschaft. Wird als Partitionsschlüssel für den Container verwendet foodGroup . Elementgruppen mit bestimmten Werten für foodGroup, z.B. Beef Products, Baked Products und Sausages and Luncheon Meats, bilden eindeutige logische Partitionen.

Eine logische Partition definiert auch den Bereich für Datenbanktransaktionen. Sie können Elemente in einer logischen Partition mithilfe einer Transaktion mit Momentaufnahmeisolation aktualisieren. Wenn einem Container neue Elemente hinzugefügt werden, werden neue logische Partitionen transparent vom System erstellt. Sie müssen sich keine Gedanken über das Löschen einer logischen Partition machen, wenn die zugrunde liegenden Daten gelöscht werden.

Es gibt keine Beschränkung auf die Anzahl der logischen Partitionen in einem Container. Jede logische Partition kann bis zu 20 GB Daten speichern. Effektive Partitionsschlüssel weisen eine breite Palette möglicher Werte auf. Beispielsweise können in einem Container, in dem alle Elemente eine foodGroup-Eigenschaft aufweisen, die Daten innerhalb der logischen Partition Beef Products auf bis zu 20 GB anwachsen. Durch Auswählen eines Partitionsschlüssels mit einer Vielzahl möglicher Werte können Sie sicherstellen, dass der Container skaliert werden kann.

Verwenden Sie Azure Monitor Alerts, um zu überwachen, ob sich die Größe einer logischen Partition auf 20 GB annähert.

Physische Partitionen

Ein Container skaliert, indem Daten und Durchsatz über physische Partitionen verteilt werden. Intern wird eine oder mehrere logische Partitionen einer einzelnen physischen Partition zugeordnet. In der Regel verfügen kleinere Container über viele logische Partitionen, erfordern jedoch nur eine einzige physische Partition. Im Gegensatz zu logischen Partitionen handelt es sich bei physischen Partitionen um eine interne Systemimplementierung, und Azure Cosmos DB verwaltet sie vollständig.

Die Anzahl der physischen Partitionen in einem Container hängt von den folgenden Merkmalen ab:

• Der Menge des bereitgestellten Durchsatzes (jede einzelne physische Partition kann einen Durchsatz von bis zu 10.000 Anforderungseinheiten pro Sekunde bereitstellen) Die Beschränkung auf 10.000 RU/s für physische Partitionen bedeutet, dass für logische Partitionen ebenfalls eine Begrenzung auf 10.000 RU/s besteht, da jede logische Partition nur einer physischen Partition zugeordnet ist.

• Der gesamte Datenspeicher (jede einzelne physische Partition kann bis zu 50 Gigabyte an Daten speichern).

Hinweis

Physische Partitionen sind eine interne Systemimplementierung, die vollständig von Azure Cosmos DB verwaltet wird. Sie müssen sich beim Entwickeln Ihrer Lösungen nicht auf physische Partitionen konzentrieren, da Sie diese nicht kontrollieren können. Konzentrieren Sie sich stattdessen auf Partitionsschlüssel. Durch Auswählen eines Partitionsschlüssels, der den Durchsatz gleichmäßig über logische Partitionen verteilt, wird ein ausgewogener Durchsatzverbrauch über physische Partitionen hinweg sichergestellt.

Es gibt keine Beschränkung auf die Gesamtanzahl der physischen Partitionen in einem Container. Wenn der bereitgestellte Durchsatz oder die Datengröße zunimmt, erstellt Azure Cosmos DB automatisch neue physische Partitionen, indem die vorhandenen geteilt werden. Die Teilung physischer Partitionen hat keine Auswirkungen auf die Verfügbarkeit Ihrer Anwendung. Nach der Aufteilung einer physischen Partition bleiben alle Daten innerhalb einer einzelnen logischen Partition weiterhin auf derselben physischen Partition gespeichert. Bei der Aufteilung physischer Partitionen wird einfach eine neue Zuordnung der logischen Partitionen zu physischen Partitionen erstellt.

Der bereitgestellte Durchsatz für einen Container teilt gleichmäßig zwischen physischen Partitionen auf. Ein Partitionsschlüsselentwurf, der Anforderungen nicht gleichmäßig verteilt, kann zu viele Anforderungen führen, die zu einer kleinen Teilmenge von Partitionen geleitet werden, die "heiß" werden. Hot Partitions verursachen eine ineffiziente Verwendung des bereitgestellten Durchsatzes, was zu einer Zinsbegrenzung und höheren Kosten führen kann.

Nehmen wir zum Beispiel einen Container, bei dem der Pfad /foodGroup als Partitionsschlüssel angegeben ist. Der Container kann eine beliebige Anzahl physischer Partitionen aufweisen, in diesem Beispiel wird jedoch davon ausgegangen, dass er über drei verfügt. Eine einzelne physische Partition kann mehrere Partitionsschlüssel enthalten. Die größte physische Partition könnte zum Beispiel die drei größten logischen Partitionen enthalten: Beef Products, Vegetable and Vegetable Products, und Soups, Sauces, and Gravies.

Wenn Sie einen Durchsatz von 18.000 Anforderungseinheiten pro Sekunde (RU/s) zuweisen, verwendet jede der drei physischen Partitionen ein Drittel des gesamten bereitgestellten Durchsatzes. Innerhalb der ausgewählten physischen Partition können die logischen Partitionsschlüssel Beef Products, Vegetable and Vegetable Products und Soups, Sauces, and Gravies die 6.000 bereitgestellten RU/s der physischen Partition gemeinsam nutzen. Weil der bereitgestellte Durchsatz gleichmäßig auf die physischen Partitionen Ihres Containers verteilt ist, müssen Sie unbedingt einen Partitionsschlüssel auswählen, der den verbrauchten Durchsatz gleichmäßig verteilt. Weitere Informationen finden Sie unter Auswählen des richtigen logischen Partitionsschlüssels.

Verwalten logischer Partitionen

Azure Cosmos DB verwaltet automatisch die Platzierung logischer Partitionen auf physischen Partitionen, um den Skalierbarkeits- und Leistungsanforderungen des Containers gerecht zu werden. Wenn der Durchsatz und die Speicheranforderungen einer Anwendung steigen, verschiebt Azure Cosmos DB logische Partitionen, um die Last über mehr physische Partitionen zu verteilen. Erfahren Sie mehr über physische Partitionen.

Azure Cosmos DB verwendet hashbasierte Partitionierung, um logische Partitionen über physische Partitionen zu verteilen. Azure Cosmos DB erstellt für den Partitionsschlüsselwert eines Elements einen Hashwert. Das Hashergebnis bestimmt die logische Partition. Anschließendverteilt Azure Cosmos DB den Schlüsselbereich der Partitionsschlüsselhashes gleichmäßig auf die physischen Partitionen.

Transaktionen in gespeicherten Prozeduren oder Triggern sind nur für Elemente in einer einzigen logischen Partition zulässig.

Replikatgruppen

Jede physische Partition besteht aus einer Reihe von Replikaten, auch als Replikatsatz bezeichnet. Jedes Replikat hostet eine Instanz der Datenbank-Engine. Bei einer Replikatgruppe wird der Datenspeicher in der physischen Partition dauerhaft, hochverfügbar und konsistent. Jedes Replikat in der physischen Partition erbt das Speicherkontingent der Partition. Alle Replikate einer physischen Partition unterstützen den Durchsatz, der dieser physischen Partition zugeordnet ist. Replikatgruppen werden von Azure Cosmos DB automatisch verwaltet.

Kleinere Container benötigen in der Regel eine einzelne physische Partition, verfügen aber weiterhin über mindestens vier Replikate.

Diese Abbildung zeigt, wie logische Partitionen global verteilten physischen Partitionen zugeordnet werden. Partitionssatz in der Abbildung bezieht sich auf eine Gruppe physischer Partitionen, die dieselben logischen Partitionsschlüssel in mehreren Regionen verwalten:

Auswählen eines Partitionsschlüssels

Ein Partitionsschlüssel besteht aus zwei Komponenten: dem Partitionsschlüsselpfad und dem Partitionsschlüsselwert. Beispiel: Wenn Sie bei dem Element { "userId" : "Andrew", "worksFor": "Microsoft" } „userId“ als Partitionsschlüssel auswählen, sind dies die beiden Partitionsschlüsselkomponenten:

• Der Partitionsschlüsselpfad (Beispiel: "/userId"). Der Partitionsschlüsselpfad akzeptiert alphanumerische Zeichen und Unterstriche (_). Mithilfe der Standardpfadnotation (/) können Sie auch geschachtelte Objekte verwenden.

• Der Partitionsschlüsselwert (Beispiel: "Andrew"). Der Partitionsschlüsselwert kann vom Typ „string“ oder „numeric“ sein.

Erfahren Sie mehr über die Grenzwerte für Durchsatz, Speicher und Partitionsschlüssellänge im Artikel zu Azure Cosmos DB-Dienstkontingenten .

Die Auswahl Ihres Partitionsschlüssels ist eine einfache, aber wichtige Entwurfsentscheidung in Azure Cosmos DB. Nachdem Sie den Partitionsschlüssel ausgewählt haben, können Sie ihn nicht mehr ändern. Wenn Sie den Partitionsschlüssel ändern müssen, verschieben Sie Ihre Daten mit dem gewünschten Partitionsschlüssel in einen neuen Container. Containerkopieaufträge helfen bei diesem Prozess. Alternativ können Sie globale sekundäre Indizes (Vorschau) hinzufügen, um eine Kopie Ihrer Daten mit verschiedenen Partitionsschlüsseln zu erstellen, die für bestimmte Abfragemuster optimiert sind.

Für alle Container sollte der Partitionsschlüssel:

• Er sollte einer Eigenschaft mit einem Wert entsprechen, der sich nicht ändert. Wenn eine Eigenschaft Ihr Partitionsschlüssel ist, können Sie den Wert dieser Eigenschaft nicht aktualisieren.

• Enthalten nur String Werte – oder konvertieren Sie Zahlen in eine String , wenn sie die Grenzen doppelter Genauigkeitsnummern nach IEEE 754 binary64 überschreiten können. Die Json-Spezifikation erläutert, warum die Verwendung von Zahlen außerhalb dieser Grenze aufgrund von Interoperabilitätsproblemen eine schlechte Methode ist. Diese Bedenken sind insbesondere für die Partitionsschlüsselspalte relevant, da sie unveränderlich ist und die Datenmigration später erforderlich ist.

• Er sollte eine hohe Kardinalität aufweisen. Anders ausgedrückt: Die Eigenschaft sollte über eine Vielzahl möglicher Werte verfügen.

• Er sollte die zu verbrauchenden Anforderungseinheiten (Request Units, RUs) und die Datenspeicherung gleichmäßig auf alle logischen Partitionen verteilen. Durch diese Verteilung wird ein gleichmäßiger RU-Verbrauch und eine gleichmäßige Speicherverteilung auf Ihren physischen Partitionen sichergestellt.

• Es sollten in der Regel Werte verwendet werden, die nicht größer als 2048 Bytes sind. Wenn keine großen Partitionsschlüssel aktiviert sind, sollten die Werte 101 Bytes nicht überschreiten. Weitere Informationen finden Sie unter Große Partitionsschlüssel.

Wenn Sie in Azure Cosmos DB ACID-Transaktionen mit mehreren Elementen benötigen, müssen Sie gespeicherte Prozeduren oder Trigger verwenden. Alle JavaScript-basierten gespeicherten Prozeduren und Trigger sind auf den Bereich einer einzelnen logischen Partition beschränkt.

Hinweis

Wenn Sie nur über eine physische Partition verfügen, ist der Wert des Partitionsschlüssels möglicherweise nicht relevant, da alle Abfragen auf dieselbe physische Partition abzielen.

Typen von Partitionsschlüsseln

Partitionierungsstrategie	Wann verwendet werden soll	Vorteile	Nachteile
Regulärer Partitionsschlüssel (z. B. CustomerId, OrderId)	Wird verwendet, wenn der Partitionsschlüssel eine hohe Kardinalität aufweist und sich an Abfragemustern richtet (z. B. filtern nach CustomerId). Geeignet für Workloads, bei denen Abfragen hauptsächlich auf die Daten eines einzelnen Kunden ausgerichtet sind (z. B. Abrufen aller Bestellungen für einen Kunden).	Einfach zu verwalten. Effiziente Abfragen, wenn das Zugriffsmuster mit dem Partitionsschlüssel übereinstimmt (z. B. Abfragen aller Bestellungen nach CustomerId). Verhindert partitionsübergreifende Abfragen, wenn Zugriffsmuster konsistent sind.	Risiko von Hot Partitionen, wenn einige Werte (z. B. einige Kunden mit hohem Datenverkehr) mehr Daten generieren als andere. Kann den Grenzwert von 20 GB pro logischer Partition erreichen, wenn das Datenvolume für einen bestimmten Schlüssel schnell wächst.
Synthetischer Partitionsschlüssel (z. B. CustomerId + OrderDate)	Wird verwendet, wenn kein einzelnes Feld sowohl über eine hohe Kardinalität verfügt als auch Übereinstimmungen mit Abfragemustern. Gut für Schreiblasten, bei denen Daten gleichmäßig auf physische Partitionen verteilt werden müssen (z. B. viele Bestellungen, die am selben Datum getätigt wurden).	Hilft beim gleichmäßigen Verteilen von Daten über Partitionen, wodurch Hot Partitionen reduziert werden (z. B. das Verteilen von Bestellungen durch CustomerId und OrderDate). Verteilt Schreibvorgänge auf mehrere Partitionen und verbessert den Durchsatz.	Abfragen, die nur nach einem Feld filtern (z. B. nur CustomerId), können zu partitionsübergreifenden Abfragen führen. Partitionsübergreifende Abfragen können zu einer höheren RU-Auslastung (2-3 RU/s Zusätzliche Gebühr für jede physische Partition, die vorhanden ist) und zu einer zusätzlichen Latenz führen.
Hierarchischer Partitionsschlüssel (HPK) ( z. B. CustomerId/OrderId, StoreId/ProductId)	Wird verwendet, wenn Sie eine Partitionierung mit mehreren Ebenen benötigen, um große Datasets zu unterstützen. Ideal, wenn Abfragen nach der ersten und zweiten Ebene der Hierarchie filtern.	Verhindert den Grenzwert von 20 GB, indem mehrere Partitionsebenen erstellt werden. Effiziente Abfrage auf beiden Hierarchischen Ebenen (z. B. zuerst nach CustomerID und dann nach OrderID filtern). Minimiert partitionsübergreifende Abfragen für Abfragen auf oberster Ebene (z. B. Abrufen aller Daten aus einer bestimmten Kunden-ID).	Erfordert eine sorgfältige Planung, um sicherzustellen, dass der Schlüssel auf oberster Ebene eine hohe Kardinalität aufweist und in den meisten Abfragen enthalten ist. Komplexer zu verwalten als ein regulärer Partitionsschlüssel. Wenn Abfragen nicht mit der Hierarchie übereinstimmen (z. B. nur nach OrderID filtern, wenn CustomerID die erste Ebene ist), kann die Abfrageleistung beeinträchtigt werden.
Global Secondary Index (GSI) – Vorschau (z. B. verwendet die Quelle CustomerId, GSI verwendet OrderId)	Verwenden Sie diese Option, wenn Sie keinen einzelnen Partitionsschlüssel finden können, der für alle Abfragemuster geeignet ist. Ideal für Workloads, die von mehreren unabhängigen Eigenschaften effizient abfragen müssen und über eine große Anzahl physischer Partitionen verfügen.	Entfernt partitionsübergreifende Abfragen bei Verwendung des GSI-Partitionsschlüssels. Ermöglicht mehrere Abfragemuster für dieselben Daten mit der automatischen Synchronisierung aus dem Quellcontainer. Leistungsisolation zwischen Arbeitslasten.	Jede GSI hat zusätzliche Speicher- und RU-Kosten. Die Daten in der GSI sind letztendlich mit dem Quellcontainer konsistent.

Partitionsschlüssel für Container mit vielen Lesevorgängen

Bei den meisten Containern sind diese Kriterien alles, was Sie beim Auswählen eines Partitionsschlüssels berücksichtigen müssen. Für große Container mit vielen Lesevorgängen sollten Sie jedoch einen Partitionsschlüssel auswählen, der häufig als Filter in Ihren Abfragen verwendet wird. Wenn Sie den Partitionsschlüssel in das Filter-Prädikat einschließen, können Abfragen effizient an die relevanten physischen Partitionen weitergeleitet werden.

Diese Eigenschaft ist eine gute Partitionsschlüsselauswahl, wenn die meisten Anforderungen Ihrer Workload Abfragen sind und die meisten Ihrer Abfragen einen Gleichheitsfilter für dieselbe Eigenschaft verwenden. Wenn Sie z. B. häufig eine Abfrage ausführen, die nach UserID filtert, würde durch Auswählen von UserID als Partitionsschlüssel die Anzahl der partitionsübergreifenden Abfragen reduziert.

Wenn Ihr Container klein ist, verfügen Sie wahrscheinlich nicht über genügend physische Partitionen, um sich gedanken über die Leistung von partitionsübergreifenden Abfragen zu machen. Die meisten kleinen Container in Azure Cosmos DB benötigen nur eine oder zwei physische Partitionen.

Wenn Ihr Container auf mehr als ein paar physische Partitionen anwachsen könnte, sollten Sie unbedingt einen Partitionsschlüssel auswählen, der die Anzahl von partitionsübergreifenden Abfragen minimiert. Ihr Container benötigt mehr als einige physische Partitionen, wenn eines der folgenden Szenarien zutrifft:

• Ihr Container verfügt über mehr als 30.000 Anforderungseinheiten bereitgestellt

• In Ihrem Container werden mehr als 100 GB Daten gespeichert.

Globale sekundäre Indizes für partitionsübergreifende Abfragen

Wenn Ihre Anwendung Daten mithilfe mehrerer verschiedener Eigenschaften effizient abfragen muss, stellen globale sekundäre Indizes (Vorschau) eine Alternative zur Verwendung einer Partitionsschlüsselstrategie für das Dataset bereit. Globale sekundäre Indizes sind zusätzliche Container mit unterschiedlichen Partitionsschlüsseln, die automatisch mit Daten aus Ihrem Quellcontainer synchronisiert werden.

Berücksichtigen Sie globale sekundäre Indizes, wenn:

• Sie verfügen über mehrere Abfragemuster, die von einer einzelnen Partitionsschlüsselstrategie nicht erfüllt werden können.
• Das Ändern des vorhandenen Partitionsschlüssels wäre störend
• Sie müssen analytische oder Sucharbeitslasten von Transaktionsvorgängen isolieren.

Globale sekundäre Indizes helfen dabei, partitionsübergreifende Abfragen zu vermeiden, indem dieselben Daten mit unterschiedlichen Partitionsschlüsseln gespeichert werden, die für bestimmte Abfragemuster optimiert sind. Dieser Ansatz kann den RU-Verbrauch erheblich reduzieren und die Abfrageleistung für Szenarien verbessern, in denen die Partitionsschlüsseloptimierung allein nicht ausreicht.

Verwenden der Element-ID als Partitionsschlüssel

Hinweis

Dieser Abschnitt gilt in erster Linie für die API für NoSQL. Andere APIs, z. B. die API für Gremlin, unterstützen den eindeutigen Bezeichner nicht als Partitionsschlüssel.

Wenn Ihr Container über eine Eigenschaft mit einem breiten Spektrum möglicher Werte verfügt, ist dies wahrscheinlich eine großartige Auswahl für Partitionsschlüssel. Ein Beispiel für eine solche Eigenschaft ist die Element-ID. Für kleine Container mit vielen Lesevorgängen oder für beliebig große Container mit vielen Schreibvorgängen stellt die Element-ID (/id) natürlich eine gute Wahl für den Partitionsschlüssel dar.

Die Systemeigenschaftselement-ID ist in jedem Element in Ihrem Container vorhanden. Möglicherweise verfügen Sie über weitere Eigenschaften, die eine logische ID Ihres Elements darstellen. In vielen Fällen sind diese eindeutigen Bezeichner auch großartige Partitionsschlüsselauswahlen aus denselben Gründen wie die Element-ID.

Die Element-ID stellt aus den folgenden Gründen eine gute Wahl für den Partitionsschlüssel dar:

• Es ist eine Vielzahl möglicher Werte vorhanden (eine eindeutige Element-ID pro Element).
• Weil pro Element eine eindeutige Element-ID vorhanden ist, eignet sich die Element-ID hervorragend für die gleichmäßige Verteilung des RU-Verbrauchs und der Datenspeicherung.
• Sie können problemlos effiziente Punktlesevorgänge ausführen, weil Ihnen der Partitionsschlüssel eines Elements immer bekannt ist, wenn Sie die entsprechende Element-ID kennen.

Beachten Sie beim Auswählen der Element-ID als Partitionsschlüssel die folgenden Einschränkungen:

• Wenn es sich bei der Element-ID um den Partitionsschlüssel handelt, wird sie zu einem eindeutigen Bezeichner für den gesamten Container. Sie können keine Elemente mit doppelten Bezeichnern erstellen.
• Wenn Sie über einen Container mit vielen Lesevorgängen verfügen, der viele physische Partitionen umfasst, sind Abfragen effizienter, wenn ein Gleichheitsfilter mit der Element-ID verwendet wird.
• Gespeicherte Prozeduren oder Trigger können nicht auf mehrere logische Partitionen abzielen.

Zugehöriger Inhalt

• Bereitgestellter Durchsatz in Azure Cosmos DB
• Globale Verteilung in Azure Cosmos DB
• Schulung: Modellieren und Partitionieren Ihrer Daten in Azure Cosmos DB