Partitionierung und horizontale Skalierung in Azure Cosmos DB (2023)

  • Artikel
  • 10Minuten Lesedauer

GILT FÜR: Partitionierung und horizontale Skalierung in Azure Cosmos DB (1) NoSQLPartitionierung und horizontale Skalierung in Azure Cosmos DB (2) MongoDBPartitionierung und horizontale Skalierung in Azure Cosmos DB (3) CassandraPartitionierung und horizontale Skalierung in Azure Cosmos DB (4) GremlinPartitionierung und horizontale Skalierung in Azure Cosmos DB (5) Tabelle

Azure Cosmos DB arbeitet mit Partitionierung, um einzelne Container in einer Datenbank entsprechend den Leistungsanforderungen Ihrer Anwendung zu skalieren. Mithilfe der Partitionierung werden die Elemente in einem Container in Teilgruppen unterteilt, die als logische Partitionen bezeichnet werden. Logische Partitionen werden basierend auf dem Wert des Partitionsschlüssels erstellt, die 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.

Zusätzlich zu einem Partitionsschlüssel, der die logische Partition des Elements bestimmt, weist jedes Element in einem Container eine (innerhalb der logischen Partition eindeutige) Element-ID auf. 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 Auswirkungen auf die Leistung Ihrer Anwendung hat.

In diesem Artikel wird die Beziehung zwischen logischen und physischen Partitionen erörtert. Außerdem werden bewährte Methoden für die Partitionierung erläutert. Und Sie erhalten eine detaillierte Übersicht über die Funktionsweise der horizontalen Skalierung in Azure CosmosDB. Sie müssen diese internen Details nicht unbedingt verstehen, um Ihren Partitionsschlüssel auswählen zu können, aber wir haben sie angeführt, damit Sie Klarheit über die Funktionsweise von Azure CosmosDB haben.

Logische Partitionen

Eine logische Partition besteht aus einer Gruppe von Elementen mit demselben Partitionsschlüssel. Beispielsweise enthalten alle Elemente in einem Container mit Daten über Nahrungsmittel eine foodGroup-Eigenschaft. Sie können foodGroup als Partitionsschlüssel für den Container verwenden. 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 besteht keine Beschränkung für die Anzahl von logischen Partitionen in Ihrem Container. Jede logische Partition kann bis zu 20GB Daten speichern. Durch eine sinnvolle Auswahl des Partitionsschlüssels ergeben sich viele mögliche Werte. 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 20GB anwachsen. Durch Auswählen eines Partitionsschlüssels mit einer Vielzahl möglicher Werte können Sie sicherstellen, dass der Container skaliert werden kann.

Sie können mithilfe von Azure Monitor-Warnungen überwachen, ob sich die Größe einer logischen Partition 20GB annähert.

Physische Partitionen

Ein Container wird skaliert, indem Daten und Durchsatz auf physische Partitionen verteilt werden. Intern wird mindestens eine logische Partition einer einzelnen physischen Partition zugeordnet. Normalerweise verfügen kleinere Container über viele logische Partitionen, benötigen aber nur eine einzige physische Partition. Im Gegensatz zu logischen Partitionen sind physische Partitionen eine interne Implementierung des Systems, und sie werden vollständig von Azure CosmosDB verwaltet.

Die Anzahl der physischen Partitionen in Ihrem Container hängt von folgenden Faktoren ab:

Hinweis

Physische Partitionen sind eine interne Implementierung des Systems, die vollständig von Azure CosmosDB verwaltet werden. 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 die Partitionsschlüssel. Wenn Sie einen Partitionsschlüssel auswählen, der den verbrauchten Durchsatz gleichmäßig auf logische Partitionen verteilt, stellen Sie sicher, dass der Durchsatzverbrauch auf den physischen Partitionen ausgeglichen ist.

Es besteht keine Beschränkung für die Gesamtanzahl von physischen Partitionen in Ihrem Container. Wenn der bereitgestellte Durchsatz oder die Datengröße zunimmt, erstellt Azure CosmosDB automatisch neue physische Partitionen, indem die vorhandenen aufgeteilt werden. Die Aufteilung 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 für einen Container bereitgestellte Durchsatz wird gleichmäßig auf physische Partitionen aufgeteilt. Ein Design mit Partitionsschlüsseln, bei dem Anforderungen nicht gleichmäßig verteilt werden, kann dazu führen, dass zu viele Anforderungen an eine kleine Teilmenge der Partitionen gerichtet werden, die "heiß" werden. Bei heißen Partitionen wird der bereitgestellte Durchsatz nicht effizient genutzt, sodass es zu einer geringeren Datenrate und höheren Kosten kommen kann.

