Best Practices für das Skalieren des bereitgestellten Durchsatzes

In diesem Artikel werden bewährte Methoden und Strategien zum Skalieren des Durchsatzes Ihrer Datenbank oder Ihres Containers (Sammlung, Tabelle oder Diagramm) beschrieben. Die Konzepte gelten, wenn Sie entweder die bereitgestellten manuellen Anforderungseinheiten pro Sekunde (RU/s) oder die automatische Skalierung der maximalen RU/s aller Ressourcen für eine der Azure Cosmos DB-APIs erhöhen.

Voraussetzungen

• Wenn Sie neu bei der Partitionierung und Skalierung in Azure Cosmos DB sind, lesen Sie Die Partitionierung und horizontale Skalierung in Azure Cosmos DB.
• Wenn Sie planen, Ihre RU/s aufgrund von 429 Ausnahmen zu skalieren, lesen Sie die Anleitungen in " Diagnose" und behandeln Sie "Anforderungsrate zu groß" (429) Ausnahmen. Ermitteln Sie vor dem Erhöhen der RU/Sekunde die Grundursache des Problems und ob die Erhöhung der RU/Sekunde die richtige Lösung ist.

Hintergrundinformationen zum Skalieren von RU/Sekunde

Wenn Sie eine Anforderung senden, um die RU/s Ihrer Datenbank oder Ihres Containers zu erhöhen, je nach angefordertem RU/s und Ihrem aktuellen physischen Partitionslayout, wird der Skalierungsvorgang entweder sofort oder asynchron abgeschlossen (in der Regel 4-6 Stunden).

• Sofortige Skalierung:

  • Wenn die angeforderten RU/Sekunde vom aktuellen Layout der physischen Partitionen unterstützt werden können, muss Azure Cosmos DB weder Partitionen teilen noch neue Partitionen hinzufügen.
  • Daher wird der Vorgang sofort abgeschlossen, und die RU/Sekunde stehen zur Verwendung zur Verfügung.

• Asynchrone Skalierung:

  • Wenn die angeforderten RU/s höher sind als das, was vom physischen Partitionslayout unterstützt werden kann, teilt Azure Cosmos DB vorhandene physische Partitionen auf. Dies geschieht, bis die Ressource über die Mindestanzahl von Partitionen verfügt, die für die Unterstützung der angeforderten RU/Sekunde erforderlich sind.
  • Daher kann die Ausführung des Vorgangs einige Zeit dauern, in der Regel 4 bis 6 Stunden. Jede physische Partition kann einen Durchsatz von maximal 10.000 RU/Sekunde (dies gilt für alle APIs) und eine Speichergröße von 50 GB unterstützen (dies gilt für alle APIs, mit Ausnahme von Cassandra mit 30 GB Speicher).

  Hinweis

  Wenn Sie einen Änderungs-Schreibbereichsvorgang ausführen oder einen neuen Bereich hinzufügen/entfernen , während ein asynchroner Skalierungsvorgang ausgeführt wird, wird der Durchsatzskalierungsvorgang angehalten. Es wird automatisch fortgesetzt, sobald der Failovervorgang oder das Hinzufügen/Entfernen der Region abgeschlossen ist.

• Sofortige Skalierung:

  • Für den Skalierungsvorgang muss Azure Cosmos DB keine neuen Partitionen teilen oder hinzufügen.
  • Daher wird der Vorgang sofort abgeschlossen, und die RU/Sekunde stehen zur Verwendung zur Verfügung.
  • Das Hauptergebnis dieses Vorgangs besteht darin, dass RUs pro physischer Partition reduziert werden.

Hochskalieren von RU/Sekunde ohne Änderung des Partitionslayouts

Schritt 1: Ermitteln der aktuellen Anzahl physischer Partitionen

Navigieren Sie zu Erkenntnisse>Durchsatz>Normalisierter RU-Verbrauch (%) nach PartitionKeyRangeID. Zählen Sie die eindeutige Anzahl von PartitionKeyRangeIDs.

Jede PartitionKeyRangeID ist einer physischen Partition zugeordnet und wird zugewiesen, um Daten für einen Bereich möglicher Hashwerte zu speichern.

Azure Cosmos DB verteilt Ihre Daten basierend auf Ihrem Partitionsschlüssel auf logische und physische Partitionen, um die horizontale Skalierung zu ermöglichen. Wenn Daten geschrieben werden, verwendet Azure Cosmos DB den Hash des Partitionsschlüsselwerts, um zu ermitteln, auf welcher logischen und physischen Partition sich die Daten befinden.

Schritt 2: Berechnen des maximalen Standarddurchsatzes

