MongoDB

{
       "name": "MongoDB",
       versionen: [
            { "major": 2, "minor": 6 },
            { "major": 2, "minor": 4 },
            { "major": 2, "minor": 2 }
       ]
}

Abb. 1–2 Veranschaulichung des CAP-Theorems

a. http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf

Die Auswirkungen des CAP-Theorems lassen sich gut an einem System veranschaulichen, das aus zwei Knoten besteht (s. Abb. 1–2). Das Netzwerk zwischen diesen Knoten soll gestört sein, sodass eine Partition des Systems in zwei Teile vorliegt, die sich gegenseitig nicht mehr erreichen können.

Erlaubt man nun einem der Knoten, seinen Zustand zu ändern (also im Falle eines Datenbanksystems schreibende Operationen auszuführen), wird das Gesamtsystem inkonsistent, man gibt also C auf. Will man die Konsistenz erhalten, muss der Knoten, dessen Zustand sich nicht ändert, sich als nicht verfügbar »abmelden« (da er sonst gegenüber den Clients einen nicht aktuellen Datenbestand ausliefern würde), womit man die Verfügbarkeit (A) des Systems auf nur noch einen Knoten reduziert. Nur wenn alle Knoten stets miteinander kommunizieren können, kann man dauerhaft C und A aufrecht erhalten, was dann offenbar im Widerspruch zu P steht.

Relationale Datenbanksysteme fallen in der Regel in die CA-Kategorie, da sie großen Wert auf die Konsistenz legen und auch hohe Verfügbarkeiten garantieren. Bei Systemen, die nur auf einem Knoten laufen, kann die Ausfallsicherheit durch den Kauf sehr teurer Hardware ebenfalls nah an die 100% gebracht werden. Fällt der eine Knoten aus, ist das System aber nicht mehr verfügbar. Bei Datenbank-Clustern verringert sich die Verfügbarkeit, da die Transaktionen zur Sicherstellung der Konsistenz auf mehreren Knoten eine längere Laufzeit haben.

Bei vielen NoSQL-Datenbanken kann man aufgrund der hohen Verteilung nicht auf die Partition Tolerance (P) verzichten. Da die Verfügbarkeit (A) ebenfalls einen sehr hohen Stellenwert einnimmt (da man grundsätzlich alle Anfragen an das System beantworten können möchte), bleibt nur der Ausweg, an der Konsistenz (C) zu sparen. Dies ist dann aber eine bewusste Design-Entscheidung beim Entwurf dieser Systeme und nicht dem Unwillen oder der Vergesslichkeit der Entwickler geschuldet.

Sie als Anwender solcher Technologien sollten sich aber stets bewusst sein, dass Sie sich nicht mehr auf Ihre bisherigen Konsistenzzusagen verlassen können!

1.5 ACID vs. BASE

Das ACID⁵-Prinzip, das Sie von relationalen Datenbanksystemen gewohnt sind, stellt in Zusammenhang mit Transaktionen⁶ Folgendes sicher:

• Atomicity (Atomarität):

  Eine Transaktion wird nach dem Alles-oder-nichts-Prinzip entweder vollständig oder gar nicht ausgeführt. Wird eine atomare Transaktion abgebrochen, ist das System in einem unveränderten Zustand.

• Consistency (Konsistenz):

  Eine Folge von Datenbankoperationen führt wieder zu einem konsistenten Zustand, sofern das System zuvor schon in einem konsistenten Zustand war. Hier bezieht sich die Konsistenz vorwiegend auf die inhaltliche und referenzielle Integrität⁷ des Datenbestandes.

• Isolation:

  Nebenläufig ausgeführte Transaktionen beeinflussen sich nicht gegenseitig.

• Durability (Dauerhaftigkeit):

  Die Auswirkungen von Transaktionen müssen dauerhaft im System gespeichert werden, insb. auch bei Systemabstürzen.

Bitte beachten Sie, dass der Konsistenzbegriff aus dem CAP-Theorem und dem ACID-Prinzip nicht identisch sind, sondern sich auf verschiedenen Granularitätsebenen bewegen.

