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.
Azure DocumentDB-Computeressourcen werden als vCores bereitgestellt, die die logische CPU der zugrunde liegenden Hardware darstellen. Die Speichergröße für die Bereitstellung bezieht sich auf die Kapazität, die für die Shards in Ihrem Cluster verfügbar ist.
Der Speicher wird für Datenbankdateien, temporäre Dateien, Transaktionsprotokolle und die Datenbankserverprotokolle verwendet. Sie können die Compute- und Speichereinstellungen unabhängig voneinander auswählen. Die ausgewählten Compute- und Speicherwerte gelten für jeden Shard im Cluster.
Berechnen in Azure DocumentDB
Die Gesamtmenge des RAM in einem einzelnen Shard basiert auf der ausgewählten Anzahl von vCores.
| Cluster tier (Clustertarif) | V-Kerne | Ein Shard, GiB RAM |
|---|---|---|
| M10 | 1 (burstfähig) | 2 |
| M20 | 2 (burstfähig) | 4 |
| M25 | 2 (burstfähig) | 8 |
| M30 | 2 | 8 |
| M40 | 4 | 16 |
| M50 | 8 | 32 |
| M60 | 16 | 64 |
| M80 | 32 | 128 |
| M200 | 64 | 256 |
Speicher in Azure DocumentDB
Die Gesamtmenge des von Ihnen zugewiesenen Speichers definiert auch die E/A-Kapazität, die für jeden Shard im Cluster verfügbar ist.
| Speichergröße, GiB | Maximale IOPS-Anzahl |
|---|---|
| 32 | 3,500† |
| 64 | 3,500† |
| 128 | 3,500† |
| 256 | 3,500† |
| 512 | 3,500† |
| 1,024 | 5.000 |
| 2,048 | 7\.500 |
| 4,095 | 7\.500 |
| 8,192 | 16.000 |
| 16.384 | 18.000 |
| 32.767 | 20.000 |
† Max. IOPS (Eingabe/Ausgabe-Vorgänge pro Sekunde) mit kostenlosem Datenträgerbursting. Speicher bis zu 512 GiB inklusive mit aktiviertem kostenlosem Datenträgerbursting.
Maximieren von IOPS für Ihre Compute- und Speicherkonfiguration
Jede Berechnungskonfiguration weist einen IOPS-Grenzwert auf, der von der Anzahl der vCores abhängt. Stellen Sie sicher, dass Sie die Compute-Konfiguration für Ihren Cluster auswählen, um die IOPS im ausgewählten Speicher vollständig zu nutzen.
| Speichergröße | Speicher-IOPS, bis zu | Minimale Berechnungsebene | Min. vCores |
|---|---|---|---|
| Bis zu 0,5 TiB | 3,500† | M30 | 2 virtuelle Kerne |
| 1 TiB | 5.000 | M40 | 4 virtuelle Kerne |
| 2 TiB | 7\.500 | M50 | 8 virtuelle Kerne |
| 4 TiB | 7\.500 | M50 | 8 virtuelle Kerne |
| 8 TiB | 16.000 | M60 | 16 virtuelle Kerne |
| 16 TiB | 18.000 | M60 | 16 virtuelle Kerne |
| 32 TiB | 20.000 | M60 | 16 virtuelle Kerne |
† Maximale IOPS mit freiem Speicher-Bursting. Speicher bis zu 512 GiB inklusive mit aktiviertem kostenlosem Datenträgerbursting.
Wenn Sie beispielsweise 8 TiB Speicher pro Shard oder mehr benötigen, stellen Sie sicher, dass Sie 16 vCores oder mehr für die Computekonfiguration des Knotens auswählen. Mit dieser Auswahl können Sie die vom ausgewählten Speicher bereitgestellte IOPS-Nutzung maximieren.
Überlegungen zur Berechnung und Speicherung
Bei der Konfiguration Ihres Azure DocumentDB-Clusters ist es wichtig zu verstehen, wie sich Compute- und Speicheroptionen auf Die Leistung, Kosten und Skalierbarkeit für Ihre spezifische Workload auswirken.
Überlegungen zu Arbeitssatz und Arbeitsspeicher
In Azure DocumentDB bezieht sich der Arbeitssatz auf den Teil Ihrer Daten, auf den häufig zugegriffen und von Ihren Anwendungen verwendet wird. Sie enthält sowohl die Daten als auch die Indizes, die während der typischen Vorgänge der Anwendung regelmäßig gelesen oder in diese geschrieben werden. Das Konzept eines Arbeitssatzes ist wichtig für die Leistungsoptimierung, da MongoDB, wie viele Datenbanken, am besten funktioniert, wenn der Arbeitssatz in den RAM passt.
Um Ihren Arbeitssatz für die MongoDB-Datenbank zu definieren und zu verstehen, berücksichtigen Sie die folgenden Komponenten:
- Häufig verwendete Daten: Zu diesen Daten gehören Dokumente, die Ihre Anwendung regelmäßig liest oder aktualisiert.
- Indizes: Indizes, die in Abfragevorgängen verwendet werden, sind ebenfalls Teil des Arbeitssatzes, da sie in den Arbeitsspeicher geladen werden müssen, um einen schnellen Zugriff sicherzustellen.
- Anwendungsnutzungsmuster: Die Analyse der Verwendungsmuster Ihrer Anwendung kann helfen, zu identifizieren, auf welche Teile Ihrer Daten am häufigsten zugegriffen wird.
Indem Sie den Arbeitssatz im RAM beibehalten, können Sie langsamere Datenträger-E/A-Vorgänge minimieren und so die Leistung Ihrer MongoDB-Datenbank verbessern. Wenn Ihr Arbeitssatz den verfügbaren RAM überschreitet, sollten Sie das Datenmodell optimieren, ihrem Cluster mehr RAM hinzufügen oder Daten über mehrere Knoten verteilen.
Optimale Konfiguration für eine Workload auswählen
Das Ermitteln der richtigen Compute- und Speicherkonfiguration für Ihre Azure DocumentDB-Workload umfasst die Auswertung mehrerer Faktoren im Zusammenhang mit den Anforderungen und Nutzungsmustern Ihrer Anwendung. Zu den wichtigsten Schritten und Überlegungen zur Ermittlung der optimalen Konfiguration gehören:
Verstehen Sie Ihre Arbeitslast
- Datenvolumen: Schätzen Sie die Gesamtgröße Ihrer Daten, einschließlich Indizes.
- Lese-/Schreibverhältnis: Bestimmen Sie das Verhältnis von Lesevorgängen mit Schreibvorgängen.
- Abfragemuster: Analysieren Sie die Typen von Abfragen, die Ihre Anwendung ausführt. Beispielsweise: einfache Lesevorgänge, komplexe Aggregationen.
- Parallelität: Bewerten Sie die Anzahl der gleichzeitigen Vorgänge, die Ihre Datenbank verarbeiten muss.
Überwachen der aktuellen Leistung
- Ressourcenauslastung: Verwenden Sie Überwachungstools zum Nachverfolgen von CPU, Arbeitsspeicher, Datenträger-E/A und Netzwerknutzung, bevor Sie Ihre Workload zu Azure migrieren. Nachdem Sie Ihre MongoDB-Workload in einem Azure DocumentDB-Cluster bereitgestellt haben, können Sie die Überwachung mithilfe von Azure-Überwachungsmetriken fortsetzen.
- Leistungsmetriken: Überwachen Sie wichtige Leistungsmetriken wie Latenz, Durchsatz und Cachetrefferverhältnisse.
- Engpässe: Identifizieren Sie vorhandene Leistungsengpässe, z. B. hohe CPU-Auslastung, Arbeitsspeicherdruck oder langsame Datenträger-E/A.
Schätzen der Ressourcenanforderungen
- Arbeitsspeicher: Stellen Sie sicher, dass Ihr Arbeitssatz (häufig verwendete Daten und Indizes) in den RAM passt. Wenn ihre Arbeitssatzgröße den verfügbaren Arbeitsspeicher überschreitet, sollten Sie mehr RAM hinzufügen oder Ihr Datenmodell optimieren.
- CPU: Wählen Sie eine CPU-Konfiguration aus, die ihre Anforderungen an die Abfragelast und Parallelität verarbeiten kann. CPU-intensive Workloads könnten mehr Kerne erfordern. Verwenden Sie die Metrik "CPU Percent" mit der Aggregation "Max" auf Ihrem Azure DocumentDB-Cluster, um historische Berechnungsnutzungsmuster anzuzeigen.
- Speicher-IOPS: Wählen Sie Speicher mit ausreichenden IOPS aus, um Ihre Lese- und Schreibvorgänge zu verarbeiten. Verwenden Sie die Metrik "IOPS" mit der Aggregation "Max" in Ihrem Cluster, um die historische Nutzung der Speicher-IOPS anzuzeigen.
- Netzwerk: Stellen Sie eine angemessene Netzwerkbandbreite sicher, um die Datenübertragung zwischen Ihrer Anwendung und der Datenbank zu verarbeiten, insbesondere für verteilte Setups. Stellen Sie sicher, dass Sie den Host für Ihre MongoDB-Anwendung konfiguriert haben, um beschleunigte Netzwerktechnologien wie SR-IOV zu unterstützen.
Angemessen skalieren
-
Vertikale Skalierung: Skaliert compute / RAM nach oben und unten und skalieren Speicher nach oben.
- Berechnen: Erhöhen Sie den vCore/RAM auf einem Cluster, wenn Ihre Workload eine temporäre Erhöhung erfordert oder häufig über 70% der CPU-Auslastung für längere Zeiträume überschreitet.
- Stellen Sie sicher, dass Sie über die entsprechende Datenaufbewahrung in Ihrer Azure DocumentDB-Datenbank verfügen. Die Aufbewahrung ermöglicht es Ihnen, unnötige Speichernutzung zu vermeiden. Überwachen Sie die Speichernutzung, indem Sie Warnungen für die Metriken "Speicherprozent" und/oder "Verwendeter Speicher" mit der Aggregation "Max" festlegen. Erwägen Sie, den Speicher zu erhöhen, da ihre Workloadgröße 70% Nutzung überschreitet.
- Horizontale Skalierung: Erwägen Sie die Verwendung mehrerer Shards für Ihren Cluster, um Ihre Daten über mehrere Azure DocumentDB-Knoten zu verteilen, um Leistungsvorteile zu erzielen und die Kapazitätsverwaltung zu verbessern, wenn Ihre Workload wächst. Diese Skalierung ist besonders nützlich für große Datasets (über 2-4 TiB) und Anwendungen mit hohem Durchsatz.
-
Vertikale Skalierung: Skaliert compute / RAM nach oben und unten und skalieren Speicher nach oben.
Testen und Durchlaufen
- Benchmarking: Führen Sie Messungen für die am häufigsten verwendeten Abfragen mit unterschiedlichen Konfigurationen durch, um die Auswirkung auf die Leistung zu bestimmen. Verwenden Sie CPU/RAM- und IOPS-Metriken und Benchmarking auf Anwendungsebene.
- Auslastungstests: Führen Sie Auslastungstests durch, um Produktionsworkloads zu simulieren und die Leistung Ihrer ausgewählten Konfiguration zu überprüfen.
- Kontinuierliche Überwachung: Überwachen Sie Ihre Azure DocumentDB-Bereitstellung kontinuierlich, und passen Sie Ressourcen nach Bedarf basierend auf änderungen an Arbeitslasten und Nutzungsmustern an.
Indem Sie diese Faktoren systematisch auswerten und Ihre Konfiguration kontinuierlich überwachen und anpassen, können Sie sicherstellen, dass Ihre MongoDB-Bereitstellung für Ihre spezifische Arbeitsauslastung gut optimiert ist.
Überlegungen zur Speicherung
Die Entscheidung über die geeignete Speichergröße für Ihre Workload umfasst mehrere Überlegungen, um eine optimale Leistung und Skalierbarkeit zu gewährleisten. Im Folgenden finden Sie Überlegungen zur Speichergröße in Azure DocumentDB:
Geschätzte Datengröße:
- Berechnen Sie die erwartete Größe Ihrer Azure DocumentDB-Daten. Berücksichtigen Sie dabei Folgendes:
- Aktuelle Datengröße: Wenn Sie aus einer vorhandenen Datenbank migrieren.
- Wachstumsrate: Schätzen Sie, wie viele Daten im Laufe der Zeit hinzugefügt werden.
- Dokumentgröße und -struktur: Verstehen Sie Ihre Datenschema- und Dokumentgrößen, da sie sich auf die Speichereffizienz auswirken.
- Berechnen Sie die erwartete Größe Ihrer Azure DocumentDB-Daten. Berücksichtigen Sie dabei Folgendes:
Faktor in Indizes:
- Azure DocumentDB verwendet Indizes für eine effiziente Abfrage. Indizes verbrauchen zusätzlichen Speicherplatz.
- Schätzen Sie die Größe der Indizes basierend auf:
- Anzahl der Indizes.
- Größe der indizierten Felder.
Überlegungen zur Leistung
- Die Datenträgerleistung wirkt sich auf Datenbankvorgänge aus, insbesondere für Workloads, die ihren Arbeitssatz nicht in den RAM anpassen können. Berücksichtigen Sie dabei Folgendes:
- E/A-Durchsatz: IOPS, also Eingabe-/Ausgabevorgänge pro Sekunde, ist die Anzahl der Anforderungen, die in einer Sekunde an Speicherdatenträger gesendet werden. Die größere Speichergröße verfügt über mehr IOPS. Stellen Sie einen angemessenen Durchsatz für Lese-/Schreibvorgänge sicher. Verwenden Sie die Metrik "IOPS" mit der Aggregation "Max", um verwendete IOPS auf Ihrem Cluster zu überwachen.
- Latenz: Latenz ist die Zeit, die eine Anwendung benötigt, um eine einzelne Anforderung zu empfangen, an Speicherdatenträger zu senden und die Antwort an den Client zu senden. Latenz ist ein kritisches Maß für die Leistung einer Anwendung zusätzlich zu IOPS und Durchsatz. Der Typ des verwendeten Speichers und die Speicherkonfiguration definieren weitgehend die Latenz. In einem verwalteten Dienst wie Azure DocumentDB wird der schnelle Speicher wie Premium-SSD-Datenträger mit Einstellungen verwendet, die für die Reduzierung der Latenz optimiert sind.
- Die Datenträgerleistung wirkt sich auf Datenbankvorgänge aus, insbesondere für Workloads, die ihren Arbeitssatz nicht in den RAM anpassen können. Berücksichtigen Sie dabei Folgendes:
Zukünftiges Wachstum und Skalierbarkeit:
- Planen Sie zukünftige Datenwachstums- und Skalierbarkeitsanforderungen.
- Weisen Sie mehr Speicherplatz zu, der über die aktuellen Anforderungen hinausgeht, um das Wachstum ohne häufige Speichererweiterungen zu berücksichtigen.
Beispielberechnung:
- Angenommen, Ihre anfängliche Datengröße beträgt 500 GiB.
- Mit Indizes kann es auf 700 GiB wachsen.
- Wenn Sie erwarten, dass die Daten in zwei Jahren verdoppelt werden, planen Sie 1,4 TiB (700 GiB * 2).
- Fügen Sie einen Puffer für Mehraufwand, Wachstum und betriebliche Anforderungen hinzu.
- Vielleicht möchten Sie heute mit 1-TiB-Speicher beginnen und es auf 2 TiB skalieren, sobald seine Größe über 800 GiB wächst.
Die Entscheidung über die Speichergröße umfasst eine Kombination aus der Schätzung aktueller und zukünftiger Datenanforderungen, unter Berücksichtigung der Indizierung und Komprimierung sowie der Sicherstellung einer angemessenen Leistung und Skalierbarkeit. Regelmäßige Überwachung und Anpassung auf der Grundlage der tatsächlichen Nutzungs- und Wachstumstrends sind ebenfalls entscheidend, um eine optimale MongoDB-Leistung aufrechtzuerhalten.
Was ist burstfähiger Compute?
Burstable Tier bietet eine intelligente Lösung, die auf kleine Datenbankworkloads zugeschnitten ist. Durch die Bereitstellung minimaler CPU-Leistung während Leerlaufzeiten optimieren diese Cluster die Ressourcenauslastung. Die echte Brillanz liegt jedoch in der Fähigkeit, als Reaktion auf erhöhte Datenverkehrs- oder Workloadanforderungen nahtlos auf die volle CPU-Leistung zu skalieren. Diese Flexibilität ermöglicht höchste Leistung zum genau richtigen Zeitpunkt und sorgt gleichzeitig für erhebliche Kosteneinsparungen.
Durch die Reduzierung des anfänglichen Preispunkts des Diensts zielt azure DocumentDBs Burstable Cluster Tier darauf ab, das Onboarding und die Erkundung von Azure DocumentDB zu reduzierten Preisen zu erleichtern. Diese Demokratisierung des Zugriffs ermöglicht es Unternehmen jeder Größe, die Leistungsfähigkeit von Azure DocumentDB zu nutzen, ohne immense Kosten zu verursachen. Ganz gleich, ob Sie ein Startup, ein kleines Unternehmen oder ein Unternehmen sind, diese Stufe eröffnet neue Möglichkeiten für eine kostengünstige Skalierbarkeit.
Die Bereitstellung einer skalierbaren Ebene ist so einfach wie die Bereitstellung regulärer Ebenen; Sie müssen nur "M10", "M20" oder "M25" als Clusterebene auswählen. Hier ist ein Schnellstarthandbuch, das schrittweise Anleitungen zum Einrichten eines Azure DocumentDB-Clusters bietet.