Die höchste Anzahl von RU/Sekunde, auf die Sie skalieren können, ohne dass Azure Cosmos DB Partitionen teilen muss, ist gleich Current number of physical partitions * 10,000 RU/s.

Sie können diesen Wert vom Azure Cosmos DB-Ressourcenanbieter abrufen. Führen Sie eine GET-Anforderung für Ihre Datenbank- oder Container-Durchsatzeinstellungsobjekte durch und rufen Sie die Eigenschaft instantMaximumThroughput ab. Dieser Wert ist auch auf der Seite " Skalierung und Einstellungen" Ihrer Datenbank oder Ihres Containers im Portal verfügbar.

Beispiel

Angenommen, Sie haben einen vorhandenen Container mit fünf physischen Partitionen und 30.000 RU/s des manuell bereitgestellten Durchsatzes. Sie können die RU/s 5 * 10,000 RU/s = 50,000 RU/s sofort erhöhen. Analog dazu könnten wir bei einem Container mit maximal 30.000 automatisch skalierten RU/Sekunde (Skalierung zwischen 3.000 und 30.000 RU/Sek.) sofort auf 50.000 RU/Sekunde (Skalierung zwischen 5.000 und 50.000 RU/Sek.) erhöhen.

Sicherstellen einer gleichmäßigen Datenverteilung während der asynchronen Skalierung

Hintergrund

Wenn Sie die RU/s über die aktuelle Anzahl hinaus physical partitions * 10,000 RU/serhöhen, teilt Azure Cosmos DB vorhandene Partitionen auf, bis die neue Anzahl von Partitionen = ROUNDUP(requested RU/s / 10,000 RU/s). Bei einer Teilung werden übergeordnete Partitionen in zwei untergeordnete Partitionen aufgeteilt.

Angenommen, Sie haben einen Container mit drei physischen Partitionen und 30.000 RU/s des manuell bereitgestellten Durchsatzes. Wenn Sie den Durchsatz auf 45.000 RU/s erhöhen, teilt Azure Cosmos DB zwei der vorhandenen physischen Partitionen auf, sodass insgesamt vorhanden sind ROUNDUP(45,000 RU/s / 10,000 RU/s) = 5 physical partitions.

Wenn Sie über eine Arbeitsauslastung verfügen, die gleichmäßig verteilt ist in Bezug auf Speicher- und Anforderungsvolume – in der Regel durch Partitionierung durch Felder mit hoher Kardinalität wie /id- wird empfohlen, RU/s so festzulegen, dass alle Partitionen gleichmäßig verteilt werden, wenn Sie eine Skalierung ausführen.

Um zu sehen, warum, nehmen wir uns ein Beispiel an, in dem Sie über einen vorhandenen Container mit zwei physischen Partitionen verfügen, 20.000 RU/s und 80 GB Daten.

Dank der Auswahl eines guten Partitionsschlüssels mit hoher Kardinalität werden die Daten ungefähr gleichmäßig auf beide physischen Partitionen verteilt. Jeder physischen Partition werden ungefähr 50 % des Keyspace zugewiesen, der als Gesamtbereich der möglichen Hashwerte definiert ist.

Darüber hinaus verteilt Azure Cosmos DB die RU/Sekunde gleichmäßig auf alle physischen Partitionen. Daher umfasst jede physische Partition 10.000 RU/Sekunde und 50 % (40 GB) der gesamten Daten. Im folgenden Diagramm ist der aktuelle Zustand dargestellt.

Angenommen, Sie möchten unsere RU/s von 20.000 RU/s auf 30.000 RU/s erhöhen.

Wenn Sie die RU/s einfach auf 30.000 RU/s erhöhen, wird nur eine der Partitionen aufgeteilt. Nach der Unterbrechung haben Sie Folgendes:

• Eine Partition, die 50% der Daten enthält (diese Partition wurde nicht geteilt).
• Zwei Partitionen, die jeweils 25% der Daten enthalten (dies sind die resultierenden untergeordneten Partitionen des übergeordneten Elements, das geteilt wurde).

Da Azure Cosmos DB RU/s gleichmäßig über alle physischen Partitionen verteilt, erhält jede physische Partition immer noch 10.000 RU/s. Sie haben jetzt jedoch eine schiefe Speicher- und Anforderungsverteilung.

Im folgenden Diagramm verfügen Partitionen 3 und 4 (die untergeordneten Partitionen von Partition 2) jeweils über 10.000 RU/s, um Anforderungen für 20 GB Daten zu verarbeiten, während Partition 1 1 1 10.000 RU/s hat, um Anforderungen für zweimal die Datenmenge (40 GB) zu verarbeiten.