NoSQL-Datenbanken können (oder wollen) eine Konsistenz im Sinne des ACID-Prinzips oft nicht garantieren, gewährleisten dann aber einen anderen Grad an Konsistenz. Hier kommt der Begriff BASE⁸ ins Spiel:

• Basically Available
• Soft State
• Eventual Consistency

Dieses zugegebenermaßen sehr konstruiert wirkende Akronym will den Gegensatz zu ACID (im Englischen Säure) und BASE (Lauge) aus der Chemie aufgreifen. Die beiden Begriffe Basically Available und Soft State sind nicht präzise definiert, greifen aber nach meiner Interpretation die Verfügbarkeit (A) des CAP-Theorems auf.

Unter Eventual Consistency wird relativ klar das C des CAP-Theorems adressiert, und zwar in dem Sinne, dass das verteilte System (nach einer möglichst kurzen Zeitspanne der Inkonsistenz) letztendlich wieder in einem konsistenten Zustand ist.

Die letztendliche Konsistenz möchte ich an einem konkreten Beispiel mit zwei Knoten erläutern. Schreibzugriffe sind nur an einem der Knoten, den wir Master nennen, erlaubt. Der Master repliziert den Datenbestand in regelmäßigen Abständen an den anderen Knoten, den wir Slave nennen. Lesezugriffe sind an beiden Knoten erlaubt. Nach einem Schreibvorgang auf dem Master sehen Clients, die vom Slave lesen, die neuen oder geänderten Daten nicht sofort. Erst nach Abschluss der Replikation, die ggf. asynchron arbeitet, ist der Slave wieder auf dem aktuellen Stand.

Mit MongoDB können Sie keine Transaktionen fahren, die mehr als ein Dokument umfassen. Selbst bei Operationen auf nur einem Dokument ist kein explizites Rollback möglich. Immerhin sind Änderungen an einem Dokument aber atomar im Sinne des ACID-Prinzips. Da Sie ganze Objektnetze in einem Dokument unterbringen können, sind dokumentenübergreifende Transaktionen oft auch gar nicht notwendig.

1.6 Zusammenfassung

In dieser Einleitung haben Sie die Herausforderungen kennengelernt, die es im Big-Data-Umfeld zu meistern gilt. Sie haben ferner die Grundidee hinter der NoSQL-Bewegung verstanden und wissen, dass Sie insbesondere bei der Konsistenz umdenken müssen, wenn Sie MongoDB einsetzen.

Was Sie dabei beachten müssen, damit Sie dennoch keine Daten verlieren, werde ich Ihnen im Rest des Buches zeigen. Lassen Sie uns also jetzt direkt durchstarten in die Welt abseits des relationalen Pfades, in eine Welt ohne ACID, in die Welt von MongoDB ...

Fußnoten

Kapitel 1

Kapitel 2

Kapitel 3

Kapitel 4

Kapitel 5

Kapitel 6

Kapitel 7

Kapitel 8

Kapitel 9

Kapitel 10

Kapitel 11

2 MongoDB in 21 Minuten

In diesem Kapitel zeige ich Ihnen, wie schnell Sie einen MongoDB-Server installieren, starten und benutzen können. Sie werden Testdaten importieren und Ihre ersten Abfragen absetzen.

2.1 Installation

Die jeweils aktuelle Version von MongoDB kann auf der Homepage heruntergeladen werden: http://www.mongodb.org/downloads. Sie sollten die stabile Produktionsversion verwenden. Ich werde die Installation exemplarisch für Windows durchführen, Anleitungen für andere Betriebssysteme können Sie der Online-Dokumentation¹ entnehmen.

Nachdem die passende Archivdatei heruntergeladen ist, entpacke ich den Inhalt in ein Verzeichnis meiner Wahl, z. B. C:\nosql. Dort befindet sich nun ein neues Verzeichnis, dessen Name mit mongodb gefolgt von Betriebssystem- und Versionsinfos beginnt, z. B.:

