Benchmarking von MongoDB – Steigerung der NoSQL-Leistung

Datenbanksysteme sind entscheidende Komponenten im Zyklus jeder erfolgreich laufenden Anwendung. Jede Organisation, die sie einbezieht, hat daher den Auftrag, durch konsequente Überwachung und Bewältigung kleinerer Rückschläge eine reibungslose Leistung dieser DBMs sicherzustellen, bevor sie zu enormen Komplikationen eskalieren, die zu einem Ausfall der Anwendung oder einer langsamen Leistung führen können.

Sie fragen sich vielleicht, wie Sie feststellen können, ob die Datenbank wirklich ein Problem haben wird, während sie normal funktioniert. Nun, das ist es, was wir in diesem Artikel besprechen werden, und wir nennen es Benchmarking. Beim Benchmarking werden im Grunde eine Reihe von Abfragen mit einigen Testdaten zusammen mit einer Ressourcenbereitstellung ausgeführt, um festzustellen, ob diese Parameter dem erwarteten Leistungsniveau entsprechen.

MongoDB verfügt nicht über eine Standard-Benchmarking-Methodik, daher müssen wir diese beim Testen von Abfragen auf eigener Hardware lösen. So sehr Sie auch beeindruckende Zahlen aus dem Benchmark-Prozess erhalten, müssen Sie vorsichtig sein, da dies ein anderer Fall sein kann, wenn Sie Ihre Datenbank mit echten Abfragen ausführen.

Die Idee hinter dem Benchmarking ist es, sich einen allgemeinen Überblick darüber zu verschaffen, wie sich verschiedene Konfigurationsoptionen auf die Leistung auswirken, wie Sie einige dieser Konfigurationen optimieren können, um maximale Leistung zu erzielen, und die Kosten für die Verbesserung dieser Implementierung abzuschätzen. Außerdem wachsen Anwendungen mit der Zeit in Bezug auf Benutzer und wahrscheinlich die zu bedienende Datenmenge, daher müssen vor diesem Zeitpunkt Kapazitätsplanungen durchgeführt werden. Nachdem Sie einen steigenden Datentrend erkannt haben, müssen Sie ein Benchmarking durchführen, wie Sie die Anforderungen dieser enorm wachsenden Datenmenge erfüllen.

Überlegungen zum Benchmarking von MongoDB

1. Wählen Sie Workloads aus, die eine typische Darstellung der modernen Anwendungen von heute sind. Moderne Anwendungen werden täglich komplexer und das überträgt sich bis auf die Datenstrukturen. Das heißt, die Datenpräsentation hat sich mit der Zeit auch geändert, zum Beispiel das Speichern einfacher Felder in Objekten und Arrays. Es ist nicht ganz einfach, mit diesen Daten mit standardmäßigen oder eher minderwertigen Datenbankkonfigurationen zu arbeiten, da dies zu Problemen wie schlechter Latenz und schlechtem Durchsatz führen kann, die die komplexen Daten betreffen. Wenn Sie einen Benchmark durchführen, sollten Sie daher Daten verwenden, die Ihre Anwendung übersichtlich darstellen.
2. Schreibvorgänge doppelt prüfen. Stellen Sie immer sicher, dass alle Datenschreibvorgänge so ausgeführt wurden, dass kein Datenverlust möglich war. Dies dient der Verbesserung der Datenintegrität, indem sichergestellt wird, dass die Daten konsistent sind, und ist insbesondere in der Produktionsumgebung am besten anwendbar.
3. Verwenden Sie Datenmengen, die eine Darstellung von „Big Data“-Datensätzen sind, die sicherlich die RAM-Kapazität für einen einzelnen Knoten überschreiten werden. Wenn die Testarbeitslast groß ist, hilft es Ihnen, die zukünftigen Erwartungen an Ihre Datenbankleistung vorherzusagen und daher früh genug mit der Kapazitätsplanung zu beginnen.

