Skalierbarkeit in Azure DocumentDB

Azure DocumentDB bietet die Möglichkeit, Cluster vertikal und horizontal zu skalieren. Während die Computeclusterebene und der Speicherdatenträger funktionell voneinander abhängen, werden die Skalierbarkeit und die Kosten für Compute und Speicher entkoppelt.

Vertikale Skalierung

Die vertikale Skalierung bietet die folgenden Vorteile:

• Anwendungsteams verfügen möglicherweise nicht immer über einen klaren Pfad, um ihre Daten logisch zu shardieren. Darüber hinaus wird logisches Sharding pro Sammlung definiert. In einem Dataset mit mehreren nicht gehardeten Sammlungen kann die Datenmodellierung zur Partitionierung der Daten schnell mühsam werden. Durch die einfache Skalierung des Clusters kann die Notwendigkeit einer logischen Sharding umgangen werden, während die wachsenden Speicher- und Computeanforderungen der Anwendung erfüllt werden.
• Für die vertikale Skalierung ist kein Datenausgleich erforderlich. Die Anzahl der physischen Shards bleibt gleich, und nur die Kapazität des Clusters wird ohne Auswirkungen auf die Anwendung erhöht.
• Die Skalierung nach oben und unten erfolgt völlig ohne Ausfallzeit und ohne Unterbrechung des Dienstes. Es sind keine Anwendungsänderungen erforderlich, und der Betrieb kann ungestört fortgesetzt werden.
• Computeressourcen können auch bei bekannten Zeitfenstern mit geringer Aktivität herunterskaliert werden. Die Skalierung nach unten vermeidet erneut die Notwendigkeit, Daten über weniger physische Shards hinweg neu auszubalancieren und ist ein Null-Down-Vorgang ohne Unterbrechung des Diensts. Auch hier sind keine Anwendungsänderungen erforderlich, nachdem der Cluster herunterskaliert wurde.
• Am wichtigsten ist, dass Compute und Speicher unabhängig voneinander skaliert werden können. Wenn mehr Kerne und Arbeitsspeicher benötigt werden, kann die Datenträgergröße wie gewünscht beibehalten werden, und die Clusterebene kann skaliert werden. Wenn mehr Speicher und IOPS benötigt werden, kann die Clusterebene so beibehalten werden, wie sie ist, und die Speichergröße kann unabhängig skaliert werden. Bei Bedarf können Rechen- und Speicheranforderungen unabhängig voneinander skaliert werden, um die Anforderungen der einzelnen Komponenten zu optimieren, ohne dass sich die Flexibilitätsanforderungen einer Komponente auf die andere auswirken.

Horizontale Skalierung

Schließlich wächst die Anwendung auf einen Punkt, an dem die vertikale Skalierung nicht ausreicht. Arbeitsauslastungsanforderungen können über die Kapazität der größten Clusterebene hinaus wachsen, und schließlich werden weitere Shards benötigt. Die horizontale Skalierung in Azure DocumentDB bietet die folgenden Vorteile:

• Logisch geshardete Datensätze erfordern keine Benutzereingriffe, um Daten über die zugrunde liegenden physischen Shards hinweg ausbalancieren. Der Dienst ordnet logische Shards automatisch physischen Shards zu. Wenn Knoten hinzugefügt oder entfernt werden, werden die Daten in der Datenbank im Hintergrund automatisch ausgeglichen.
• Anforderungen werden automatisch an den relevanten physischen Shard weitergeleitet, der den Hashbereich für die abgefragten Daten besitzt.
• Geo-verteilte Cluster verfügen über eine homogene Konfiguration mit mehreren Knoten. Daher sind logische und physische Shardzuordnungen in den primären und Replikatregionen eines Clusters konsistent.

Rechen- und Speicherskalierung

Compute- und Arbeitsspeicherressourcen beeinflussen Lesevorgänge in Azure DocumentDB mehr als Datenträger-IOPS.

