11. Februar 2016 von Michael Schuboth
MongoDB Storage Engines
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:
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:
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.