c:\nosql\mongodb-win32-x86_64-2008plus-2.x

Auf dieses Verzeichnis werde ich mich im Folgenden als MONGO_HOME beziehen.

2.2 Server starten

Um den Server-Prozess zu starten, öffnen Sie eine Kommandozeilen-Shell und wechseln in das Verzeichnis MONGO_HOME\bin. Dort befinden sich alle ausführbaren Programme, die wir zum Betrieb und zur Administration eines MongoDB-Systems benötigen. Zunächst müssen wir noch ein neues Verzeichnis anlegen, in dem MongoDB seine Daten speichert:

rem Windows
mkdir \data

# Unix
mkdir /data

Anschließend starten wir den Server mit

mongod --dbpath /data

Auf der Konsole sollten nun in etwa folgende Log-Ausgaben zu sehen sein:

Sat Dec 01 14:15:40 [initandlisten] MongoDB starting : pid=5616 port=27017
dbpath=/data 64-bit host=localhost
Sat Dec 01 14:15:40 [initandlisten] db version v2.x, pdfile version 4.5
Sat Dec 01 14:15:40 [initandlisten] git version:
f5e83eae9cfbec7fb7a071321928f00d1b0c5207
Sat Dec 01 14:15:40 [initandlisten] build info: windows
sys.getwindowsversion(major=6, minor=1, build=7601, platform=2,
service_pack='Service Pack 1') BOOST_LIB_VERSION=1_49
Sat Dec 01 14:15:40 [initandlisten] options: { dbpath: "/data", rest: true }
Sat Dec 01 14:15:40 [initandlisten] journal dir=/data/journal
Sat Dec 01 14:15:40 [initandlisten] recover : no journal files present, no
recovery needed
Sat Dec 01 14:15:40 [initandlisten] waiting for connections on port 27017

Ohne weitere Konfiguration verwendet ein MongoDB-Server als Default den TCP/IP-Port 27017 für eingehende Verbindungen. Wenn Sie den Server mit der Kommandozeilenoption

$ mongod --httpinterface --rest

starten, können Sie 1000 Ports höher, also unter folgender URL:

http://localhost:28017

eine einfache, HTML-basierte Administrationsoberfläche erreichen (s. Abb. 2–1)

Abb. 2–1 Interface zur Administration

Dort finden sich Informationen über verbundene Clients, Datenbankoperationen und aufgetretene Locks, auf die wir im weiteren Verlauf des Buchs näher eingehen werden.

2.3 Mongo Shell

Im weiteren Verlauf werden wir die sogenannte Mongo Shell verwenden. Dabei handelt es sich um einen Kommandozeilen-Client, mit dem wir den Server administrieren und auch Daten manipulieren können.

Als Benutzer erhalten Sie einen Prompt, auf dem Sie JavaScript²-Befehle und -Skripte ausführen können. Dabei können Sie auf eine Reihe bestehender Java-Script-Objekte zugreifen, die jeweils bestimmte Datenbankkonstrukte repräsentieren. Aus Sicht des Servers verhält sich die in C++ implementierte Mongo Shell wie jeder andere Datenbank-Client.

Gestartet wird das Ganze im Verzeichnis MONGO_HOME/bin:

$ mongo3

Da der zuvor gestartete Server auf dem Standardport 27017 horcht, müssen wir keine weiteren Verbindungsparameter angeben. Danach werden wir von der Mongo Shell wie folgt begrüßt:

MongoDB shell version: 2.x
connecting to: test
>

Wenn wir beim Start der Mongo Shell keinen Namen einer Datenbank angeben, verwenden wir standardmäßig eine zunächst leere Datenbank namens test. Setzen Sie zum Einstieg ein paar einfache JavaScript-Befehle ab:

> var a = 2
> b = a + 2
4
> for (i=0; i<5; i++) { print(i) }
0
1
2
3
4

2.4 Erste Schritte

Ein MongoDB-Server verwaltet mehrere logische Datenbanken. Einen Überblick über alle Datenbanken verschaffen wir uns mit dem Befehl

> show dbs
local 0.078125GB

In einem frisch aufgesetzten System sehen wir nur die stets existierende Datenbank local.

Eine Übersicht über weitere Befehle erhalten Sie mit dem Kommando help().

2.4.1 Collections

Einzelne Datensätze, die in MongoDB Dokumente heißen, werden innerhalb logischer Namensräume organisiert, den sogenannten Collections. Eine Collection entspricht in etwa einer Tabelle aus einem relationalen Datenbanksystem, ist aber nicht identisch damit. Collections müssen nicht explizit angelegt werden, sie werden bei der ersten Verwendung automatisch erzeugt. In unserer Datenbank test gibt es zunächst noch keine Collections:

> show collections
>

2.4.2 Dokumente

Dokumente werden innerhalb der Mongo Shell im JSON⁴-Format repräsentiert. Das JSON-Format ist ein leichtgewichtiges, textbasiertes Format, in dem man ein Objekt gut lesbar darstellen kann, z. B.:

> doc = { hello: "MongoDB" }

Im obigen Beispiel ist doc ein Dokument mit einem Feld namens hello, das den String-Wert "MongoDB" hat.

Wir werden in Kapitel 3 noch genauer auf Collections und Dokumente eingehen.

2.4.3 CRUD-Operationen

Ich werde nun in der Collection dokumente einige Dokumente speichern, manipulieren und suchen. Mit

> db.dokumente.insert( doc )
> db.dokumente.insert( {a: 1, b: "zwei" } )
> db.dokumente.insert( {a: 2, b: "drei" } )

ist das Speichern bereits erledigt. Das JavaScript-Objekt db repräsentiert in der Mongo Shell die aktuell selektierte Datenbank. Collections werden automatisch zu Attributen dieses Datenbankobjekts und sind daher über den Ausdruck db.name oder db["name"] zugreifbar. Mit dem ersten schreibenden Zugriff auf die Collection dokumente wurde diese angelegt, wie die Auflistung aller Collections nun zeigt:

> show collections
dokumente
system.indexes

Mit db.dokumente.help() erhalten Sie Hilfe zu den Befehlen der Collection.

Neben unserer Collection dokumente ist auch eine weitere Collection system. indexes entstanden, die Informationen über Indizes enthält (mehr dazu in Kap. 6). Wir können nun die zuvor eingefügten Dokumente z. B. zählen oder auch suchen:

> db.dokumente.count()
3
> db.dokumente.find()
{ "_id" : ObjectId("50ba1112b9b2400412cbe6bd"),
    "hello" : "MongoDB" }
{ "_id" : ObjectId("50ba1112b9b2400412cbe6be"),
    "a" : 1, "b" : "zwei" }
{ "_id" : ObjectId("50ba112eb9b2400412cbe6bf"),
    "a" : 2, "b" : "drei" }

Dabei fällt auf, dass beim Schreiben ein Feld _id erzeugt wurde, mit dem das Dokument eindeutig identifiziert werden kann. Das Feld _id wird automatisch ergänzt, wenn Sie es nicht selbst angeben.

Da man oft nicht an allen Dokumenten innerhalb einer Collection interessiert ist, kann man der Methode find(...) Suchkriterien und Feldgruppen in Form von Dokumenten mitgeben, um die Treffermenge einzuschränken, z. B.:

> db.dokumente.find( {a: 2}, {_id: 0} )
{ "a" : 2, "b" : "drei" }

In diesem Beispiel schränken wir mit dem ersten Parameter {a: 2} die Menge der gefundenen Dokumente auf solche ein, bei denen das Feld a den Wert 2 besitzt. Mit dem optionalen zweiten Parameter schränken wir die Menge der zurückgelieferten Felder innerhalb eines Dokuments ein, indem wir für Felder, die wir ignorieren möchten, eine 0 angeben. (In SQL würden Sie an dieser Stelle eine konkrete Spaltenliste anstatt von * beim SELECT angeben.)

