Keine Angst vor MongoDB

Während Entwick­ler und erfah­rene Daten­bank­spe­zia­lis­ten die flexi­blen Möglich­kei­ten und vor allem die Perfor­mance der NoSQL-Daten­bank MongoDB feiern, tun sich Unter­neh­men schwer mit der Entschei­dung, Teile ihrer Daten­bank­ar­chi­tek­tur zu migrie­ren. Das Daten­bank-Setup stellt das Zentrum der Kunden­kom­mu­ni­ka­tion dar und wird wie ein Augap­fel gehütet. Viele Unter­neh­men können nicht einschät­zen, wie hoch der Aufwand und das Risiko einer Migra­tion im Vergleich zur gewünsch­ten Mehrleis­tung ausfällt. Eine Bestandsaufnahme.


MongoDB ist in aller Munde. Seit ihrer Einfüh­rung im Jahre 2009 hat die NoSQL-Daten­bank ein steti­ges, mitun­ter atembe­rau­ben­des Wachs­tum hinge­legt. Die Abkehr von bestehen­den Daten­bank-Archi­tek­tu­ren steht synonym für eine moderne Form der Daten­ver­ar­bei­tung und wird damit zu einem der wesent­li­chen Erfolgs­fak­to­ren eine erfolg­rei­chen Digita­li­sie­rungs- und BigData-Strate­gie hochsti­li­siert.

Dabei wird gelegent­lich überse­hen, dass längst klar ist, dass MongoDB und der gesamte NoSQL-Ansatz nicht nur Vorteile mit sich bringen. Für manche Aufga­ben mag es die bessere Option sein, bei den starre­ren, aber in diesen Grenzen sehr perfor­man­ten SQL-Daten­ban­ken zu bleiben. Und Perfor­mance ist beileibe nicht das einzige, wichtige Selek­ti­ons­kri­te­rium. Ausfall­si­cher­heit, Wartungs­freund­lich­keit und letzt­lich die Kosten von Imple­men­tie­rung und Betrieb der Daten­bank müssen ebenso Berück­sich­ti­gung bei der Bedarfs­ana­lyse finden, sonst bleibt das Bild unvollständig.

Es geht also nicht um eine simple Schwarz-Weiß-Entschei­dung zwischen zwei Syste­men. Bei genauer Analyse zeigen sich präzise die Vor- und Nachteile der unter­schied­li­chen Techno­lo­gien. Und in vielen Fällen ist MongoDB tatsäch­lich besser, wenn sorgfäl­tig geplant wurde. Aber eben nicht immer. NoSQL steht für Not only SQL, also für die umsich­tige Kombi­na­tion beider Technologien.

Das kann NoSQL

NoSQL steht in enger Verbin­dung zum Schlüs­sel­be­griff BigData. In der Tat zeigen uns mehrjäh­ri­gen Erfah­run­gen im Umgang mit der Technik, dass sie eine hohe Perfor­mance leistet, wenn es darum geht, riesige Daten­men­gen zu verar­bei­ten. Ein wesent­li­ches Krite­rium dafür ist die verteilte Archi­tek­tur der Daten­bank. Hinter dem Fachbe­griff Sharding verbirgt sich der simul­tane Betrieb zahlrei­cher Daten­spei­cher (Knoten), die gemein­sam die Daten­bank­leis­tung erbrin­gen. Daraus ergibt sich, dass die verschie­de­nen Knoten simul­tan unter­schied­li­che Aufga­ben überneh­men können, was die Perfor­mance erhöht. Daraus ergibt sich aber natür­lich auch, dass eine der großen Heraus­for­de­run­gen bei der Nutzung von NoSQL-Syste­men darin besteht, diese Archi­tek­tur sorgfäl­tig aufzu­bauen und zu pflegen.

Wir bei Formware konzen­trie­ren uns entlang der Anfor­de­run­gen unserer Kunden auf Dokumen­ten-orien­tierte Daten­ban­ken. Im NoSQL-Univer­sum sind das zum Beispiel CouchDB und MongoDB. Bei einer großen Menge von Dokumen­ten, die konti­nu­ier­lich anfal­len, besitzt MongoDB gleich eine Reihe von bauart­be­ding­ten Merkma­len, die die Perfor­mance steigern.

Die Schreib- und Lese-Perfor­mance ist in MongoDB schon dadurch höher, dass sie über mehrere Knoten verteilt wird. Das sorgt gleich­zei­tig für mehr Ausfall­si­cher­heit, da Knoten und damit deren Daten­be­stand redun­dant gehal­ten werden. Die Syste­ma­tik von MongoDB erlaubt eine sehr starke Kompres­sion der Dokumente. Das ist natür­lich bei großen Daten­be­stän­den ein beson­ders wichti­ges Perfor­mance-Krite­rium. Außer­dem ist das System flexi­bel im Umgang mit unter­schied­li­chen Datei­for­ma­ten und ‑größen. Für unsere Dokument-orien­tier­ten Anwen­dun­gen wollten wir auf Filere­fe­ren­zen verzich­ten und die Dokumente in der Daten­bank direkt ablegen, um diese MongoDB-Vorteile zu nutzen. Inter­es­sant dabei: Die maximale Dokument­größe in MongoDB beträgt 16 Mbyte. Alles darüber wird automa­tisch in Chunks geteilt und im sogenann­tem GridFS abgelegt. Das macht der Daten­bank­trei­ber automa­tisch. Der Entwick­ler greift einfach auf die Datei in der Daten­bank zu, aller­dings benötigt er dafür eine spezi­elle Strea­ming-API, anders als bei norma­len Dokumenten.

