MongoDB — Wann eine Dokumentendatenbank Sinn ergibt

Relationale Datenbanken decken 90 % unserer Bedürfnisse ab. Aber was ist mit den restlichen 10 %? Logs, Events, flexible Formulare, Daten ohne festes Schema. Für diese Fälle haben wir MongoDB ausprobiert — und festgestellt, dass NoSQL weder Magie noch eine Bedrohung ist.

Anwendungsfall: IoT-Sensordaten¶

Jeder Sensortyp sendete andere Daten in einem anderen Format. In einer relationalen Datenbank hätten wir ein EAV-Modell oder Dutzende von Tabellen gebraucht. MongoDB ermöglicht es, ein Dokument so zu speichern, wie es ankommt.

Schema-less bedeutet nicht Schema-free¶

Der größte Mythos. Auch in MongoDB braucht man Konventionen. Ohne sie endet man mit inkonsistenten Daten — „createdDate” an einer Stelle, „created_date” an einer anderen. Wir führten Mongoose für die Schema-Durchsetzung auf der Anwendungsebene ein.

Indizes und die Aggregation Pipeline¶

db.readings.createIndex({ sensorId: 1, timestamp: -1 });
db.sensors.createIndex({ location: "2dsphere" });
db.logs.createIndex({ createdAt: 1 }, { expireAfterSeconds: 2592000 });

Die Aggregation Pipeline in MongoDB 2.6 ist überraschend leistungsfähig. GROUP BY, JOIN (Lookup), Transformationen — alles in einer einzigen Pipeline.

Wann JA, wann NEIN¶

JA: Variables Schema, hierarchische Daten, Prototyping, Geo-Abfragen. NEIN: Transaktionssysteme (ohne Multi-Document ACID), komplexes Reporting, kleine Projekte.

Das richtige Werkzeug für das richtige Problem¶

MongoDB ist kein Ersatz für eine relationale Datenbank; es ist eine Ergänzung. PostgreSQL für Transaktionsdaten, MongoDB für Sensoren und Logs. Der Schlüssel ist, sich nicht vom Hype mitreißen zu lassen.