Bevor Sie also viel Zeit und Energie in eine bestimmte Cloud investieren, ist es wichtig, die allgemeinen Leistungsmerkmale von MongoDB in dieser Cloud zu verstehen. Wir haben nach diesen Informationen gesucht und sie nicht gefunden – deshalb haben wir uns entschieden, sie im Rahmen unserer Performance-Reihe für Sie zusammenzustellen.
Das Benchmark-Rig
Wir haben uns für diesen Test entschieden, AWS, Azure und DigitalOcean zu vergleichen. Es wurden zwei unterschiedliche Konfigurationen gewählt. Die folgende Tabelle fasst die Maschinenkonfigurationen zusammen:
Anbieter | Region | ScaleGrid Medium* (Cores/RAM/Disk/Prov IOPS) | ScaleGrid Large* (Kerne/RAM/Festplatte/prov. IOPS) |
AWS | USA Ost | 1/3,75 GB/60 GB/300 | 2/7,5 GB/120 GB/500 |
Azurblau | USA, Osten | 2/3,5 GB/60 GB/bis zu 2000 | 4/7GB/120GB/bis zu 4000 |
DigitalOcean | New York 3 | 2/4 GB/25 GB/SSD** | 4/8 GB/35 GB/SSD** |
* Einzelheiten zu Maschinenkonfigurationen finden Sie hier unter „MongoDB-Hosting“.
** DigitalOcean hat direkt angeschlossene SSDs.
Die Benchmark-Leistungstests wurden mit YCSB-Arbeitslast A (hohe Arbeitslast aktualisieren) ausgeführt. Wir haben letzten Monat in einem sehr ausführlichen Beitrag über YCSB, seine Einrichtung und seine Arbeitsbelastung gesprochen.
- Alle Benchmark-Tests wurden in einer eigenständigen Konfiguration durchgeführt
- Für beide Konfigurationen 5 Millionen Datensätze wurden eingefügt mit unterschiedlicher Serverlast (basierend auf der Anzahl der Client-Threads).
- Für die mittlere Konfiguration wurde Arbeitslast A mit Standardwerten (50 % Aktualisierung, 50 % Lesen) mit einer Vorgangsanzahl von 5 Millionen ausgeführt bei unterschiedlicher Serverauslastung.
- Für die große Konfiguration wurde Arbeitslast A mit Standardwerten (50 % Aktualisierung, 50 % Lesezugriff) mit einer Vorgangsanzahl von 10 Millionen ausgeführt bei unterschiedlicher Serverauslastung.
Ergebnisse
Wir werden die Ergebnisse basierend auf der Einfügeleistung und den Durchsatz-/Latenzmerkmalen unter hoher Arbeitslast für Aktualisierungen erörtern.
Leistung einfügen
Mittlere Instanzen
Die Durchsatz-/Latenzeigenschaften für das Einfügen von 5 Millionen Datensätzen in der mittleren Konfiguration:
Große Instanzen
Die Durchsatz-/Latenz-Eigenschaften für das Einfügen von 5 Mio. Datensätzen in der großen Konfiguration:
Leistung aktualisieren
Mittlere Instanzen
Die Durchsatz-/Latenzeigenschaften für 5 Millionen Schreib-/Aktualisierungsvorgänge auf der Medienkonfiguration:
Der Test wurde nur für DigitalOcean mit 32 Threads durchgeführt. AWS und Azure waren mit 16 Threads flach. Allerdings erweckt DigitalOcean den Eindruck einer linearen Skalierung bis 32 Threads.
Große Instanzen
Die Durchsatz-/Latenzeigenschaften für 10 Millionen Schreib-/Aktualisierungsvorgänge in der großen Konfiguration:
Gesamtanalyse
- Wie erwartet, hat MongoDB auf DigitalOcean durchgehend einen hohen Durchsatz und niedrige Latenz und schlägt die anderen während der Einfügephase um Längen, indem es das Maximum aus seinen lokalen SSD-Laufwerken herausholt. Interessanterweise, obwohl es während der Lese-/Aktualisierungsphase sehr gut läuft, geben andere Anbieter ihm ein gewisses Maß an Konkurrenz, insbesondere wenn die Serverlast zunimmt. Offensichtlich verwenden AWS/Azure Netzwerkspeicher mit viel höherem Durchsatz.
- Um eine bessere Leistung der AWS-Festplatte zu erzielen, kann der Benutzer größere Festplatten verwenden oder mehr bereitgestellte IOPS zuweisen.
- Auf mittleren Instanzen scheint MongoDB auf Azure sowohl während der Einfügungs- als auch während der Aktualisierungs-/Lesephasen durchgängig viel besser abzuschneiden als AWS. Das war überraschend. Die Hardware ist ziemlich gleichmäßig aufeinander abgestimmt. Bei großen Instanzen ist die AWS-Leistung deutlich besser als bei Azure.
- Sowohl AWS als auch Azure verschlechtern sich ziemlich gut in Latenzen, wenn die Last zunimmt. Azure scheint eine ziemlich gute Latenzabbaukurve zu haben.
- Ein weiterer interessanter Aspekt der durchgehenden Leistung von MongoDB auf AWS ist, wie „flach“ es ist:Scheint sich sogar auf einer Protokollskala elegant zu verschlechtern.
- Basierend auf den Latenzzahlen sieht es so aus, als wäre der optimale Punkt aus Lastsicht für mittlere und große Instanzen 8 bzw. 16 Threads.