Neben dem einfachen Feldvergleich auf Identität gibt es noch viele weitere sog. Query-Operatoren, die ich ausführlich in Kapitel 6 erklären werde.

Im Gegensatz zu relationalen Datenbanken kann ein einzelnes Feld eines Dokuments aber auch Arrays oder eingebettete Unterobjekte enthalten:

> db.autoren.insert( {
    titel: "MongoDB: Ein praktischer Einstieg",
    autoren:[
        {name: "N.N."},
        {name: "Tobias Trelle"}
    ]
} )

Eine anschließende Suche mit Formatierung macht die Struktur deutlicher:

> db.autoren.find().pretty()
{
"_id" : ObjectId("50ba1bafb9b2400412cbe6c0"),
"titel" : "Praxisbuch MongoDB",
"autoren" : [
    {
    "name" : "N.N"
    },
    {
    "name" : "Tobias Trelle"
    }
]
}

Wenn wir nun ein bestimmtes Objekt verändern wollen, können wir die Methode update(...) verwenden:

> db.dokumente.update( {a: 2}, {b: "vier"} )

Intuitiv würde man nun vielleicht vermuten, dass im Dokument mit a = 2 der Wert für b auf "vier" gesetzt wurde. Dies ist aber nicht der Fall, wie eine anschließende Suche zeigt (mit leerem Suchkriterien-Dokument {} werden alle Dokumente gefunden):

> db.dokumente.find({}, {_id: 0})
{ "a" : 1, "b" : "zwei" }
{ "b" : "vier" }

Die Semantik der update(...) -Methode ist so, dass der zweite Parameter (hier {b: "vier"}) das bestehende Dokument vollständig ersetzt und nicht nur die darin vorkommenden Fehler manipuliert!

Partielle Updates und noch einiges mehr sind aber dennoch möglich und werden in Kapitel 7 ausführlich behandelt.

Einzelne Dokumente werden mit remove(...) gelöscht:

> db.dokumente.remove( {a: 1} )
> db.dokumente.find({}, {_id: 0})
{ "b" : "vier" }

Um alle Dokumente einer Collection zu löschen, ruft man remove() ohne Parameter auf. Dies kann bei großen Datenmengen sehr lange dauern, da jedes Dokument einzeln gelöscht wird, was z. B. auch eine Aktualisierung von Indizes auslösen kann. Schneller ist man hier mit:

> db.dokumente.drop()
true
> show collections
system.indexes

Mit drop() wird die Collection vollständig gelöscht, inklusive aller bestehenden Indizes.

2.5 Daten importieren

Die bisherigen Beispiele mögen Ihnen zu Recht trivial vorkommen. Im weiteren Verlauf des Buchs werden wir auf eine größere und komplexere Datenmenge zurückgreifen. Es handelt sich um einen Auszug aus öffentlich zugänglichen Tweets der Twitter-Plattform. Diese Daten können Sie von

https://github.com/ttrelle/mongodb-buch/blob/master/data/tweets.zip?raw=true

herunterladen und ins Verzeichnis MONGO_HOME entpacken. Der Inhalt des Archivs ist eine Datei im BSON-Format, die gut 50.000 Dokumente beinhaltet, die wir gleich in eine Collection einspielen werden.

Beenden Sie dazu nun die Mongo Shell mit dem Befehl exit. Anschließend rufen Sie im Verzeichnis MONGO_HOME\bin den folgenden Befehl auf, um die Daten in eine Datenbank namens twitter in eine Collection namens tweets zu importieren:

$ mongorestore -d twitter../tweets.bson
connected to: 127.0.0.1
2014-02-27T08:30:07.181+0100 tweets.bson
2014-02-27T08:30:07.185+0100    going into namespace [twitter.tweets]
2014-02-27T08:30:07.187+0100 tweets.metadata.json not found. Skipping.
2014-02-27T08:30:10.002+0100          Progress: 76560817/85711256     89%
(bytes)
53641 objects found