Methodik

Unser Benchmark-Test wird einige große Standortdaten beinhalten, die von hier heruntergeladen werden können, und wir werden die Robo3t-Software verwenden, um unsere Daten zu manipulieren und die Informationen zu sammeln, die wir benötigen. Die Datei hat mehr als 500 Dokumente, die für unseren Test völlig ausreichen. Wir verwenden MongoDB Version 4.0 auf einem Ubuntu Linux 12.04 Intel Xeon-SandyBridge E3-1270-Quadcore 3,4 GHz dedizierten Server mit 32 GB RAM, Western Digital WD Caviar RE4 1 TB Spinning Disk und Smart XceedIOPS 256 GB SSD. Wir haben die ersten 500 Dokumente eingefügt.

Wir haben die folgenden Einfügebefehle ausgeführt

db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:0})
db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:1})

Bedenken schreiben

Write Concern beschreibt die Bestätigungsebene, die von MongoDB für Schreibvorgänge in diesem Fall in eine eigenständige MongoDB angefordert wird. Wenn dieser Wert für einen Betrieb mit hohem Durchsatz auf niedrig eingestellt ist, sind die Schreibaufrufe so schnell, dass die Latenzzeit der Anforderung verringert wird. Wenn der Wert dagegen hoch eingestellt ist, sind die Schreibaufrufe langsam und erhöhen folglich die Abfragelatenz. Eine einfache Erklärung dafür ist, dass Sie sich bei einem niedrigen Wert keine Gedanken über die Möglichkeit machen, einige Schreibvorgänge im Falle eines Mongod-Absturzes, eines Netzwerkfehlers oder eines anonymen Systemausfalls zu verlieren. Eine Einschränkung in diesem Fall ist, dass Sie nicht sicher sind, ob diese Schreibvorgänge erfolgreich waren. Wenn andererseits das Schreibinteresse hoch ist, gibt es eine Eingabeaufforderung zur Fehlerbehandlung, und somit werden die Schreibvorgänge bestätigt. Eine Bestätigung ist einfach eine Bestätigung, dass der Server den Schreibvorgang akzeptiert hat.

In unserem Test führte die Einstellung „Write Concern“ auf „Low“ dazu, dass die Abfrage in min. 0,013 ms und max. 0,017 ms ausgeführt wurde. In diesem Fall ist die grundlegende Bestätigung des Schreibens deaktiviert, aber man kann immer noch Informationen über Socket-Ausnahmen und eventuell ausgelöste Netzwerkfehler erhalten.

Wenn der Write Concern hoch eingestellt ist, dauert die Rückkehr fast doppelt so lange, wobei die Ausführungszeit 0,027 ms min. und 0,031 ms max. beträgt. Die Quittierung ist in diesem Fall garantiert, aber nicht zu 100% hat sie das Plattenjournal erreicht. In diesem Fall beträgt die Wahrscheinlichkeit eines Schreibverlusts aufgrund des 100-ms-Fensters, in dem das Journal möglicherweise nicht auf die Festplatte geschrieben wird, 50 %.

Journaling

Dies ist eine Technik, um sicherzustellen, dass kein Datenverlust auftritt, indem sie im Falle eines Ausfalls für Haltbarkeit sorgt. Dies wird durch eine Write-Ahead-Protokollierung in Journaldateien auf der Festplatte erreicht. Es ist am effizientesten, wenn der Schreibschutz hoch eingestellt ist.

Für eine sich drehende Festplatte ist die Ausführungszeit mit aktiviertem Journaling etwas hoch, in unserem Test betrug sie beispielsweise etwa 0,251 ms für dieselbe Operation oben.

Die Ausführungszeit für eine SSD ist jedoch für denselben Befehl etwas geringer. In unserem Test waren es etwa 0,207 ms, aber abhängig von der Art der Daten kann dies manchmal dreimal schneller sein als eine sich drehende Festplatte.