Heraus­for­de­run­gen bei der Planung und im Betrieb

Die Merkmale, die MongoDB schnell machen, liegen vor allem in dem dezen­tra­len Ansatz der Daten­hal­tung. Dadurch entste­hen eigent­lich Zielkon­flikte: Wie kann die Konsis­tenz der Daten über die Knoten hinweg erhal­ten werden, wenn die Knoten mitun­ter simul­tan arbei­ten? Einer­seits muss die Konsis­tenz regel­mä­ßig in Inter­val­len geprüft werden, dies steht aber eigent­lich im Wider­spruch zum Paradigma der Availa­bi­lity, der Verfüg­bar­keit. Jeder Knoten soll perma­nent schreib- bezie­hungs­weise lesebe­reit sein und damit die Perfor­mance des Systems erhal­ten. MongoDB löst diese Konflikte zuver­läs­sig und wir als Betrei­ber gewin­nen dadurch viele Vorteile.

Und drittens soll die Daten­bank insge­samt verfüg­bar bleiben, selbst wenn einzelne Knoten zeitweise die Verbin­dung verlie­ren oder ausfal­len. Das ist die Partitionstoleranz.

Es können nie mehr als zwei der drei Anfor­de­run­gen gleich­zei­tig vollstän­dig erfüllt werden. Man muss also Abstri­che in einem der drei Leistungs­be­rei­che machen und es gilt im Vorfeld sehr genau zu planen, wo das geschieht. Es kann auch unter­schied­li­che vorde­fi­nierte Arbeits­sze­na­rien geben, die hier unter­schied­li­che Priori­tä­ten setzen.

Zwei Jahre lang haben wir bei Formware gelernt, mit diesen Syste­men zu arbei­ten. Inzwi­schen beträgt das gesamte gespei­cherte Daten­vo­lu­men 100 TB in unkom­pri­mier­tem Zustand. Rund drei Millio­nen Anfra­gen laufen täglich durch diese Systeme.

Zu Beginn haben wir die Bordmit­tel von MongoDB genutzt, allen voran den OPSMa­na­ger, ein ungemein wertvol­ler Beglei­ter für den Anfang. Mit wachsen­dem Verständ­nis des Systems, greifen unsere Daten­bank-Adminis­tra­to­ren aber inzwi­schen lieber auf unsere eigenen Tools und Toolsets zurück, um wieder­keh­rende Aufga­ben zu automa­ti­sie­ren und das System zu adminis­trie­ren. Auf den OpsMa­na­ger können wir daher mittler­weile verzichten.

Die Kosten im Blick behalten

MongoDB ist eine OpenSo­urce-Daten­bank. Das verführt erst einmal zu der Annahme, es handelt sich um ein preis­wer­tes und auch risiko­ar­mes Projekt, wenn man auf die NoSQL-Daten­bank migriert. Tatsäch­lich gibt es neben den kosten­lo­sen Kompo­nen­ten auch Enter­prise-Services und gehos­tete Lösun­gen, für die Kosten anfallen.

Spannend wird es aber vor allem bei den Tools, die eben nicht kosten­frei sind. Diese sind gekop­pelt an Service-Verträge, so dass je nach Größe der zu verwal­ten­den Daten­bank und Menge der Zugriffe Lizenz­kos­ten im fünf- bis sechs­stel­li­gen Bereich anfallen.

Und davon können heute unsere Kunden profi­tie­ren. Wir können das Gesamt­pa­ket – Daten­bank und Adminis­tra­tion – günsti­ger betrei­ben, als es mit der Nutzung des OPSMa­na­gers möglich wäre. Je mehr Kunden wir begeis­tern können, umso besser vertei­len sich unsere Entwick­lungs­kos­ten. Auf Wunsch erhält jeder Kunde Zugriff auf diese Tools und dadurch Zugriff auf MongoDB-Instanzen.

Unabhän­gig vom Preis sind wir bei Formware natür­lich in der Lage, bei der Imple­men­tie­rung und Migra­tion zu unter­stüt­zen. Wir haben von unseren eigenen Fehlern gelernt und die Heraus­for­de­run­gen von MongoDB und von Migra­ti­ons­pro­jek­ten verstan­den. Auch diese „Lernkurve“ beinhal­tet Kosten, die in eine umfas­sende Kalku­la­tion einflie­ßen sollten. Und nicht zuletzt stehen unsere Server in Deutsch­land. Sie erfül­len alle gülti­gen Daten­schutz­be­stim­mun­gen und die ISO 27001 für Informationssicherheitsmanagement.

Keinen Blogbeitrag mehr verpassen!