Während Entwickler und erfahrene Datenbankspezialisten die flexiblen Möglichkeiten und vor allem die Performance der NoSQL-Datenbank MongoDB feiern, tun sich Unternehmen schwer mit der Entscheidung, Teile ihrer Datenbankarchitektur zu migrieren. Das Datenbank-Setup stellt das Zentrum der Kundenkommunikation dar und wird wie ein Augapfel gehütet. Viele Unternehmen können nicht einschätzen, wie hoch der Aufwand und das Risiko einer Migration im Vergleich zur gewünschten Mehrleistung ausfällt. Eine Bestandsaufnahme.
MongoDB ist in aller Munde. Seit ihrer Einführung im Jahre 2009 hat die NoSQL-Datenbank ein stetiges, mitunter atemberaubendes Wachstum hingelegt. Die Abkehr von bestehenden Datenbank-Architekturen steht synonym für eine moderne Form der Datenverarbeitung und wird damit zu einem der wesentlichen Erfolgsfaktoren eine erfolgreichen Digitalisierungs- und BigData-Strategie hochstilisiert.
Dabei wird gelegentlich übersehen, dass längst klar ist, dass MongoDB und der gesamte NoSQL-Ansatz nicht nur Vorteile mit sich bringen. Für manche Aufgaben mag es die bessere Option sein, bei den starreren, aber in diesen Grenzen sehr performanten SQL-Datenbanken zu bleiben. Und Performance ist beileibe nicht das einzige, wichtige Selektionskriterium. Ausfallsicherheit, Wartungsfreundlichkeit und letztlich die Kosten von Implementierung und Betrieb der Datenbank müssen ebenso Berücksichtigung bei der Bedarfsanalyse finden, sonst bleibt das Bild unvollständig.
Es geht also nicht um eine simple Schwarz-Weiß-Entscheidung zwischen zwei Systemen. Bei genauer Analyse zeigen sich präzise die Vor- und Nachteile der unterschiedlichen Technologien. Und in vielen Fällen ist MongoDB tatsächlich besser, wenn sorgfältig geplant wurde. Aber eben nicht immer. NoSQL steht für Not only SQL, also für die umsichtige Kombination beider Technologien.
Das kann NoSQL
NoSQL steht in enger Verbindung zum Schlüsselbegriff BigData. In der Tat zeigen uns mehrjährigen Erfahrungen im Umgang mit der Technik, dass sie eine hohe Performance leistet, wenn es darum geht, riesige Datenmengen zu verarbeiten. Ein wesentliches Kriterium dafür ist die verteilte Architektur der Datenbank. Hinter dem Fachbegriff Sharding verbirgt sich der simultane Betrieb zahlreicher Datenspeicher (Knoten), die gemeinsam die Datenbankleistung erbringen. Daraus ergibt sich, dass die verschiedenen Knoten simultan unterschiedliche Aufgaben übernehmen können, was die Performance erhöht. Daraus ergibt sich aber natürlich auch, dass eine der großen Herausforderungen bei der Nutzung von NoSQL-Systemen darin besteht, diese Architektur sorgfältig aufzubauen und zu pflegen.
Wir bei Formware konzentrieren uns entlang der Anforderungen unserer Kundinnen und Kunen auf Dokumenten-orientierte Datenbanken. Im NoSQL-Universum sind das zum Beispiel CouchDB und MongoDB. Bei einer großen Menge von Dokumenten, die kontinuierlich anfallen, besitzt MongoDB gleich eine Reihe von bauartbedingten Merkmalen, die die Performance steigern.
Die Schreib- und Lese-Performance ist in MongoDB schon dadurch höher, dass sie über mehrere Knoten verteilt wird. Das sorgt gleichzeitig für mehr Ausfallsicherheit, da Knoten und damit deren Datenbestand redundant gehalten werden. Die Systematik von MongoDB erlaubt eine sehr starke Kompression der Dokumente. Das ist natürlich bei großen Datenbeständen ein besonders wichtiges Performance-Kriterium. Außerdem ist das System flexibel im Umgang mit unterschiedlichen Dateiformaten und ‑größen. Für unsere Dokument-orientierten Anwendungen wollten wir auf Filereferenzen verzichten und die Dokumente in der Datenbank direkt ablegen, um diese MongoDB-Vorteile zu nutzen. Interessant dabei: Die maximale Dokumentgröße in MongoDB beträgt 16 Mbyte. Alles darüber wird automatisch in Chunks geteilt und im sogenanntem GridFS abgelegt. Das macht der Datenbanktreiber automatisch. Der Entwickler greift einfach auf die Datei in der Datenbank zu, allerdings benötigt er dafür eine spezielle Streaming-API, anders als bei normalen Dokumenten.
Herausforderungen bei der Planung und im Betrieb
Die Merkmale, die MongoDB schnell machen, liegen vor allem in dem dezentralen Ansatz der Datenhaltung. Dadurch entstehen eigentlich Zielkonflikte: Wie kann die Konsistenz der Daten über die Knoten hinweg erhalten werden, wenn die Knoten mitunter simultan arbeiten? Einerseits muss die Konsistenz regelmäßig in Intervallen geprüft werden, dies steht aber eigentlich im Widerspruch zum Paradigma der Availability, der Verfügbarkeit. Jeder Knoten soll permanent schreib- beziehungsweise lesebereit sein und damit die Performance des Systems erhalten. MongoDB löst diese Konflikte zuverlässig und wir als Betreiber gewinnen dadurch viele Vorteile.
Und drittens soll die Datenbank insgesamt verfügbar bleiben, selbst wenn einzelne Knoten zeitweise die Verbindung verlieren oder ausfallen. Das ist die Partitionstoleranz.
Es können nie mehr als zwei der drei Anforderungen gleichzeitig vollständig erfüllt werden. Man muss also Abstriche in einem der drei Leistungsbereiche machen und es gilt im Vorfeld sehr genau zu planen, wo das geschieht. Es kann auch unterschiedliche vordefinierte Arbeitsszenarien geben, die hier unterschiedliche Prioritäten setzen.
Zwei Jahre lang haben wir bei Formware gelernt, mit diesen Systemen zu arbeiten. Inzwischen beträgt das gesamte gespeicherte Datenvolumen 100 TB in unkomprimiertem Zustand. Rund drei Millionen Anfragen laufen täglich durch diese Systeme.
Zu Beginn haben wir die Bordmittel von MongoDB genutzt, allen voran den OPSManager, ein ungemein wertvoller Begleiter für den Anfang. Mit wachsendem Verständnis des Systems, greifen unsere Datenbank-Administratoren aber inzwischen lieber auf unsere eigenen Tools und Toolsets zurück, um wiederkehrende Aufgaben zu automatisieren und das System zu administrieren. Auf den OpsManager können wir daher mittlerweile verzichten.
Die Kosten im Blick behalten
MongoDB ist eine OpenSource-Datenbank. Das verführt erst einmal zu der Annahme, es handelt sich um ein preiswertes und auch risikoarmes Projekt, wenn man auf die NoSQL-Datenbank migriert. Tatsächlich gibt es neben den kostenlosen Komponenten auch Enterprise-Services und gehostete Lösungen, für die Kosten anfallen.
Spannend wird es aber vor allem bei den Tools, die eben nicht kostenfrei sind. Diese sind gekoppelt an Service-Verträge, so dass je nach Größe der zu verwaltenden Datenbank und Menge der Zugriffe Lizenzkosten im fünf- bis sechsstelligen Bereich anfallen.
Und davon können heute unsere Kundinnen und Kunden profitieren. Wir können das Gesamtpaket – Datenbank und Administration – günstiger betreiben, als es mit der Nutzung des OPSManagers möglich wäre. Je mehr Kundinnen und Kunden wir begeistern können, umso besser verteilen sich unsere Entwicklungskosten. Auf Wunsch erhält jede Kundin und jeder Kunde Zugriff auf diese Tools und dadurch Zugriff auf MongoDB-Instanzen.
Unabhängig vom Preis sind wir bei Formware natürlich in der Lage, bei der Implementierung und Migration zu unterstützen. Wir haben von unseren eigenen Fehlern gelernt und die Herausforderungen von MongoDB und von Migrationsprojekten verstanden. Auch diese „Lernkurve“ beinhaltet Kosten, die in eine umfassende Kalkulation einfließen sollten. Und nicht zuletzt stehen unsere Server in Deutschland. Sie erfüllen alle gültigen Datenschutzbestimmungen und die ISO 27001 für Informationssicherheitsmanagement.