Erste Schritte mit MongoDB für SQL-Umsteiger

Jede neue Datenbank erfordert einen neuen Lernschritt: Befehle und teilweise auch die Syntax sind trotz aller Standartisierung von SQL über ein klein wenig anders, aber im Allgemeinen findet man sich schnell zurecht - zumindest, wenn der Umstieg von einer SQL-Datenbank auf eine andere erfolgt. Bei NoSQL reicht es dagegen nicht aus, einfach ein paar neue Befehle zu lernen.

Der größte Schritt beim Umstieg ist ein gedanklicher Abschied von vertrauten SQL-Denkmustern, besser gesagt: Relationalen Denkmustern. Einige Beispiele habe ich im letzten Teil bereits angedeutet.

Ein sehr guter Einstiegspunkt ist das MongoDB-Tutorial: Auf http://try.mongodb.org/ findet sich eine MongoDB-Konsole mit einem interaktiven Tutorial. Schritt für Schritt führt es einen in etwa 15 Minuten in die Welt von MongoDB ein und zeigt, wie einfach diese NoSQL-Datenbank zu benutzten. JavaScript-Vorkenntnisse sind dabei ganz klar von Vorteil, notfalls geht es aber auch ohne.

Der MongoDB-Client lässt sich auf fast jedem Linuxsystem installieren, wird die Datenbank selbst installiert, kommt er bereits mit. Aufgerufen wird er einfach mit dem Befehl mongo. Dahinter kann optional der Name des Datenbankservers angegeben werden. Wird nichts angegeben, verbindet er sich mit einem MongoDB-Server auf dem gleichen Computer.

$ mongo
MongoDB shell version: 2.4.1
connecting to: test
> show dbs
cachedb 0.203125GB
default 0.203125GB
local 0.078125GB
test 0.203125GB

Die gewünschte Datenbank wird genau wie bei MySQL mittels use ausgewählt. Bei allen folgenden Befehlen wird an Stelle der Datenbank üblicherweise das Kürzel db verwendet:

> use test
switched to db test
> show collections
system.indexes
testcol
> db.getCollectionNames()
[ "system.indexes", "testcol" ]

Die Datenbank test hat neben dem Strukturspeicher system.indexes noch eine Collection namens testcol. Die Befehle show collections und db.getCollectionNames() sind identisch, lediglich die Ausgabe unterscheidet sich.

Eine neue Collection muss nicht explizit erstellt werden - sie wird mit dem ersten Schreibzugriff automatisch ins Leben gerufen. Da NoSQL-Datenbanken keine festen Strukturvorgaben kennen, ist auch keine weitere Definition nötig und die bei vielen MySQL-basierten Projekten bekannten und gefürchteten SQL-Dateien mit der vor der Nutzung eines Tools dessen Tabellenstruktur erstellt werden muss, entfallen vollständig. Das gleiche gilt auch für Datenbanken, die ebenfalls mit dem ersten Schreibzugriff automatisch erstellt werden.

Als Beispiel soll eine neue Collection dienen, die technische Daten verschiedener Flugzeuge erfasst:

> db.flugzeuge.insert({brand: "Airbus", model: "A380", passengers: 853, fuel: "Jet-A1", engine: ['GP7270','GP7270','GP7270','GP7270']})
> db.flugzeuge.insert({brand: "Transall", model: "C-160", freight: 16000, fuel: "Jet-A1", engine: ['Rolls-Royce-Tyne-Mk.22','Rolls-Royce-Tyne-Mk.22']})
> db.flugzeuge.insert({brand: "Cessna", model: "172", seats: 4, fuel: "AVGAS 100LL", engine: 'O-320'})

Drei sehr unterschiedliche Flugzeuge landen in der Collection: Ein Passagier-Linienflugzeug, ein militärisches Frachtflugzeug und ein Kleinflugzeug. Während Hersteller, Modellbezeichnung und Treibstoffart bei allen drei Elementen vorhanden sind, wurden die verbleibenden Felder dem jeweiligen Flugzeugtyp angepasst. Der A380 hat eine große Passagierkapazität während bei der Transall eher die Frachtleistung relevant ist. Die Cessna hat dagegen 4 Sitze von denen ein bis zwei auf Piloten entfallen - die Angabe "3 Passagiere" oder "4 Passagiere" wäre hier ungenau.

Bei den Triebwerken kommt der Unterschied zu einer SQL-Datenbank noch deutlicher zum tragen: Während die mehrmotorigen Maschinen jeweils eine Liste der verbauten Triebwerke enthalten, in Flugrichtung gesehen von links nach rechts gespeichert, gibt es bei der einmotorigen Cessna keinen Grund für ein Triebwerks-Array. Bei einem Segelflugzeug könnte dieser Schlüssel auch komplett entfallen.

Die Abfrage erfolgt über die Methode find() der Collection:

> db.flugzeuge.find()
{ "_id" : ObjectId("52d571706953a4139a6160ba"), "brand" : "Airbus", "model" : "A380", "passengers" : 853, "fuel" : "Jet-A1", "engine" : [ "GP7270", "GP7270", "GP7270", "GP7270" ] }
{ "_id" : ObjectId("52d571e56953a4139a6160bb"), "brand" : "Transall", "model" : "C-160", "freight" : 16000, "fuel" : "Jet-A1", "engine" : [ "Rolls-Royce-Tyne-Mk.22", "Rolls-Royce-Tyne-Mk.22" ] }
{ "_id" : ObjectId("52d572346953a4139a6160bc"), "brand" : "Cessna", "model" : "172", "seats" : 4, "fuel" : "AVGAS 100LL", "engine" : "O-320" }

Alle drei Dokumente werden angezeigt, jedoch nur mit den tatsächlich existierenden Schlüsseln. Bei der Cessna gibt es kein Frachtvolumen und der A380 hat keine Gesamtzahl der verfügbaren Sitze. Jedes Dokument hat allerdings vom Server eine eindeutige ID erhalten, die immer zwangsweise indiziert und damit schnell auffindbar ist.

Jedes Objekt in der MongoDB-Shell kennt übrigens die Methode .help() mit der sich alle an dieser Stelle erlaubten Methoden mit einem kurzen Hilfetext anzeigen lassen.