MongoDB Storage Engines

Erste Erfahrungen aus der Praxis

11. Februar 2016Michael Schuboth

MongoDB – diese NoSQL-Datenbank ist den meisten Fachleuten bereits ein Begriff, euch auch?

Die dokumentenorientierte Datenbank wurde im Gartner Magic Quadrant 2015 als Führer im Bereich der operativen Datenbankmanagementsysteme gelistet, direkt hinter den klassischen relationalen Datenbanken von Oracle, IBM und Microsoft. Auch bei adesso setzen wir MongoDB bereits seit einigen Jahren in unseren Projekten und Lösungen ein, so zum Beispiel in der MIG|Suite.

Die MIG|Suite ist eine Lösung der adesso insurance solutions GmbH für Migrationsprojekte im Versicherungsumfeld. Mithilfe der MIG|Suite können Versicherungen ihre Daten – Versicherungsverträge – von ihren „Altsystemen“, meist hostbasierte Systeme oder relationale Datenbanken, auf ein neues System migrieren.

Die MongoDB dient in der MIG|Suite als Datenspeicher für die Versicherungsverträge, die aus dem Altsystem importiert werden. Dabei macht sich die MIG|Suite die Schemafreiheit der MongoDB zunutze. Durch diese wird es ermöglicht, die Daten eins zu eins aus dem Altsystem zu übernehmen. Dabei hilft die Komponente MIG|Tools, welche die Strukturen des Altsystems in persistierbare Java-Klassen umwandelt. Diese geben dann beim Import der Daten die Struktur in MongoDB vor. Die folgende Abbildung stellt eine Grobübersicht der MIG|Suite dar:

MIG Suite

So ist auch gewährleistet, dass die Spezialisten der Altsysteme weiterhin die Daten verstehen und damit ohne Umdenken arbeiten können. Dies ist ein entscheidender Vorteil, wenn es in der Komponente MIG|Transform dann um das Mapping des Altsystems auf das des neuen Systems geht.

MongoDB 3.2 – WiredTiger löst MMAPv1 ab

Storage Engines sind die Teile der Datenbank, welche für das Ablegen der Daten auf dem Dateisystem verantwortlich sind. Bis zur Version 2.8 war MMAPv1 die einzige Storage Engine in MongoDB. Dann wurde nach der Übernahme des gleichnamigen Unternehmens zusätzlich WiredTiger als Alternative zu MMAPv1 ausgeliefert. Mit der im Dezember erschienen Version 3.2 (heute aktuell 3.2.1) wurde WiredTiger erstmals als Standard-Storage-Engine ausgeliefert. Das Verwenden von MMAPv1 muss dadurch beim Start der Datenbankinstanz explizit angegeben werden, ansonsten kommt WiredTiger zum Einsatz. Neben WiredTiger und MMAPv1 hat MongoDB zwei weitere Storage Engines ausgeliefert, eine In Memory Storage Engine und eine, die Verschlüsselung anbietet. Beide sind jedoch nur Teil der Enterprise-Version. Darüber hinaus wird mit der Storage Engine API die Möglichkeit angeboten, eigene Storage Engines zu entwickeln. So hat Facebook zum Beispiel RocksDB entwickelt.

MMAPv1 und WiredTiger in MIG|Suite

Der größte Unterschied zwischen MMAPv1 und WiredTiger ist die Komprimierung der Daten. Während MMAPv1 die Daten ohne Komprimierung auf das Dateisystem schreibt, ist es mit WiredTiger möglich, verschiedene Grade der Komprimierung auszuwählen. Somit stellt sich in Projekten mit MongoDB die Frage, welche Storage Engine eingesetzt werden soll, die mit dem alten oder dem neuen Standard.

Im Rahmen eines MIG|Suite-Projekts habe ich diese Fragestellung genauer untersucht. Grundlage der Tests waren 1.000 anonymisierte Versicherungsverträge mit insgesamt 6.743 Vertragsständen aus einem Hostsystem. Diese wurde in eine 205 MB große Textdatei mithilfe der Komponente MIG|Import in die MongoDB importiert. Einmal mit MMAPv1 als Storage Engine und ein weiteres Mal mit WiredTiger.

In dieser Grafik sieht man die durchschnittlichen Testergebnisse des Imports mit den beiden Storage Engines:

Testergebnisse 1Testergebnisse 2

Die Ergebnisse sind überraschend, denn auch bei dieser geringen Menge an Daten zeigen sich die weitreichenden Effekte des trivialen Austauschs der Storage Engine. WiredTiger zeigt deutlich, wieso MongoDB einen Wechsel der Standard-Storage-Engine vorgenommen hat. Neben der deutlichen Reduzierung des verbrauchten Speicherplatzes konnte darüber hinaus auch die Geschwindigkeit des Imports verbessert werden. Das hatte ich aufgrund des höheren Ressourcenverbrauchs von WiredTiger beim Komprimieren nicht erwartet – es ist aber eine weitere Erkenntnis, die zur Auswahl der Storage Engine beiträgt.

Abschließend kann festgehalten werden, dass sich bei Daten, die in Form von Text vorliegen, bereits bei kleinen Mengen ein Einsatz von WiredTiger lohnt. Die Entscheidung für eine Storage Engine sollte immer auf Basis der zu persistierenden Daten gefällt werden. Dabei muss auch das Lesen dieser Daten betrachtet werden. Zudem bietet sich mit der Storage Engine API zusätzlich eine Schnittstelle, die es ermöglicht, eigene Storage Engines zu entwickeln.

Ich würde mich sehr freuen, wenn ihr in den Kommentaren eure eigenen Erfahrungen mit den verschiedenen Storage Engines mit mir teilt. Darüber hinaus stehe ich euch sehr gerne für Fragen zu NoSQL, MongoDB und die MIG|Suite zur Verfügung.

Michael Schuboth Michael Schuboth ist Software Engineer bei der adesso insurance solutions GmbH. Er ist technisch für die MIG|Suite verantwortlich, interessiert sich für die neuesten Technologietrends und leitet das Kölner Fußballteam.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentare

Christian 12. Februar 2016

Hallo Michael,

danke für den wirklich interessanten Artikel.

Eine einfache Erklärung für den Effekt, dass komprimierte Daten schneller geschrieben werden ist der langsame I/O. Während die Geschwindigkeit der Prozessoren seit Jahren zulegt sind Festplatten und I/O Komponenten gerade beim Schreiben extrem langsam. Erst die SSDs, die nun de facto Standard sind, haben hier einen Geschwindigkeitsschub gebracht.

Dies ist auch die Erklärung, warum eine Kompression einen Geschwindigkeitsvorteil bringen kann, denn je weniger Daten über den langsamen IO-Bus geschickt werden müssen, desto schneller ist das Gesamtsystem. Außerdem profitieren viele Kompressionsverfahren durch direkt im Silizium verdrahtet Algorithmen.

Kommentar hinzufügen:

Ihr Kommentar: