NoSQL – Jenseits der relationalen Datenbanken

Dokumentenorientierte Datenbanken verfolgen einen völlig anderen Ansatz als relationale Datenbanken. Hier werden die zu speichernden Daten nicht in Tabellen abgelegt, sondern in sogenannten Dokumenten. Ein Dokument ist hier nicht im Sinne eines Textdokuments zu sehen, sondern eher als Sammelmappe. Innerhalb eines Dokuments können beliebige Felder definiert werden, die sogenannten Schlüssel, welchen jeweils einen Wert zugeordnet ist. Der Wert kann dabei in der Regel beliebig sein, also eine Zahl, ein Wort, ein Text, eine Liste von Worten bzw. Zahlen, eine Datei usw. Die Dokumente sind dabei komplett schemalos. Dies bedeutet, dass man innerhalb eines Dokuments jederzeit beliebige neue Schlüssel mit einem beliebigen Wert anlegen kann. Der Schlüssel muss zwar innerhalb eines Dokuments einmalig sein, kann aber in anderen Dokumenten wieder vorkommen – muss es aber nicht. Ebenso kann der Wert eine beliebige Länge haben, diese muss vorab nicht definiert werden. Dies ist ein fundamentaler Unterschied zur vorab klar zu definierenden und quasi-starren Struktur von relationalen Datenbanken.

Daher eigenen sich dokumentenorientierte Datenbanken besonders dann, wenn größere Mengen Text mit unbestimmter Länge zu speichern sind – wie z.B. bei Blogs und Content Management Systemen oder auch Wikis. Der Vorteil hier ist, dass alles, was zu einem Dokument (Wiki-Seite, Blogeintrag etc.) gehört, innerhalb der Datenbank auch in einem Dokument gespeichert werden kann. Dies wären z. B. die Meta-Daten einer Wiki-Seite (Tags, Datum der letzten Änderung etc.) oder bei einem Blog ebenfalls Metadaten oder auch die Kommentare, die Leser zum Blogeintrag hinterlassen haben. Bei relationalen Datenbanken würden diese Daten typischerweise auf mehrere Tabellen verteilt und wären nicht auf einen Blick sichtbar.

Dadurch, dass die Daten komplett anders abgelegt werden als in relationalen Datenbanken, ist bei der Nutzung von dokumentenorientierten Datenbanken vor allem eines wichtig: Umdenken. Was bei MySQL & Co. vielleicht auf mehrere Tabellen verteilt wurde (bzw. werden musste), kann bei Dokumentenorientierung wahrscheinlich in einem Dokument abgelegt werden. Auch die Abfrage der Daten gestaltet sich anders, wie im folgenden Abschnitt erklärt wird, was beim Anlegen der Dokumente natürlich berücksichtigt werden sollte. Denn auch wenn die Datenbank an sich schemalos ist bzw. kein Schema verlangt, sollte man sich natürlich vorab schon Gedanken machen, wie man die Daten innerhalb der Datenbank und den Dokumenten organisiert. Ansonsten ist es später eventuell schwierig, gezielte Abfragen durchzuführen.

Viele dokumentenorientierte Datenbanken verwenden für Abfragen auf die Datenbank einen MapReduce-Ansatz. Diese ursprünglich von Google entwickelte Abfragetechnik teilt die abzufragende Datenmenge in mehrere kleine Teilmengen auf und wendet dann das Abfragekriterium an. Liegen die Ergebnisse vor, ist der Map-Teil abgeschlossen. Anschließend werden die Ergebnisse der verschiedenen Map-Teile zusammengefasst und als Ergebnis ausgegeben, womit auch der Reduce-Teil ausgeführt ist. Der MapReduce-Prozess an sich ist für den Anwender nicht weiter sichtbar, er erhält immer das Ergebnis zurück. Der Vorteil von MapReduce ist, dass sowohl die Map-Prozesse als auch die Reduce-Prozesse (quasi-) parallel ausgeführt werden, was besonders bei größeren Datenmengen Geschwindigkeitsvorteile gegenüber gleichwertigen SQL-Abfragen an relationale Datenbanken bringt. Je nach Implementierung können auch dokumentenorientierte Datenbanken das Abfragergebnis noch nach bestimmten Kriterien sortieren (aufsteigend, absteigend etc.).

Dagegen ist es in der Regel nur sehr umständlich zu realisieren, den Schlüssel zu einem Wert zu erhalten. Das heißt, Abfragen wie Zeige alle Schlüsselnamen in allen Dokumenten, wo der Wert foobar lautet sind aufwendig und müssen in der Regel softwareseitig umgesetzt werden.

Das Datenformat, in der viele dokumentenorientierte Datenbanken die Daten speichern, ist JSON, die JavaScript Object Notation bzw. die binäre Variante BSON. Weiterhin ermöglichen die Datenbanken in der Regel einen einfachen Umgang mit binären Daten wie z.B. Dateien. Diese werden einfach wie jeder andere Wert auch in einem Feld gespeichert. Das Ergebnis von Abfragen auf die Datenbanken wird dann auch im JSON- bzw. BSON-Format zurückgegeben. Dies hat den Vorteil, dass die allermeisten Programmiersprachen mit JSON-Daten umgehen können.

Es gibt eine Reihe von Open-Source-Datenbanken, welche dokumentenorientiert sind. Zur Zeit wohl am verbreitetsten sind CouchDB und MongoDB.

Zu CouchDB gab es auf Pro-Linux einen ausführlichen Artikel. Einige Merkmale von CouchDB sind eine HTTP-basierte API, d.h. Daten können über reguläre HTTP-Requests abgefragt und geschrieben werden. Weiterhin ist standardmäßig eine Weboberfläche namens Futon enthalten, über die die Datenbank komplett verwaltet werden kann. Außerdem unterstützt CouchDB die automatische Revisionierung, d.h. bei jeder Änderung an einem Dokument wird eine neue Revision angelegt, die alten Daten bleiben aber erhalten. Dies gilt auch für Dateien, die als binäre Daten in der Datenbank abgelegt werden können. Außerdem ist die automatische Replikation der Datenbank, auch über mehrere Server hinweg und bidirektional, sehr einfach konfigurierbar.

MongoDB hat etwas andere Schwerpunkte als CouchDB. So unterstützt die Datenbank zusätzlich die Indizierung von Dokumenten, was die Abfragen bzw. die Suche innerhalb von Dokumenten schneller macht. Um direkten Zugriff auf die Datenbank zu bekommen, gibt es eine Schnittstelle für die Kommandozeile (ähnlich wie bei z.B. MySQL und SQLite). Zusätzlich stehen natürlich, ebenso wie bei CouchDB, APIs für eine Reihe von Programmiersprachen bereit. Stärken hat MongoDB weiterhin beim Umgang mit großen Datenmengen. Zum einen kann die Datenbank mit Hilfe von GridFS auch sehr große Dateien (z.B. Videos) speichern. Zum anderen unterstützt MongoDB von Haus aus die horizontale Skalierung (das sogenannte Sharding), d.h. mehrere parallel laufende Datenbanken teilen die Anfrage untereinander auf.