Die Ausführungszeit des Importvorgangs kann in Abhängigkeit von Ihrem System variieren. Sobald die Daten importiert sind, rufen wir wieder die Mongo Shell auf und wechseln in die Twitter-Datenbank, um uns die Anzahl der Tweets anzuzeigen:

$ mongo
MongoDB shell version: 2.x
connecting to: test
> use twitter
switched to db twitter
> show collections
system.indexes
tweets
> db.tweets.count()
53641

Wenn wir nun mittels

> db.tweets.find()

nach allen importierten Tweets suchen, gibt die Mongo Shell einen Wust von Dokumenten aus. Die Anzahl der angezeigten Dokumente wird per Default auf 20 beschränkt. Diese Anzahl wird bestimmt durch:

> DBQuery.shellBatchSize
20

Um die jeweils nächste Tranche der Ergebnismenge anzuzeigen, geben Sie bitte den Befehl it ein. Um Dokumente lesbarer anzuzeigen, verwenden Sie diesen Befehl:

> db.tweets.find().pretty()

Probieren Sie einfach mal ein paar Suchen nach verschiedenen Kriterien aus. Die Hilfe zur find()- Methode unterstützt Sie dabei.

> db.tweets.find().help()

Alle weiteren Details zu Queries und auch zur Indexierung finden Sie in Kapitel 6.

2.6 Schemafreiheit

Eines der Alleinstellungsmerkmale von MongoDB ist die sogenannte Schemafreiheit, auf die ich in Kapitel 8 noch genauer eingehen werde. Zum Einstieg will ich Ihnen anhand eines einfachen Beispiels die Möglichkeiten aufzeigen, die Sie ohne ein starres Schema haben.

Sie können z. B. einen Produktkatalog mit den unterschiedlichsten Produkttypen innerhalb einer Collection realisieren:

> use shop
switched to db shop
> db.produkte.insert({
  typ: "dvd",
  titel: "Lost Highway",
  regie: "David Lynch"
})
> db.produkte.insert({
  typ: "cd",
  titel: "Highway to Hell",
  band: "AC/DC"
})

Die Suche nach gemeinsamen Feldern der unterschiedlichen Produkte ist ganz einfach:

> db.produkte.find({titel: /Highway/})
{     "_id" : ObjectId("530eefa913109e3002c125de"),
      "typ" : "dvd",
      "titel" : "Lost Highway",
      "regie" : "David Lynch" }
{     "_id" : ObjectId("530eefe313109e3002c125df"),
      "typ" : "cd",
      "titel" : "Highway to Hell",
      "band" : "AC/DC" }

Eine Einschränkung auf bestimmte Produktarten ist dabei möglich:

> db.produkte.find({titel: /Highway/, typ: "cd"})
...

Das gilt ebenso für die Suche nach Feldern, die es nur für bestimmte Produkte gibt:

> db.produkte.find({regie: "David Lynch"})
...

Das Beispiel ist zugegebenermaßen trivial, deutet aber die Mächtigkeit an, die die Schemafreiheit beim Umgang mit semistrukturierten Daten bietet. Hier kristallisiert sich einer der Hauptvorteile von MongoDB heraus, der insbesondere auch den Big-Data-Aspekt Variety adressiert.

2.7 Zusammenfasssung

In diesem Kapitel haben Sie gesehen, wie einfach der Einstieg in MongoDB ist. Nach den ersten Schritten haben Sie bereits Daten importiert und die Vorteile der Schemafreiheit kennengelernt. Im nächsten Kapitel werde ich Ihnen die technologischen Grundlagen für all das näher erklären.

3 Grundlegende Konzepte

Nachdem Sie im letzten Kapitel die ersten praktischen Erfahrungen mit MongoDB und der Mongo Shell gesammelt haben, werden wir nun näher auf die dahinter liegenden Konzepte und Begriffe eingehen und die technischen Grundlagen beleuchten, auf denen MongoDB basiert.

Kapitel 6