mySQL vs. ElasticSearch vs. MongoDB

Anfang des Jahres habe ich mySQL und MongoDB aus Sicht der Daten verglichen, jetzt geht es um Leistung. Neu im Bunde ist dieses Mal ElasticSearch, eine nicht-Datenbank, die sich vor allem mit schneller Volltextsuche rühmt, aber kann sie auch im Praxiseinsatz mithalten?

mySQL dürfte die derzeit weltweit am weitesten verbreitete Datenbank sein. Einfach, schnell unkompliziert - zumindest für Kleinstapplikationen, damit lockt das Urgestein. Doch sobald es um mittlere Datenmengen, Performance, Skalierbarkeit oder Zuverlässigkeit geht, fangen die Probleme an.

Mit ElasticSearch habe ich bisher kaum Berührungspunkte. Eingesetzt habe ich es noch nie, aber genau das soll sich aus aktuellem Anlass jetzt ändern. Sich selbst bezeichnet das Projekt nicht als Datenbank, sondern als hochperfomante Suchmaschine, vorzugsweise für die Volltextsuche. Warum es keine Datenbank ist, konnte mir bisher zwar niemand erklären, aber ich nehme diese Tatsache vorerst als gegeben hin.

MongoDB hat sich schon vor drei Jahren im Vergleich gegen CouchDB und Postgres durchgesetzt. ElasticSearch kommt mit einer großen Hypothek: Ich erwarte mir einen Performancevorteil gegenüber mySQL, der den zusätzlichen Hardware- und Entwicklungsaufwand rechtfertigt. Die aktuelle Beliebtheit einer Technologie war noch nie ein Qualitätskriterium, schon gar nicht für mich. MongoDB haben wir bereits im Unternehmenseinsatz, es soll zumindest die Chance bekommen, sich gegen die reine ElasticSearch zu behaupten.

Real-World Test

In meinem derzeitigen Hauptprojekt werden große Datenmengen verarbeitet (mittlerweile nennt man so etwas "BigData"). Millionen von Einzeldaten werden kombiniert, um am Ende ein Selektionsergebnis zu erhalten, dass schließlich die Datenbasis für zukünftige Abfragen weiter vergrößert. Genutzt wird diese Applikation von verschiedenen Anwendern mit unterschiedlichen Anforderungsprofilen. Die Performance ist seit Jahren ziemlich konstant, trotzdem gab es seitens der Nutzer den Wunsch nach einer Beschleunigung. Als Wunschziel wurden "20-50% der aktuellen Dauer einer Seketion" ausgegeben.

Die Software ist nicht optimal, hier gibt es definitiv noch Optimierungsmöglichkeiten, aber der mit großem Abstand größte Flaschenhals ist die genutzte mySQL-Datenbank: Die Selektionen sind nicht selten so aufwendig, dass ein kompletter Slave für Minuten, manchmal sogar Stunden blockiert ist. Die Nutzung von MyISAM ist dabei nicht gerade ein Vorteil, insbesondere in der Replikation, aber ein Wechsel zu InnoDB liegt außerhalb meines Entscheidungsspielraums - und selbst dann ist fraglich, wie weit sich die Performance steigern lassen würde.

Das Datenmodell ist über Jahre gewachsen und auf die Datenerfassung hin optimiert. Das diese möglichst schnell läuft, hat höhere Priorität als mein Projekt und eine Änderung des Datenmodells würde sich auf viele andere Projekte auswirken.

Für den Test nutze ich unsere Entwicklungsdatenbank: Knapp 300.000 Datensätze in der Haupttabelle mit unterschiedlich vielen Zusatzdaten in drei weiteren Tabellen. Diese vier Tabellen werden für die meisten Selektionen - nicht nur von meiner Applikation - genutzt, also typischerweise per JOIN mit der Haupttabelle verbunden.

Die Testdaten kommen unseren Live-Daten in Struktur und Inhalt ziemlich nahe, sollten also ein realistisches Testszenario bilden.

Der Test soll hauptsächlich zeigen, wie gut sich alle drei Lösungen bei mehreren gleichzeitig laufenden komplexen Selektionen verhalten und ob hierbei ein Geschwindigkeitsgewinn erzielt werden kann. Aber zunächst geht es um die Installation und Befüllung der Testdatenbanken.

Ich erwarte, dass mySQL weit abgeschlagen hinter ElasticSearch und MongoDB landen wird. Welche der beiden NoSQL-Technologien allerdings die Nase vorn haben wird, möchte ich nicht prognostizieren. Es würde mich weder überraschen, wenn MongoDB relativ weit hinter ElasticSearch bleibt, noch wenn die Datenbank die Suchmaschine deutlich schlägt - immerhin geht es hier um die Selektion mehrere Felder und nicht um eine Volltextsuche über den gesamten Datenbestand.