Sie können die physischen Partitionen Ihres Containers im Azure-Portal auf dem Blatt Metriken im Abschnitt Speicher anzeigen:

Im oben gezeigten Screenshot weist ein Container /foodGroup als Partitionsschlüssel auf. Jeder der drei Balken im Diagramm stellt eine physische Partition dar. In der Abbildung entspricht der Partitionsschlüsselbereich einer physischen Partition. Die ausgewählte physische Partition enthält die drei wichtigsten logischen Partitionen: Beef Products, Vegetable and Vegetable Products und Soups, Sauces, and Gravies.

Wenn Sie einen Durchsatz von 18.000Anforderungseinheiten pro Sekunde (RU/s) bereitstellen, kann jede der drei physischen Partitionen 1/3 des insgesamt bereitgestellten Durchsatzes nutzen. 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.000bereitgestellten RU/s der physischen Partition gemeinsam nutzen. Weil der bereitgestellte Durchsatz gleichmäßig auf die physischen Partitionen Ihres Containers aufgeteilt ist, müssen Sie unbedingt einen Partitionsschlüssel auswählen, der den verbrauchten Durchsatz gleichmäßig aufteilt. Informationen hierzu finden Sie unter Auswählen eines Partitionsschlüssels.

Verwalten logischer Partitionen

Azure Cosmos DB verwaltet die Platzierung logischer Partitionen in physischen Partitionen transparent und automatisch, um die Anforderungen an Skalierbarkeit und Leistung des Containers effizient zu erfüllen. Wenn sich die Anforderungen einer Anwendung an Durchsatz und Speicher erhöhen, verschiebt Azure CosmosDB logische Partitionen, um die Last automatisch auf eine größere Anzahl physischer Partitionen zu verteilen. Weitere Informationen zu physischen Partitionen finden Sie hier.

Azure Cosmos DB verwendet eine hashbasierte Partitionierung, um logische Partitionen auf physische Partitionen zu verteilen. Azure Cosmos DB erstellt für den Partitionsschlüsselwert eines Elements einen Hashwert. Das Hashergebnis bestimmt die physische 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 einzelnen logischen Partition zulässig.

Replikatgruppen

Jede physische Partition besteht aus Replikatgruppen. Jedes Replikat hostet eine Instanz der Datenbank-Engine. Eine Replikatgruppe macht die in der physischen Partition gespeicherten Daten dauerhaft, hochverfügbar und konsistent. Jedes Replikat, aus dem die physische Partition besteht, erbt das Speicherkontingent der Partition. Alle Replikate einer physischen Partition unterstützen gemeinsam den Durchsatz, der der physischen Partition zugeordnet wurde. Replikatgruppen werden von Azure CosmosDB automatisch verwaltet.

Normalerweise benötigen kleinere Container nur eine einzige physische Partition, sie verfügen jedoch trotzdem über mindestens 4Replikate.

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

Partitionierung und horizontale Skalierung in Azure Cosmos DB (7)

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.

Informationen zu den Beschränkungen im Hinblick auf Durchsatz, Speicher und Länge des Partitionsschlüssels finden Sie im Artikel Kontingente im Azure Cosmos DB-Dienst.

Die Auswahl Ihres Partitionsschlüssels ist eine einfache, aber wichtige Entwurfsentscheidung in Azure CosmosDB. Nachdem Sie Ihren Partitionsschlüssel ausgewählt haben, ist es nicht möglich, ihn direkt zu ändern. Wenn Sie Ihren Partitionsschlüssel ändern müssen, sollten Sie Ihre Daten mit dem neuen gewünschten Partitionsschlüssel in einen neuen Container verschieben. (Containerkopieraufträge helfen bei diesem Prozess.)

Für alle Container sollte Ihr Partitionsschlüssel die folgenden Punkte erfüllen:

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

  • Sollte nur String-Werte enthalten. Zahlen sollten idealerweise in eine String konvertiert werden, wenn es wahrscheinlich ist, dass sie außerhalb der Grenzen von Zahlen mit doppelter Genauigkeit gemäß IEEE754 binary64 liegen. In der Json-Spezifikation sind Gründe dafür genannt, warum die Verwendung von Zahlen außerhalb dieser Grenze im Allgemeinen aufgrund wahrscheinlicher Interoperabilitätsprobleme nicht empfohlen wird. Diese Bedenken sind besonders für die Partitionsschlüsselspalte relevant, da sie unveränderlich ist und eine Datenmigration erfordert, damit sie später geändert werden kann.

  • 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. Dadurch 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 mehr als 2048Byte lang sind. Wenn keine großen Partitionsschlüssel aktiviert sind, sollten die Werte 101Byte nicht überschreiten. Weitere Informationen finden Sie unter Große Partitionsschlüssel.