• Lesevorgänge konsultieren zuerst den Cache auf der Computeebene und greifen auf den Datenträger zurück, wenn Daten nicht aus dem Cache abgerufen werden konnten. Bei Workloads mit einer höheren Leserate pro Sekunde führt die Skalierung der Clusterebene zum Abrufen weiterer CPU- und Arbeitsspeicherressourcen zu einem höheren Durchsatz.
• Neben dem Lesedurchsatz profitieren Workloads mit einem hohen Datenvolumen pro Lesevorgang auch von der Skalierung der Computeressourcen des Clusters. Clusterebenen mit mehr Arbeitsspeicher erleichtern beispielsweise größere Nutzlastgrößen pro Dokument und eine größere Anzahl kleinerer Dokumente pro Antwort.

Datenträger-IOPS beeinflusst Schreibvorgänge in Azure DocumentDB mehr als die CPU- und Arbeitsspeicherkapazitäten der Computeressourcen.

• Schreibvorgänge speichern Daten zusätzlich zum Speichern im Arbeitsspeicher zum Optimieren von Lesevorgängen immer auf dem Datenträger. Größere Datenträger mit mehr IOPS bieten einen höheren Schreibdurchsatz, insbesondere beim Skalieren.
• Der Dienst unterstützt bis zu 32 TB Festplatten pro Shard, mit mehr IOPS pro Shard, um schreibintensive Arbeitslasten besser zu unterstützen, insbesondere beim Ausführen in großem Maßstab.

Speicherintensive Arbeitslasten und Datenträger mit großer Kapazität

Keine Mindestspeicheranforderungen pro Clusterebene

Wie bereits erwähnt, werden Speicher- und Computeressourcen für die Abrechnung und Bereitstellung entkoppelt. Während sie als zusammenhängende Einheit funktionieren, können sie unabhängig voneinander skaliert werden. Die M30-Clusterebene kann über 32 TB bereitgestellte Datenträger verfügen. Ebenso kann die M200-Clusterebene 32-GB-Datenträger bereitstellen, um sowohl Speicher- als auch Computekosten zu optimieren.

Niedrigerer TCO mit großen Datenträgern (32 TB und höher)

In der Regel beschränken NoSQL-Datenbanken den Speicher pro physischer Shard auf 4 TB. Azure DocumentDB bietet bis zu 8x kapazität mit 32 TB Datenträgern. Bei speicherintensiven Workloads erfordert eine 4 TB Shardkapazität pro physischer Shard eine massive Flotte von Computeressourcen, um die Speicheranforderungen der Workload aufrechtzuerhalten. Rechenleistung ist teurer als Speicher, und die Überprovisionierung von Rechenkapazität aufgrund von Kapazitätsbeschränkungen in einem Dienst kann schnell die Kosten erhöhen.

Betrachten wir eine speicherintensive Workload mit 200 TB Daten.

Die Anforderungen an Compute-Kapazitäten nehmen mit größeren Festplatten stark ab. Während mehr als die Mindestanzahl physischer Shards erforderlich sein kann, um die Durchsatzanforderungen der Workload aufrechtzuerhalten, sind selbst eine Verdopplung oder Verdreifachung der Anzahl der Shards kostengünstiger als ein 50-Shard-Cluster mit kleineren Datenträgern.

Verzicht auf Speichertiering bei großen Datenträgern

Eine sofortige Reaktion auf die Berechnung der Kosten in speicherintensiven Szenarien besteht darin, die Daten zu "stufen". Daten in der Transaktionsdatenbank sind auf die am häufigsten zugegriffenen "hot"-Daten beschränkt, während das größere Volumen von "kalten" Daten in einen Kaltspeicher getrennt wird. Dies führt zu einer betrieblichen Komplexität. Die Leistung ist auch unvorhersehbar und abhängig von der Datenebene, auf die zugegriffen wird. Darüber hinaus ist die Verfügbarkeit des gesamten Systems von der Resilienz sowohl der heißen als auch der kalten Datenspeicher abhängig. Bei großen Datenträgern im Dienst ist kein mehrstufiger Speicher erforderlich, da die Kosten für speicherintensive Workloads minimiert werden.

Nächste Schritte

• Erfahren Sie, wie Sie den Azure DocumentDB-Cluster skalieren.
• Sehen Sie sich bewährte Methoden für die Indizierung an