Um eine gleichmäßige Speicherverteilung aufrechtzuerhalten, können Sie zuerst Ihre RU/s skalieren, um sicherzustellen, dass jede Partitionsteilung erfolgt. Anschließend können Sie Ihre RU/s zurück in den gewünschten Zustand senken.

Wenn Sie also mit zwei physischen Partitionen beginnen, um sicherzustellen, dass die Partitionen sogar nach der Aufteilung sind, müssen Sie RU/s so festlegen, dass Sie mit vier physischen Partitionen enden. Um dies zu erreichen, legen Sie zuerst fest RU/s = 4 * 10,000 RU/s per partition = 40,000 RU/s. Nach Abschluss der Unterbrechung senken Sie dann Ihre RU/s auf 30.000 RU/s.

Daher erhält 30,000 RU/s / 4 = 7500 RU/s jede physische Partition Anforderungen für 20 GB Daten. Insgesamt verwalten Sie sogar die Speicher- und Anforderungsverteilung über Partitionen hinweg.

Allgemeine Formel

Schritt 1: Erhöhen der RU/Sekunde, um sicherzustellen, dass alle Partitionen gleichmäßig aufgeteilt werden

Wenn Sie bei einer Anfangsanzahl der physischen Partitionen von P eine gewünschte Anzahl von RU/Sekunde S festlegen möchten, gilt im Allgemeinen Folgendes:

Erhöhen Sie die RU/Sekunde wie folgt: 10,000 * P * (2 ^ (ROUNDUP(LOG_2 (S/(10,000 * P)))). Dadurch wird der am nächsten gelegene RU/s dem gewünschten Wert zugewiesen, der sicherstellt, dass alle Partitionen gleichmäßig aufgeteilt werden.

Schritt 2: Reduzieren der RU/Sekunde auf die gewünschte Anzahl

Angenommen, wir verfügen über fünf physische Partitionen mit 50.000 RU/Sek. und möchten auf 150.000 RU/Sek. skalieren. Wir sollten zuerst festlegen: 10,000 * 5 * (2 ^ (ROUND(LOG_2(150,000/(10,000 * 5)))) = 200,000 RU/sund dann unter 150.000 RU/s.

Wenn wir auf bis zu 200.000 RU/Sek. hochskaliert haben, beträgt die Mindestanzahl manueller RU/Sekunde, die wir in Zukunft festlegen können, 2.000 RU/Sekunde. Der kleinste mögliche Wert für die Autoskalierung für die maximale Anzahl von RU/Sekunde, den wir festlegen können, lautet 20.000 RU/Sek. (Skalierung zwischen 2.000 und 20.000 RU/Sekunde). Da unsere Ziel-RU/s 150.000 RU/s beträgt, sind wir nicht von den Mindest-RU/s betroffen.

Optimieren der Anzahl von RU/Sekunde für die Erfassung großer Datenmengen

Wenn Sie planen, eine große Datenmenge in Azure Cosmos DB zu migrieren oder zu erfassen, empfiehlt es sich, die RU/Sek. des Containers so festzulegen, dass Azure Cosmos DB die physischen Partitionen vorab bereitstellt, die zum Speichern der Gesamtmenge der Daten erforderlich sind, die Sie im Voraus erfassen möchten. Andernfalls muss Azure Cosmos DB während der Aufnahme Partitionen teilen, wodurch der Datenaufnahme mehr Zeit hinzugefügt wird.

Wir können die Tatsache nutzen, dass Azure Cosmos DB während der Containererstellung die heuristische Formel für die Anfangsanzahl von RU/Sek. verwendet, um die Anfangsanzahl der physischen Partitionen zu berechnen.

Schritt 1: Überprüfen der Auswahl des Partitionsschlüssels

Befolgen Sie bewährte Methoden zum Auswählen eines Partitionsschlüssels, um sicherzustellen, dass Sie nach der Migration über eine gleichmäßige Verteilung des Anforderungsvolumens und des Speichers verfügen.

Schritt 2: Berechnen der Anzahl der benötigten physischen Partitionen

Number of physical partitions = Total data size in GB / Target data per physical partition in GB

Jede physische Partition kann maximal 50 GB Speicher (30 GB für die API für Cassandra) umfassen. Der Wert, den Sie für die Zieldaten pro physischer Partition in GB auswählen sollten, hängt davon ab, wie voll gepackt die physischen Partitionen sein sollen und wie viel Speicher nach der Migration wachsen soll.

Wenn Sie beispielsweise davon ausgehen, dass der Speicher weiter wächst, können Sie den Wert auf 30 GB festlegen. Wenn Sie einen guten Partitionsschlüssel gewählt haben, der den Speicher gleichmäßig verteilt, beträgt jede Partition ca. 60% voll (30 GB von 50 GB). Wenn zukünftige Daten geschrieben werden, können sie auf den vorhandenen physischen Partitionen gespeichert werden, ohne dass der Dienst sofort weitere physische Partitionen hinzufügen muss.

Wenn Sie hingegen der Meinung sind, dass der Speicher nach der Migration nicht signifikant wachsen wird, können Sie den Wert höher festlegen, z. B. 45 GB. Dies bedeutet, dass jede Partition ca. 90% voll ist (45 GB von 50 GB). Dadurch wird die Anzahl der physischen Partitionen minimiert, auf die Ihre Daten verteilt sind, was bedeutet, dass jede physische Partition einen größeren Anteil der insgesamt bereitgestellten RU/Sekunde erhalten kann.

Schritt 3: Berechnen der Anfangsanzahl von RU/Sekunde für alle Partitionen

Starting RU/s for all partitions = Number of physical partitions * Initial throughput per physical partition

Beginnen wir mit einem Beispiel mit einer beliebigen Anzahl von Ziel-RU/Sek. pro physischer Partition.

• Initial throughput per physical partition = 10,000 RU/s per physical partition bei Verwendung von Datenbanken mit automatischer Skalierung oder gemeinsam genutztem Durchsatz
• Initial throughput per physical partition = 6000 RU/s per physical partition bei Verwendung des manuellen Durchsatzes

Beispiel

Angenommen, Sie haben 1 TB (1.000 GB) Daten, die aufgenommen werden sollen, und Sie möchten den manuellen Durchsatz verwenden. Jede physische Partition in Azure Cosmos DB verfügt über eine Kapazität von 50 GB. Nehmen wir an, Sie wollen Partitionen auf 80% voll (40 GB) packen, wodurch Platz für zukünftiges Wachstum bleibt.

Dies bedeutet, dass Sie für 1 TB Daten physische Partitionen benötigen 1000 GB / 40 GB = 25 . Um sicherzustellen, dass Sie 25 physische Partitionen erhalten, indem Sie den manuellen Durchsatz verwenden, stellen Sie zuerst bereit 25 * 6000 RU/s = 150,000 RU/s. Nachdem der Container erstellt wurde, erhöhen Sie dann die RU/s auf 250.000 RU/s, bevor die Aufnahme beginnt (geschieht sofort, weil Sie bereits über 25 physische Partitionen verfügen). Dadurch kann jede Partition die maximale Anzahl von 10.000 RU/Sek. erhalten.

Wenn Sie den Durchsatz der automatischen Skalierung oder eine Freigegebene Durchsatzdatenbank verwenden, um 25 physische Partitionen zu erhalten, würden Sie zuerst bereitstellen 25 * 10,000 RU/s = 250,000 RU/s. Da Sie bereits die höchsten RU/s haben, die mit 25 physischen Partitionen unterstützt werden können, würden Sie unsere bereitgestellten RU/s vor der Aufnahme nicht weiter erhöhen.

Theoretisch kann die Aufnahme mit 250.000 RU/s und 1 TB Daten, wenn wir davon ausgehen, dass 1 KB Dokumente und 10 RUs zum Schreiben erforderlich sind, die Aufnahme theoretisch in: 1000 GB * (1,000,000 kb / 1 GB) * (1 document / 1 kb) * (10 RU / document) * (1 sec / 250,000 RU) * (1 hour / 3600 seconds) = 11.1 hours.

Bei dieser Berechnung handelt es sich um eine Schätzung, bei der davon ausgegangen wird, dass der Client, der die Erfassung durchführt, den Durchsatz vollständig auslasten und Schreibvorgänge auf alle physischen Partitionen verteilen kann. Als bewährte Methode empfiehlt es sich, Ihre Daten auf clientseitiger Seite zu mischen . Dadurch wird sichergestellt, dass der Client jede Sekunde in viele verschiedene logische (und somit physische) Partitionen schreibt.

Sobald die Migration beendet ist, können Sie die RU/s senken oder die automatische Skalierung nach Bedarf aktivieren.

Nächste Schritte

• Überwachen normalisierter RU/s für einen Azure Cosmos DB-Container oder ein Konto
• Diagnostizieren und Beheben von Ausnahmen für "Anforderungsrate zu groß" (429)
• Erstellen von Azure Cosmos DB-Containern und -Datenbanken mit automatisch skaliertem Durchsatz