NoSQL und MongoDB — ein praktischer Einsatz

Relationale Datenbanken sind seit Jahrzehnten das Rückgrat der Enterprise-IT. Aber was, wenn Ihre Daten kein festes Schema haben? Was, wenn Sie horizontale Skalierbarkeit ohne Oracle-Lizenz brauchen? MongoDB 2.6 war gerade erschienen und wir haben es in Produktion eingesetzt. Hier sind unsere Erfahrungen.

Warum wir zu MongoDB gegriffen haben¶

Unser Kunde — ein mittelgroßer E-Commerce-Anbieter — hatte mit einem klassischen Problem zu kämpfen: ein Produktkatalog mit Tausenden von Attributen, die sich von Kategorie zu Kategorie unterschieden. In MySQL bedeutete das entweder ein EAV-Modell (langsam, komplex) oder Hunderte von Spalten voller NULL-Werte. Keine der beiden Varianten war tragbar.

MongoDB bot ein Dokumentenmodell, bei dem jedes Produkt einen anderen Satz von Attributen haben konnte. Kein ALTER TABLE, keine Migrationen. Neues Attribut hinzufügen? Einfach ins Dokument schreiben. Für Katalog-Anwendungsfälle war das ein Game Changer.

Deployment-Architektur¶

Wir setzten MongoDB 2.6 in einer Replica-Set-Konfiguration ein — drei Knoten, ein Primary und zwei Secondaries. Für unser Datenvolumen (etwa 50 GB) war Sharding nicht nötig, aber die Architektur war für zukünftiges Wachstum vorbereitet.

# NoSQL und MongoDB — ein praktischer Einsatz
mongod --replSet rs0 --port 27017 --dbpath /data/db1
mongod --replSet rs0 --port 27018 --dbpath /data/db2
mongod --replSet rs0 --port 27019 --dbpath /data/db3

# Initialisation
rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongo1:27017" },
    { _id: 1, host: "mongo2:27018" },
    { _id: 2, host: "mongo3:27019" }
  ]
})

Die Anwendungsschicht lief auf Node.js mit Mongoose ODM. Die Wahl von Node.js war kein Zufall — JSON rein, JSON raus, keine Impedance Mismatch zwischen Anwendung und Datenbank. 2014 ist diese Kombination noch relativ frisch, funktioniert aber überraschend gut.

Datenmodell — Dokumente statt Tabellen¶

Der größte mentale Umbruch für ein Team, das an relationale Datenbanken gewöhnt ist: Denormalisierung ist OK. In MongoDB machen wir keine JOINs — stattdessen betten wir zusammengehörige Daten direkt ins Dokument ein.

Ein Produktdokument sah ungefähr so aus: Name, Beschreibung, Preis, Kategorie, ein Array von Varianten (jede mit eigenem Preis und Lagerbestand), eingebettete Bewertungen und Metadaten. Eine einzige Abfrage lieferte alles, was das Frontend brauchte. Keine JOINs über fünf Tabellen.

Natürlich gibt es Kompromisse. Wenn sich ein Kategoriename ändert, muss er in allen Produkten aktualisiert werden. Aber für einen leseintensiven E-Commerce-Workload war das ein akzeptabler Kompromiss.

Indexierung — der Schlüssel zur Performance¶

MongoDB ohne richtige Indizes ist langsam. Sehr langsam. Das haben wir auf die harte Tour gelernt. Unser erstes Deployment hatte Antwortzeiten über 500 ms bei einfachen Abfragen. Nach einer Analyse mit explain() stellten wir fest, dass MongoDB Full Collection Scans durchführte.

• Compound-Indizes — Kombinationen von Feldern, die am häufigsten gemeinsam abgefragt werden
• Text-Indizes — für Volltextsuche im Katalog (neu in 2.6)
• TTL-Indizes — automatische Löschung von Session-Daten nach Ablauf
• Sparse-Indizes — für Felder, die nur in einem Teil der Dokumente existieren

Nach korrekter Indexierung erreichten wir Antwortzeiten unter 10 ms. Der Unterschied war dramatisch. Die Lektion: MongoDB sagt Ihnen nicht, dass ein Index fehlt. Sie müssen aktiv überwachen und profilieren.

Was uns positiv überrascht hat¶

Entwicklungsgeschwindigkeit. Ohne die Notwendigkeit, ein Schema vorab zu definieren, iterierten wir viel schneller. Ein neues Feature, das ein neues Feld erfordert? Einfach anfangen zu schreiben. Kein ALTER TABLE, keine Migrationen, kein Warten auf den DBA.

Aggregation Framework. MongoDB 2.6 brachte eine verbesserte Aggregation Pipeline, die die meisten analytischen Abfragen abdeckte, die wir zuvor mit komplexem SQL gelöst hatten. Pipeline-Stufen wie $match, $group, $unwind und $project sind intuitiv.

Replica-Set-Failover. Wir simulierten den Ausfall des Primary-Knotens. Die Wahl eines neuen Primary war in 12 Sekunden abgeschlossen. Die Anwendung leitete Schreibvorgänge automatisch um. Kein manueller Eingriff erforderlich.

Was wehtut¶

Keine Transaktionen. MongoDB unterstützt 2014 keine Multi-Document-Transaktionen. Für den Bestellprozess — bei dem man atomisch den Lagerbestand reduzieren und eine Bestellung erstellen muss — mussten wir das Two-Phase-Commit-Pattern von Hand implementieren. Komplex und fragil.

Write-Concern-Fallstricke. Die standardmäßige Write Concern im Treiber war „Fire and Forget”. Ohne explizites Setzen von w:majority konnte man bei einem Failover Daten verlieren. Die Dokumentation erwähnte dies, aber nicht deutlich genug.

Memory-Mapped Storage Engine. MongoDB nutzt mmap für die Speicherung. Auf einem Server mit 64 GB RAM und 50 GB Daten funktionierte das großartig. Aber sobald das Working Set den RAM überstieg, fiel die Performance dramatisch ab. Die WiredTiger Engine verspricht Verbesserungen, ist aber noch experimentell.

Wann MongoDB ja, wann nein¶

Nach sechs Monaten im Produktivbetrieb haben wir ein klares Bild:

• Ja: Produktkataloge, CMS, Echtzeit-Analytik, Session Storage, IoT-Daten, Prototyping
• Nein: Finanztransaktionen, Systeme mit komplexen JOINs, Reporting mit komplexen Beziehungen
• Es kommt darauf an: Benutzerverwaltung (einfache Profile ja, komplexe Rollen/Berechtigungen eher relationale DB)

MongoDB im Enterprise-Umfeld — mit Bedacht¶

MongoDB ist kein Ersatz für PostgreSQL oder Oracle. Es ist ein Werkzeug für bestimmte Anwendungsfälle, bei denen das Dokumentenmodell Sinn ergibt. Setzen Sie es dort ein, wo das relationale Modell knirscht — und lassen Sie relationale Datenbanken dort, wo sie glänzen. Polyglot Persistence ist kein Buzzword. Es ist Pragmatismus.