INSIGHTS Wie wir 75% Festplattenspeicher einsparen konnten:MongoDB und TokuMX im Vergleich
ABOUT YOU TECH
Autor: Berend Kapelle
In diesem Blog-Artikel möchte ich einen kurzen Überblick über unsere Erfahrung mit der MongoDB Welt geben. Durch MongoDB Forks gibt es mittlerweile Drop-In Lösungen, die sich genau wie die Original MongoDB verhalten. Außerdem werde ich die technischen Unterschiede beschreiben und dann auf die Vor- und Nachteile zu sprechen kommen, die die einzelnen Lösungen mit sich bringen bzw. auf die Erfahrung eingehen, die wir mit beiden Lösungen gemacht haben.
Fangen wir erstmal mit den beiden Hauptakteuren und deren Hintergrund an:
1. MongoDB
MongoDB wurde 2009 erstmals veröffentlicht und ist derzeit bei der stable Version 3.0.6. Vorhergehende stable Versionen waren 2.4 und 2.6. Mit 3.0 wurde erstmals eingeführt, dass man die Storage Engine wechseln kann. Dies kennt man vielleicht von MySQL, wo MyISAM und InnoDB die bekanntesten Storage Engine sind. MongoDB arbeitet neben der Standard Storage Engine auch parallel an WiredTiger, einer StorageEngine, die im Universitätsumfeld entwickelt wurde und dann später von MongoDB aufgekauft wurde.
MongoDB/WiredTiger ist komplett open source und MongoDB Inc., die Firma dahinter verdient Geld mit Supportlizenzen und Consulting zu MongoDB
2. TokuMX
TokuMX ist als Fork von MongoDB in der Version 2.4 gestartet und daher auch weitest gehend kompatibel mit der jeweiligen MongoDB Version. Die Arbeit an dem Fork für Version 2.6 wurde eingestellt, als bekannt wurde, dass Version 3.0 eine Storage Engine hat und man MongoDB nicht mehr komplett forken, sondern sich nur noch um die Storage Engine kümmern muss. Mittlerweile wurde die Firma hinter TokuMX, TokuTek von Percona aufgekauft. Tokutek ist ebenfalls ein Universitätsstartup (u.a. MIT). Percona ist bekannt aus der MySQL Welt für Clusterlösungen. TokuTek hat neben TokuMX auch eine Storage Engine für MySQL: TokuDB.
TokuMX ist wie MongoDB komplett Opensource und Tokutek bzw. jetzt Percona verdienen ebenfalls Geld durch Supportlizenzen und Consulting. Es gibt außerdem eine kostenpflichtige Enterprise Version von TokuMX, die ein paar Zusatzfeatures wie HotBackup bietet.
Welche Versionen sind gerade “ready for production use”?
Alle MongoDB Versionen sind natürlich in Production Use gewesen und werden/wurden auch aktiv mit Security und Bugs Fixes versorgt, dazu gehören alle Stable Versionen 2.4, 2.6 und jetzt 3.0. WiredTiger ist ab MongoDB3.0 neben der Standard Mongo Storage Engine mit dabei, man kann WiredTiger einfach in der Konfiguration als StorageEngine angeben.
TokuMX gibt es seit Version 2.4 als stable, die Version2.6 wurde nicht fertiggestellt und wird es wohl auch nicht, weil inzwischen TokuMX als StorageEngine für MongoDB entwicklet wird. Diese StorageEngine TokuMXSE wird noch nicht als stable bezeichnet, die Nachrichten dazu sind aber recht spärlich. Die Entwicklung ist ein wenig hinter der aktuellen MongoDB Entwicklung zurückgeblieben (letzte TokuMXSE Version basiert auf MongoDB 3.0.3, MongoDB ist bei 3.0.6). Laut Entwicklern ist der Grund dafür, dass man durch die Kapselung per Storage Engine noch nicht alle Features von TokuMX in TokuMXSE integrieren konnte. Wer trotzdem einmal mit der TokuMXSE rumspielen will, findet die letzten Versionen hier.
Wie unterscheiden sich die einzelnen Versionen < Mongo3.0?
Schauen wir uns zunächst einmal die Unterschiede zwischen MongoDB und TokuMx vor MongoDB3.0 an:
Locking
MongoDB hat seit 2.2 Locking on Database Level (zuvor gab es ein globales Lock per mongod Instanz), TokuMX hat ein Locking auf Document Level. Wir haben die Erfahrung gemacht, dass Applikationen, die sehr viele Schreibzugriffe auf unterschiedliche Dokumente in der DB machen, mit TokuMX performanter laufen.
Transaktionen
Bei MongoDB ist jede Transaktion für sich atomar, es gibt jedoch keinerlei Transaktionen, wie man es von MySQL und anderen SQL Datenbanken mit BEGIN TRANSACTION, COMMIT/ROLLBACK kennt. Bei TokuMX gibt es Transaktionen. Da diese Transaktionsbefehle über db.command ausgeführt werden, sollten auch die jeweiligen Wrapper für MongoDB (z.B. pymongo oder andere) damit zurecht kommen. Allerdings verhält sich die Applikation dann nicht mehr gleich unter den beiden Datenbanken. Vor allem durch die Integration von Transaktionen hat TokuMX ein unterschiedliches oplog Format. Statt einem Befehl/ einer Transaktion stehen dort nun mehrere Befehle innerhalb einer Transaktion. Dies ist wichtig für Frameworks wie zum Beispiel Meteor, die auf diesem oplog aufbauen und durch das andere Format nicht mit TokuMX funktionieren.
Fractal tree vs. B-Tree binary
Wenn man Blogs und offizielle Webseiten zu TokuMX und MOngoDB verfolgt, stößt man häufiger auf die Begriffe Fractal tree und binary tree. TokuMX benutzt fractal trees, MongoDB nutzt B-Trees. Wer sich ein wenig mit fraktalen Bäumen beschäftigen will, findet unter den weiterführenden Links einige interessante Artikel.
Fraktale Bäume haben einen Vorteil bei der Schreibgeschwindigkeit und ermöglichen bessere Kompression und weniger Schreibzugriffe auf die Festplatte. SSDs halten so länger und langsame Non-SSD Festplatten müssen weniger befragt werden — in beiden Fällen also ein Vorteil.
Im Vergleich von MongoDB zu TokuMX (alles vor Version 3.0) gewinnt TokuMX klar und es gibt eigentlich keinen Grund, TokuMX nicht einzusetzen. Wir nutzen TokuMX im Produktionsbetrieb und konnten eine Festplatten-Platz Ersparnis von 75% beobachten (~20GB in MongoDB vs. ~5GB in TokuMX). Bei der Geschwindigkeit haben wir einen ca. 30% besseren Durchsatz innerhalb unserer Applikation gemessen. Wir nutzen TokuMX, um unsere Produktstammdaten zu pflegen, zu verbessern und zu aggregieren — also allgemein für die Anzeige im Shop vorzubereiten. Dabei durchläuft jedes Produkt mehrere Schritte, die wir in ebenso vielen Collections speichern. Wir können daher einen Komplettdurchlauf starten, der jedes Mal das gleiche Ergebnis hat, so lange es keine Änderungen vom Händler am Ursprungsprodukt gegeben hat. Bei diesem Komplettdurchlauf ist TokuMX zwischen 30% und 40% schneller gewesen. Dabei benutzen wir normale Festplatten und keine SSDs, unser Dataset passt komplett in den Speicher.
Neuere Versionen, Mongo3.0+
Kommen wir nun zu den neueren Versionen, also MongoDB3.0 mit der Standard Storage Engine, mit WiredTiger und TokuMX SE.
Wir haben hier noch keine eigenen Benchmarks, erste Berichte und Benchmarks deuten darauf hin, dass TokuMX 2.4 mit WiredTiger bei hoher I/O Last mithalten kann, aber bei rechen-intensiven Tasks (mapreduce und aggregations) hinter WiredTiger bleibt. WiredTiger benutzt weder Fractal Tree noch B-Trees, sondern LSM Trees. TokuMX SE hat laut Entwickleraussagen noch nicht alle Features von TokuMX, da die Einbindung via Storage Engine Limitierungen mit sich bringt, die man bei einem kompletten Fork nicht hat. Wir werden zunächst abwarten, bis TokuMX SE in einer finalen Version veröffentlicht wird und dann zusammen mit WiredTiger einmal in unserem spezifischen Szenario austesten. Im Percona-Blog wurde ein sehr detaillierter Benchmark veröffentlicht, den man natürlich mit Vorsicht lesen sollte, da Percona Hersteller von TokuMX ist. Allerdings ist der Benchmarkaufbau sehr genau beschrieben und sollte somit wiederholbar sein.
Fazit:
TokuMX kann man gut verwenden, wenn man keine Volltextsuche braucht und einem das oplog Format egal ist. Wer TokuMX nicht verwenden kann, sollte auf MongoDB3.0 umsteigen. TokuMXSE ist noch nicht produktionsreif.
Wenn wir greifbare Ergebnisse zu TokuMXSE und MongoDB WiredTiger haben, werden wir uns dazu wieder melden. In den Release Notes/Blog Postings zu MongoDB3.0 wird auch von einer (derzeit) experimentellen In-Memory Storage Engine berichtet. Sobald diese verfügbar ist, werden wir uns diese genau anschauen, um sie etvl. in unsere Unittest-Umgebung zu integrieren.
Weiterführende Links
More articles
ABOUT YOU TECH
ABOUT YOU TECH