MongoDB storage tiering steigert den throughput im Test auf bis zu das 5,2-Fache
MongoDB storage tiering erhöhte in einem am 2. November 2026 von Percona veröffentlichten proof of concept den throughput um das 1,6- bis 5,2-Fache. Die Ergebnisse deuten darauf hin, dass Workloads, die sich hauptsächlich auf aktuelle records konzentrieren, eine Alternative zum sofortigen Kauf größerer Maschinen oder zur Einführung von sharding haben könnten. Allerdings wurde die Software noch nicht in Produktion eingesetzt und führte in den Tests zu deutlich schlechteren Update-Tail-Latenzen.
Das zugrunde liegende Problem beginnt, wenn ein MongoDB replica set – eine Gruppe von Datenbankservern, die Kopien derselben Daten vorhalten – über den verfügbaren Arbeitsspeicher hinauswächst. Sein working set, also die Daten, die häufig genug verwendet werden, um von einem schnellen Zugriff zu profitieren, passt dann nicht mehr vollständig in den WiredTiger cache, den Speicherbereich, den MongoDB zur effizienten Bereitstellung von Daten nutzt. Nicht im Cache enthaltene Dokumente müssen anschließend aus dem storage gelesen werden. Im getesteten Cluster spiegelte ein Read-p95 von 70 Millisekunden – das heißt, 95 Prozent der Lesevorgänge wurden innerhalb dieser Zeit abgeschlossen – eine Festplatte wider, die an ihrem Limit für input/output operations per second (IOPS) arbeitete, und nicht einen ineffizienten Index.
Sharding kann eine große Datenbank auf mehrere Maschinen verteilen, führt jedoch einen shard key ein, der bestimmt, wo records gespeichert werden, sowie mongos-Routingprozesse, Konfigurationsserver und Balancing. Queries benötigen im Allgemeinen den shard key, um effizient zu bleiben, während eine Änderung dieses key nicht unkompliziert ist. Der Thermocline genannte proof of concept platziert stattdessen ein kleineres replica set mit aktuellen records vor dem ursprünglichen Cluster. Das bestehende replica set bleibt unverändert als Archiv erhalten, und die Anwendung verbindet sich über das normale Kommunikationsprotokoll von MongoDB mit einem proxy, anstatt direkt auf den alten Cluster zuzugreifen.
Vier Komponenten verwalten diese Anordnung. Der proxy sendet eine Query nur dann an den fast tier, wenn dieser tier feststellen kann, dass er die vollständige Antwort enthält; andernfalls wird die Query an das Archiv weitergeleitet. Neue Schreibvorgänge gelangen zunächst in den fast tier. Ein feeder liest dessen change stream, MongoDBs fortlaufendes Protokoll der Datenbankänderungen, und reproduziert jeden Schreibvorgang im Archiv, sodass dort alle Dokumente erhalten bleiben. Ein evictor löscht records aus dem fast tier, sobald sie das für ihre Collection konfigurierte Alter überschreiten, jedoch erst nach der Bestätigung, dass sie im Archiv vorhanden sind. Ein warmer kopiert records, die jünger als dieses Alter sind, aus dem Archiv in den fast tier. Der fast tier kann daher leer starten und sich sowohl durch eingehenden Traffic als auch durch Warming im Hintergrund füllen, ohne dass ein manuelles Laden erforderlich ist.
Percona berichtete, dass der Test in der Hetzner Cloud durchgeführt wurde. Das bestehende Deployment war ein replica set mit drei Mitgliedern, das 40 Millionen simulierte Bestellungen und 47 GB Daten enthielt. Jedes Mitglied war auf 2,5 GB Arbeitsspeicher begrenzt, einschließlich eines 1 GB großen WiredTiger cache, und seine Datenfestplatte war auf 3.000 Lesevorgänge pro Sekunde beschränkt. Der Datensatz war damit etwa 47-mal größer als der Cache. Der zweite tier war ein weiteres replica set mit drei Mitgliedern und startete leer.
Der Workload verwendete Yahoo! Cloud Serving Benchmark (YCSB) 0.17, ein Werkzeug zur Erzeugung wiederholbaren Datenbank-Traffics, mit 64 Threads. Die Durchläufe dauerten zehn Minuten, wobei für jede Seite des Vergleichs zwei Durchläufe durchgeführt wurden. Jedes simulierte Dokument hatte ein Datum, das über das vorhergehende Jahr verteilt war. Der Onlineshop-Mix bestand aus 85 Prozent Lesevorgängen, 10 Prozent Updates und 5 Prozent Inserts, wobei bei den Lesevorgängen die neuesten Dokumente bevorzugt wurden. Ein Read-heavy-Mix nutzte 95 Prozent Lesevorgänge und 5 Prozent Updates mit demselben Aktualitätsmuster. Eine konzentrierte Variante verwendete diesen 95-zu-5-Mix, richtete jedoch 99 Prozent der gesamten Aktivität auf die neuesten 9 Prozent der Dokumente. Jeder Workload lief sowohl allein auf dem ursprünglichen Cluster als auch auf demselben Cluster hinter Thermocline, jeweils mit demselben MongoDB-Release, denselben Ressourcenlimits und demselben Client.
Über diese Durchläufe hinweg führte der begrenzte Cluster hinter dem tiering proxy pro Sekunde 1,6- bis 5,2-mal mehr Operationen aus, ohne dass Operationen abgelehnt wurden. Die größte Verbesserung erzielte der konzentrierte Workload, der von 4.447 auf 23.340 Operationen pro Sekunde stieg. Sein Read-p95 sank von 86 auf 6 Millisekunden, während p99 – der Zeitpunkt, innerhalb dessen 99 Prozent der Lesevorgänge abgeschlossen waren – von 92 auf 8 Millisekunden fiel.
Ein Vergleich mit fester Last verwendete für den Shop-Workload angeforderte 6.165 Operationen pro Sekunde, entsprechend dem Maximum des ursprünglichen Clusters. Allein lieferte dieser Cluster 6.086 Operationen pro Sekunde bei einem Read-p95 von 70,5 Millisekunden. Hinter Thermocline lieferten zwei Durchläufe 6.156 beziehungsweise 6.159 Operationen pro Sekunde, mit p95-Ergebnissen von 2,8 beziehungsweise 2,1 Millisekunden. Der Read-p99 variierte bei den tiered Durchläufen zwischen 7 und 27 Millisekunden, gegenüber 81 Millisekunden für das Archiv allein. Die Lesevorgänge auf der Festplatte des Archivs gingen von 2.704 auf 1.838 pro Sekunde zurück.
Der Empty-start-Test untersuchte den realistischeren Weg einer Einführung. Während der Shop-Workload 30 Minuten lang ohne vorgegebenes throughput-Limit lief, erreichte der Verbund durchschnittlich 8.221 Operationen pro Sekunde. Das waren 42 Prozent mehr als die 5.803 Operationen pro Sekunde des ursprünglichen Clusters mit kalten Caches. Das tiered Setup übertraf das Ergebnis des alten Clusters nach 100 Sekunden, erreichte während der ersten fünf Minuten durchschnittlich 6.417 Operationen pro Sekunde und während der letzten fünf Minuten 9.146. In diesem Zeitraum kopierte es 271.271 Dokumente aus dem Archiv in den fast tier.
Die Einschränkungen sind erheblich. Jeder Schreibvorgang muss weiterhin das Archiv erreichen, und zum Spiegeln eines Updates muss das Archiv zunächst das vorhandene Dokument von der Festplatte lesen. Die Updates im Shop-Workload blieben durch den alten Cluster begrenzt, während sich der Update-p99 auf 455 bis 472 Millisekunden verschlechterte, verglichen mit 104 bis 189 Millisekunden ohne Thermocline. Dieses Tail-Latency-Problem ist im proof of concept weiterhin ungelöst. Queries, die records außerhalb des fast tier betreffen, werden ebenfalls an das Archiv gesendet und bleiben so langsam wie zuvor. Workloads, die gleichmäßig über ihre gesamte Historie hinweg lesen, sollten daher nur einen geringen Vorteil erwarten.
Beide tiers müssen dasselbe MongoDB-Release verwenden, da das Archiv die Queries der Anwendung direkt ausführt und verstehen muss. Ein älteres Deployment müsste daher vor der Einführung aktualisiert werden. Am wichtigsten ist, dass Thermocline zwar über eine umfangreiche Testsuite verfügt, aber noch keinen Produktionstraffic verarbeitet hat. Die gemessenen Vorteile gelten für diesen Testcluster und diesen Workload, nicht für jede MongoDB-Installation. Organisationen müssten daher ihre eigenen Traffic-Muster und Ausfalltests reproduzieren, bevor sie Schlussfolgerungen ziehen. Der Code und die Betriebsanweisungen sind im Thermocline repository unter der Apache-2.0-Lizenz verfügbar.
Für Organisationen, die prüfen, wo sie Datenbank-tiers betreiben können, stellt AEU Data europäische Cloud- und Dateninfrastruktur als eine verfügbare Infrastrukturoption bereit. Die allgemeinere Erkenntnis lautet, dass MongoDB storage tiering ein durch Arbeitsspeichermangel begrenztes replica set entlasten kann, wenn aktuelle Daten die Lesevorgänge dominieren. Es beseitigt jedoch weder die Schreibkosten des Archivs noch beschleunigt es historische Queries oder ersetzt eine Validierung in Produktion.