Was ist MongoDB?

MongoDB ist eine Datenbank, die Daten als Dokumente ablegt. Ein Dokument sieht aus wie ein Datensatz in JSON, dem Format, in dem Webanwendungen ohnehin Daten austauschen: Feldname, Wert, bei Bedarf verschachtelt. Mehrere Dokumente liegen zusammen in einer Sammlung, und anders als bei einer Tabelle müssen sie nicht dieselben Felder haben. Ein Protokoll mit zwölf Messwerten liegt neben einem mit drei, und beide sind gültig.

Das ist der Kernunterschied zu relationalen Datenbanken wie MySQL oder PostgreSQL. Dort legt ihr vorab fest, welche Spalten es gibt, und jeder Datensatz muss sich daran halten. Diese Strenge ist bei zusammenhängenden Geschäftsdaten ein Schutz, bei wechselhaften Daten aber ein Korsett: Entweder entstehen Tabellen mit dreißig Spalten voller Leerwerte, oder für jede Variante eine eigene Tabelle. MongoDB löst das, indem es die feste Form einfach weglässt.

Abgefragt wird nicht mit SQL, sondern mit einer eigenen Syntax, die sich an JSON orientiert. Wer JavaScript kennt, findet sich schnell zurecht, weshalb MongoDB in Projekten mit Node.js besonders verbreitet ist: Dieselbe Datenform vom Browser über den Server bis in die Datenbank.

MongoDB läuft als Serverdienst, mit dem sich Anwendungen verbinden, genau wie bei anderen Datenbanken. Intern speichert es Dokumente in BSON, einer binären Fassung von JSON, und legt Indizes an, damit Abfragen nicht jede Sammlung komplett durchsuchen müssen. Wer auf ein Feld häufig filtert, gibt der Datenbank dafür einen Index, sonst wird es bei wachsender Datenmenge langsam. Das ist bei MongoDB nicht anders als bei MySQL.

Für Auswertungen gibt es die Aggregation Pipeline: eine Kette von Schritten, die Dokumente filtert, gruppiert und zusammenrechnet, etwa alle Protokolle eines Jahres nach Anlagentyp gezählt. Innerhalb einer Sammlung funktioniert das gut. Sobald viele Sammlungen miteinander verknüpft werden sollen, wird es umständlicher als dieselbe Aufgabe in SQL, denn das Verknüpfen über Tabellen hinweg ist genau die Disziplin, für die relationale Datenbanken gebaut wurden.

Beim Betrieb gibt es zwei Wege. Ihr könnt MongoDB auf einem eigenen Server laufen lassen, samt Sicherungen und Aktualisierungen in eigener Verantwortung. Oder ihr mietet Atlas, den Cloud-Dienst des Herstellers, der Einrichtung, Sicherung und Überwachung übernimmt und monatlich kostet. Für kleine Projekte ist Atlas oft günstiger als die Arbeitszeit, die der eigene Betrieb verschlingt. Wichtig ist dort die Wahl der Region, wenn eure Daten in der EU bleiben sollen.

MongoDB spielt seine Stärke dort aus, wo die Form der Daten offen ist oder sich noch ändert. Typische Einsatzgebiete sind:

• Produktkataloge, in denen jede Warengruppe andere Merkmale hat: Schuhe haben Größen, Farben haben Farbcodes, Kabel haben Längen
• Protokolle und Formulare, die je Typ andere Felder mitbringen, etwa Prüfberichte oder Wartungsnachweise
• Daten aus fremden Schnittstellen, die erst einmal vollständig aufgehoben werden sollen, bevor jemand sie auswertet
• Inhalte aus verschiedenen Quellen, etwa Artikel, Kommentare und Mediendaten in einer Anwendung
• Ereignis- und Sitzungsdaten, die in großer Zahl anfallen und einzeln wenig Struktur brauchen

Bei uns ist MongoDB ein Werkzeug für Teile einer Anwendung, nicht automatisch für alles. Ein Beispiel aus der Praxis: Ein Prüfdienstleister erfasst Abnahmeprotokolle, die je Anlagentyp andere Felder haben. Die Protokolle liegen als Dokumente in MongoDB, so wie sie ausgefüllt wurden, und ein neuer Anlagentyp braucht keine Änderung an der Datenbank. Kunden, Termine und Rechnungen daneben blieben in einer relationalen Datenbank, weil sie feste Form haben und verknüpft ausgewertet werden. Diese Arbeitsteilung ziehen wir in Webanwendungen und Apps regelmäßig durch.

MongoDB entstand bei 10gen, einem New Yorker Startup, das ab 2007 eigentlich eine komplette Cloud-Plattform bauen wollte. Die Plattform fand kaum Abnehmer, ihre Datenbank dagegen schon, und so veröffentlichte 10gen sie 2009 als eigenständiges Produkt. Der Name kommt von humongous, dem englischen Wort für riesig. Die Firma benannte sich später selbst in MongoDB Inc. um und lebt heute vom Cloud-Dienst Atlas und von Support-Verträgen.

