Mit Version 3.2 der dokumentenorientierten NoSQL-Datenbank MongoDB werden u.a. zwei lange vermisste(?) Features eingeführt, auf die ich im Folgenden näher eingehen möchte.
Joins
Die logischen Namensräume, in denen man seine Dokumente ablegt, werden in MongoDB Collections genannt. Diese waren bislang völlig isoliert voneinander. Jeder Art von Query, Aggregation und auch MapReduce-Job operierte auf den Daten genau einer Collection.
Ab Version 3.2 kann nun im Aggregation Frameworks ein Art Fetch Join verwendet werden, um Dokumente aus anderen Collections mitzuladen. Nehmen wir an, wir haben folgendes Schema …
| customers | orders |
|---|---|
{ _id: ObjectId(...), vorname: "...", nachname: "...", ... } | { _id: ObjectId(...), customer_id: ObjectId(...), // Foreign Key zu customers total: ..., items: [ ... ], ... } |
… und wollen bei der Suche nach Kunden (customers) direkt seine Bestellungen (orders) abfragen. Dazu legen wir zunächst folgende Testdaten ein:
1db.customers.insert( {_id: "c1", vorname: "Tobias", nachname: "Trelle"} ); 2db.orders.insert( {_id:"o1", customer_id:"c1", total: 11.50, items:[{desc: "Item 1"}, {desc: "Item 2"}]} ); 3db.orders.insert( {_id:"o2", customer_id:"c1", total: 42.95, items:[{desc: "Item 2"}, {desc: "Item 3"}]} );
Den Join können wir nun mit einer neuen Pipeline-Operation $lookup des Aggregation Frameworks ausführen:
1db.customers.aggregate( [ 2 {$match: {_id:"c1"}}, 3 {$lookup: { 4 from: "orders", 5 localField: "_id", 6 foreignField: "customer_id", 7 as: "orders"} 8 } 9] )
Als Ergebnis erhält man den Kunden samt seiner Bestellungen im ge-join-ten Feld
orders:
1{ 2"_id" : "c1", 3"vorname" : "Tobias", 4"nachname" : "Trelle", 5"orders" : [ 6 { 7 "_id" : "o1", 8 "customer_id" : "c1", 9 "total": 11.5, 10 "items" : [ { "desc" : "Item 1" }, { "desc" : "Item 2" } ] 11 }, 12 { 13 "_id" : "o2", 14 "customer_id" : "c1", 15 "total" : 42.95, 16 "items" : [ { "desc" : "Item 2" }, { "desc" : "Item 3" } ] 17 } 18] 19}
Zurzeit scheinen nur Joins über ein Feld pro Collection möglich zu sein, vielleicht ändert sich das auch noch in kommenden Versionen.
Schema-Validierung
Eine grundlegende Eigenschaft der Dokumentenorientierung war in MongoDB bislang die Schema-Freiheit, d.h. die Abwesenheit einer prüfenden Instanz beim Schreiben von Dokumenten, die bestimmte Schemata erzwingt. Konkret hieß dies, dass es weder Pflichtfeld- noch Typprüfungen auf Dokumenten gab.
Nun kann auf Ebene einer Collection ein sogenannter Validator definiert werden, der bei schreibenden Operationen Typ- und sogar inhaltliche Prüfungen ausführt:
1db.createCollection("customers", { 2 validator: { 3 nachname: {$type: "string"}, 4 alter: {$type: "int", $gte: 18 } 5 } 6})
Wir definieren bestimmte erwartete Typen für die Felder nachname und alter. Das macht diese auch direkt zu Pflichtfelder. Für das Feld alter definieren wir darüber hinaus noch die Einschränkung, dass der Wert >= 18 sein muss. Hier können nahezu alle Einschränkungen definiert werden, die auch bei der Formulierung von find-Queries verwendet werden dürfen. Ein invalides Dokument wird mit folgender Meldung abgewiesen:
1db.customers.insert({_id:"c2", nachname: "Trelle", alter: NumberInt(8)}) 2WriteResult({ 3 "nInserted" : 0, 4 "writeError" : { 5 "code" : 121, 6 "errmsg" : "Document failed validation" 7 } 8})
Erst ein Alter >= 18 führt in unserem Shop-System zum gewünschten Erfolg:
1db.customers.insert({_id:"c1", nachname: "Trelle", alter: NumberInt(25)}) 2WriteResult({ "nInserted" : 1 })
Fazit
Mit den Fetch-Joins erhält man deutlich mehr Freiheit beim Schema-Design als bisher. Man ist nicht mehr so stark gezwungen, primär Query-orientiert zu planen und Daten redundant vorzuhalten. Natürlich sollte man auch jetzt im Einzelfall die Performance im Auge behalten. Joins werden auch in MongoDB nicht ohne Impact sein.
Die Schema-Validierung ist ein Feature, das die Verantwortung der Daten aus der Ebene der Applikation zurück in die Datenbank holt und somit zur (inhaltichen) Konsistenz des Datenbestandes beiträgt. Aber auch Validierung wird ein wenig Performance kosten, allerdings eher auf CPU-Ebene.
Mit diesen beiden Neuerungen macht MongoDB einen weiteren Schritt in Richtung Enterprise-Readiness. Ziel dürfte sein, weiter in Konkurrenz zu relationalen Systemen zu treten, die solche Features bereits seit Urzeiten anbieten. Man will endlich auch eine Allzweck-Datenbank werden. Ob das der Grundidee von NoSQL (nimm das passende Tool für Dein Problem) noch genügt, sein mal dahingestellt.
Alle Details und weitere neue Features können Sie den Release Notes für Version 3.2 entnehmen.
War dieser Beitrag hilfreich?
Weitere Beiträge
von Tobias Trelle
17.12.2018 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Tobias Trelle
Software Architect
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.