Wenn das Journaling aktiviert ist, bestätigt es, dass Schreibvorgänge in das Journal vorgenommen wurden, und stellt somit die Dauerhaftigkeit der Daten sicher. Folglich überlebt der Schreibvorgang ein Mongod-Shutdown und stellt sicher, dass der Schreibvorgang dauerhaft ist.

Für eine Operation mit hohem Durchsatz können Sie die Abfragezeiten halbieren, indem Sie w=0 setzen. Andernfalls, wenn Sie sicher sein müssen, dass Daten aufgezeichnet wurden bzw. im Falle eines Back-to-Life nach einem Ausfall wiederhergestellt werden, müssen Sie w=1 setzen.

Replikation

Die Bestätigung eines Schreibproblems kann für mehr als einen Knoten aktiviert werden, der der primäre und einige sekundäre innerhalb eines Replikatsatzes sind. Dies wird dadurch gekennzeichnet, welche Ganzzahl für den Schreibparameter bewertet wird. Wenn beispielsweise w =3 ist, muss Mongod sicherstellen, dass die Abfrage eine Bestätigung vom Hauptknoten und 2 Slaves erhält. Wenn Sie versuchen, einen Wert größer als eins festzulegen und der Knoten noch nicht repliziert ist, wird eine Fehlermeldung ausgegeben, dass der Host repliziert werden muss.

Die Replikation ist mit einem Latenzrückschlag verbunden, sodass die Ausführungszeit verlängert wird. Für die obige einfache Abfrage, wenn w =3, erhöht sich die durchschnittliche Ausführungszeit auf 270 ms. Ein treibender Faktor dafür ist der Bereich der Antwortzeit zwischen Knoten, die von Netzwerklatenz, Kommunikations-Overhead zwischen den 3 Knoten und Überlastung betroffen sind. Außerdem warten alle drei Knoten darauf, dass der andere fertig ist, bevor sie das Ergebnis zurückgeben. In einer Produktionsbereitstellung müssen Sie daher nicht so viele Knoten einbeziehen, wenn Sie die Leistung verbessern möchten. MongoDB ist für die Auswahl der zu bestätigenden Knoten verantwortlich, es sei denn, es gibt eine Spezifikation in der Konfigurationsdatei mit Tags.

Spinning Disk vs Solid State Disk

Wie oben erwähnt, ist eine SSD-Festplatte je nach den betroffenen Daten ziemlich schnell als eine sich drehende Festplatte. Manchmal könnte es dreimal schneller sein, daher lohnt es sich, bei Bedarf dafür zu bezahlen. Es wird jedoch teurer, eine SSD zu verwenden, insbesondere wenn es um große Datenmengen geht. MongoDB hat den Vorteil, dass es das Speichern von Datenbanken in Verzeichnissen unterstützt, die gemountet werden können, daher die Möglichkeit, eine SSD zu verwenden. Der Einsatz einer SSD und die Aktivierung von Journaling ist eine großartige Optimierung.

Schlussfolgerung

Das Experiment war sich sicher, dass die Deaktivierung von Write Concern zu einer verkürzten Ausführungszeit einer Abfrage auf Kosten der Wahrscheinlichkeit von Datenverlusten führt. Andererseits ist die Ausführungszeit bei aktiviertem Write Concern fast doppelt so lang, wenn es deaktiviert ist, aber es besteht die Gewissheit, dass keine Daten verloren gehen. Außerdem können wir begründen, dass SSD schneller ist als eine sich drehende Festplatte. Um jedoch die Dauerhaftigkeit der Daten im Falle eines Systemausfalls sicherzustellen, ist es ratsam, den Schreibschutz zu aktivieren. Wenn Sie den Schreibschutz für einen Replikatsatz aktivieren, stellen Sie die Zahl nicht zu groß ein, sodass dies zu einer Leistungsminderung auf der Anwendungsseite führen kann.