Wenn Sie in Azure CosmosDB 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.

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

Bei den meisten Containern müssen Sie beim Auswählen eines Partitionsschlüssels nur die oben aufgeführten Kriterien beachten. 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. Abfragen können effizient nur an die relevanten physischen Partitionen weitergeleitet werden, indem der Partitionsschlüssel in das Filterprädikat eingeschlossen wird.

Wenn es sich bei den meisten Anforderungen Ihrer Workload um Abfragen handelt und die meisten Abfragen einen Gleichheitsfilter für dieselbe Eigenschaft aufweisen, kann diese Eigenschaft eine gute Wahl für den Partitionsschlüssel darstellen. 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 Sie jedoch über einen kleinen Container verfügen, sind wahrscheinlich nicht genügend physische Partitionen vorhanden, um sich Gedanken über die Leistungsauswirkungen von partitionsübergreifenden Abfragen machen zu müssen. Die meisten kleinen Container in Azure CosmosDB 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 ein paar physische Partitionen, wenn einer der folgenden Punkte zutrifft:

  • Für Ihren Container werden über 30.000Anforderungseinheiten bereitgestellt.

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

Verwenden der Element-ID als Partitionsschlüssel

Wenn Ihr Container über eine Eigenschaft mit einer Vielzahl möglicher Werte verfügt, stellt diese Eigenschaft wahrscheinlich eine gute Wahl für den Partitionsschlüssel dar. Ein mögliches 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 natürlich eine gute Wahl für den Partitionsschlüssel dar.

Die Systemeigenschaft Element-ID ist in jedem in Ihrem Container enthaltenen Element vorhanden. Möglicherweise verfügen Sie über weitere Eigenschaften, die eine logische ID Ihres Elements darstellen. In vielen Fällen handelt es sich auch dabei aus den gleichen Gründen wie bei der Element-ID um eine gute Wahl für den Partitionsschlüssel.

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, leistet die Element-ID hervorragende Arbeit, um den RU-Verbrauch und die Datenspeicherung gleichmäßig zu verteilen.
  • 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.

Wenn Sie die Element-ID als Partitionsschlüssel auswählen, müssen Sie die folgenden Punkte berücksichtigen:

  • Bei Verwendung der Element-ID als Partitionsschlüssel wird diese im gesamten Container zu einem eindeutigen Bezeichner. Sie können keine Elemente verwenden, die eine doppelte Element-ID aufweisen.
  • 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.
  • Sie können keine gespeicherten Prozeduren oder Trigger für mehrere logische Partitionen ausführen.

Nächste Schritte

  • Erfahren Sie mehr über den bereitgestellten Durchsatz in Azure Cosmos DB.
  • Erfahren Sie mehr über die globale Verteilung in Azure Cosmos DB.
  • Erfahren Sie mehr über das Bereitstellen von Durchsatz für einen Azure Cosmos DB-Container.
  • Erfahren Sie mehr über das Bereitstellen von Durchsatz für eine Azure Cosmos DB-Datenbank.
  • Weitere Informationen finden Sie im Trainingsmodul zum Modellieren und Partitionieren Ihrer Daten in Azure Cosmos DB.
  • Versuchen Sie, die Kapazitätsplanung für eine Migration zu Azure CosmosDB durchzuführen? Sie können Informationen zu Ihrem vorhandenen Datenbankcluster für die Kapazitätsplanung verwenden.
    • Wenn Sie lediglich die Anzahl der virtuellen Kerne und Server in Ihrem vorhandenen Datenbankcluster kennen, lesen Sie die Informationen zum Schätzen von Anforderungseinheiten mithilfe von virtuellen Kernen oder virtuellen CPUs.
    • Wenn Sie die typischen Anforderungsraten für Ihre aktuelle Datenbankworkload kennen, lesen Sie die Informationen zum Schätzen von Anforderungseinheiten mit dem Azure CosmosDB-Kapazitätsplaner
Top Articles
Latest Posts
Article information

Author: Otha Schamberger

Last Updated: 01/07/2023

Views: 5710

Rating: 4.4 / 5 (55 voted)

Reviews: 86% of readers found this page helpful

Author information

Name: Otha Schamberger

Birthday: 1999-08-15

Address: Suite 490 606 Hammes Ferry, Carterhaven, IL 62290

Phone: +8557035444877

Job: Forward IT Agent

Hobby: Fishing, Flying, Jewelry making, Digital arts, Sand art, Parkour, tabletop games

Introduction: My name is Otha Schamberger, I am a vast, good, healthy, cheerful, energetic, gorgeous, magnificent person who loves writing and wants to share my knowledge and understanding with you.