Die Freiheit beim Speichern hat eine Kehrseite: Die Datenbank zwingt euch keine Struktur auf, also müsst ihr selbst dafür sorgen, dass keine drei Schreibweisen desselben Feldes entstehen. Was eine Tabelle per Definition verhindert, wird hier zur Disziplinfrage im Team. Dazu kommen weitere Punkte:

• Verknüpfte Auswertungen über viele Sammlungen sind mühsamer als in SQL, Berichte werden dadurch teurer in der Entwicklung
• Prüfregeln, die relationale Datenbanken mitbringen, etwa dass eine Bestellung immer einen gültigen Kunden braucht, müssen in der Anwendung nachgebaut werden
• WordPress, Shopware und ähnliche Systeme laufen nicht auf MongoDB, sie setzen relationale Datenbanken voraus
• Die Lizenz schränkt den Weiterverkauf als Dienst ein, was für den eigenen Einsatz egal ist, bei Produktideen aber geprüft gehört

Nichts davon spricht gegen MongoDB am richtigen Ort. Es spricht nur dagegen, MongoDB zu wählen, weil der Name moderner klingt als MySQL.

Die ehrliche Antwort beginnt mit einem Blick auf die eigenen Daten. Haben sie feste Form und hängen sie zusammen, gewinnt die relationale Datenbank. Sind sie wechselhaft und stehen für sich, gewinnt das Dokument. Als Orientierung:

• Kunden, Aufträge, Rechnungen, Zahlungen: relational, weil Verknüpfungen und Prüfregeln hier den Kern der Sache ausmachen
• Protokolle, Kataloge mit wechselnden Merkmalen, Rohdaten aus Schnittstellen: MongoDB, weil jedes Dokument so bleiben darf, wie es entstand
• Berichte als Hauptzweck der Anwendung: relational, am ehesten PostgreSQL, weil SQL für Auswertungen gebaut ist
• Beides im selben Projekt: kein Widerspruch, viele Anwendungen nutzen eine relationale Datenbank für den Kern und Dokumente für den wechselhaften Rand

Erwähnenswert ist noch ein Mittelweg: PostgreSQL kann JSON-Dokumente speichern und darin suchen. Wer nur an einer Stelle freie Formate braucht, kommt damit oft ohne zweite Datenbank aus. MongoDB lohnt sich dann, wenn Dokumente nicht die Ausnahme sind, sondern die Regel.

Als Auftraggeber merkt ihr die Datenbankwahl nicht an der Oberfläche, sondern an zwei Stellen: bei Änderungen und bei Berichten. Ändert sich euer Geschäft, etwa ein neuer Protokolltyp oder eine neue Warengruppe mit eigenen Merkmalen, ist MongoDB im Vorteil, weil kein Umbau der Datenbank ansteht. Wollt ihr dagegen im nächsten Quartal einen Bericht über alles, was zusammenhängt, zahlt ihr bei einer reinen Dokumentenlösung drauf, weil solche Auswertungen dort Handarbeit sind.

Bei den laufenden Kosten gilt: Die Software selbst kostet im eigenen Betrieb nichts, Atlas kostet monatlich nach Größe und Last. Wichtiger als der Preis ist die Frage der Zuständigkeit, denn eine Datenbank ohne geprüfte Sicherung ist ein Risiko, egal welcher Bauart. Wer beauftragt, sollte deshalb fragen, warum genau diese Datenbank gewählt wurde und wer die Sicherungen prüft. Unsere Antworten dazu stehen auf der Seite zur MongoDB-Entwicklung.

MongoDB ist der Zukunftsdebatte längst entwachsen. Vor zehn Jahren galt NoSQL manchen als Ablösung der Tabellen, heute ist klar: Es war eine Ergänzung. Die relationalen Datenbanken haben dazugelernt und JSON aufgenommen, die Dokumentendatenbanken haben Transaktionen und Prüfmöglichkeiten nachgerüstet. Beide Welten sind sich entgegengekommen, und beide bleiben.

Für MongoDB selbst spricht, dass eine börsennotierte Firma mit zahlenden Kunden dahintersteht und die Datenbank seit über fünfzehn Jahren gepflegt wird. Das Werkzeug verschwindet nicht. Die Frage ist nur je Projekt neu zu stellen: Passt das Dokument zu euren Daten, oder passt die Tabelle? Wer sie ehrlich beantwortet, statt einem Trend zu folgen, fährt in beide Richtungen gut. Eine ähnliche Abwägung gilt übrigens bei Firestore, der Dokumentendatenbank von Google, die den Betrieb gleich mit übernimmt.