Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Mit dem vCore-basierten Dienst für Azure Cosmos DB for MongoDB können Cluster vertikal und horizontal skaliert werden. 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 eindeutigen Ansatz, um ihre Daten logisch horizontal zu partitionieren. Darüber hinaus wird logisches Sharding pro Sammlung definiert. In einem Dataset mit mehreren nicht partitionierten Sammlungen kann die Datenmodellierung zum Partitionieren der Daten schnell mühsam werden. Mit dem Skalieren des Clusters kann die Notwendigkeit eines logischen Shardings 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 ohne Downtime und ohne Unterbrechungen des Diensts. Es sind keine Anwendungsänderungen erforderlich, und der Betrieb im stabilen Zustand kann unverändert fortgeführt werden.
- Computeressourcen können auch bei bekannten Zeitfenstern mit geringer Aktivität herunterskaliert werden. Durch Herunterskalieren wird benötigter Datenausgleich auf weniger physischen Shards umgangen. Außerdem handelt es sich um einen Vorgang ohne Downtime und 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 belassen werden, 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. Workloadanforderungen können über die Kapazität der größten Clusterebene hinaus wachsen, und schließlich werden weitere Shards benötigt. Die horizontale Skalierung im vCore-basierten Angebot für Azure Cosmos DB for MongoDB bietet die folgenden Vorteile:
- Logisch geshardete Datensätze erfordern keine Benutzereingriffe, um Daten zwischen den zugrunde liegenden physischen Shards auszugleichen. 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.
- Geografisch verteilte Cluster verfügen über eine homogene Konfiguration mit mehreren Knoten. Daher sind Zuordnungen von logischen zu physischen Shards in den primären und Replikatbereichen eines Clusters konsistent.
Rechen- und Speicherskalierung
Compute- und Speicherressourcen beeinflussen Lesevorgänge im vCore-basierten Dienst für Azure Cosmos DB für MongoDB 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 Lesevorgangsrate pro Sekunde führt die Skalierung der Clusterebene für das 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 ermöglichen beispielsweise höhere Nutzdatengrößen pro Dokument und eine größere Anzahl kleinerer Dokumente pro Antwort.
Datenträger-IOPS beeinflusst Schreibvorgänge im vCore-basierten Dienst für Azure Cosmos DB für MongoDB mehr als die CPU- und Speicherkapazitä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 wenn sie im großen Stil ausgeführt werden.
- Der Dienst unterstützt Datenträger bis zu 32 TB pro Shard und bietet mehr IOPS pro Shard, um schreibintensive Workloads besser zu unterstützen, insbesondere wenn sie im großen Stil ausgeführt werden.
Speicherintensive Workloads und große Datenträger
Keine Mindestspeicheranforderungen pro Clusterebene
Wie bereits erwähnt, werden Speicher- und Computeressourcen für die Abrechnung und Bereitstellung entkoppelt. Obwohl sie eine zusammenhängende Einheit darstellen, 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 über 32 GB bereitgestellte Datenträger verfügen, 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 mit einem vCore-basierten Modell den Speicher pro physischer Shard auf 4 TB. Der vCore-basierte Dienst für Azure Cosmos DB for MongoDB bietet mit Datenträgern mit 32 TB bis zu 8-mal so viel Kapazität. Bei speicherintensiven Workloads erfordert eine Shardkapazität von 4 TB pro physischer Shard eine große Flotte an Computeressourcen, um die Speicheranforderungen der Workload aufrechtzuerhalten. Die Berechnung ist teurer als Speicher, und eine zu hohe Bereitstellung von Compute aufgrund von Kapazitätsgrenzwerten in einem Dienst kann die Kosten schnell erhöhen.
Stellen Sie sich eine speicherintensive Workload mit 200 TB an Daten vor.
| Speichergröße pro Shard | Mindestanzahl von Shards zum Aufrechterhalten von 200 TB |
|---|---|
| 4 TiB | 50 |
| 32 TiB | 7 |
Die Rechenanforderungen reduzieren sich deutlich mit größeren Datenträgern. Während mehr als die Mindestanzahl physischer Shards erforderlich sein kann, um die Durchsatzanforderungen der Workload aufrechtzuerhalten, sind sogar doppelte oder dreimal so viele Shards kosteneffizienter als ein Cluster mit 50 Shards und kleineren Datenträgern.
Überspringen der Speicherstaffelung mit großen Datenträgern
Eine sofortige Reaktion auf die Kostenberechnung in speicherintensiven Szenarios besteht darin, die Daten zu „staffeln“. Daten in der transaktionalen Datenbank sind auf die am häufigsten aufgerufenen „heißen“ Daten beschränkt, während das größere Volumen von „kalten“ Daten in einen kälteren Speicher ausgelagert wird. Dies führt zu einer betrieblichen Komplexität. Die Leistung ist auch unvorhersehbar und abhängig von der Datenschicht, 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 vCore-Dienst ist kein mehrstufiger Speicher erforderlich, da die Kosten für speicherintensive Workloads minimiert werden.