zurück zum Artikel

CouchDB - angesagter Vertreter der "NoSQL"-Datenbanken

Rudolf Jansen

Die Datenbank-Community diskutiert derzeit intensiv über "NoSQL-Datenbanken". Einer ihrer Vertreter ist CouchDB. Mit ihr erfolgt die Speicherung dokumentenbasiert und ohne explizite Schemadefinition.

Die Datenbank-Community diskutiert derzeit intensiv über "NoSQL-Datenbanken". Diese neuen Datenbanken verzichten bewusst auf Funktionen, die in ihren relationalen Pendants inzwischen Standard sind, und konzentrieren sich stattdessen auf Spezialanforderungen insbesondere in Web(-2.0)-Anwendungen, bei denen relationale Datenbanken an ihre (Performance-)Grenzen stoßen. Ein Vertreter der neuen Datenbankgeneration ist CouchDB. Mit ihr erfolgt die Speicherung dokumentenbasiert und ohne explizite Schemadefinition.

Wer zum ersten Mal den Begriff "NoSQL-Datenbanken" zur Kenntnis nimmt, fragt sich möglicherweise, ob mit ihnen die Datenbankwelt vollständig neuerfunden wird und man seine über die vergangenen Jahre gesammelten SQL-Kenntnisse zukünftig nicht mehr verwenden soll oder darf. Vielleicht denkt man an objektorientierte- oder XML-Datenbanken, die ebenfalls mit dem Ziel angetreten sind, relationale Datenbanken dort zu ersetzen, wo sie durch ihre zugrunde liegende tabellenbasierte Speicherung an ihre Grenzen stoßen. Sind NoSQL-Datenbanken nun der nächste Versuch, den "großen bösen" relationalen Datenbanken Marktanteile streitig zu machen? Der Begriff "NoSQL-Datenbanken" mag die Ursache für solche Annahmen sein und wird daher in letzter Zeit auch immer häufiger durch "Not only SQL Databases" ersetzt, was dem eigentlichen Grundgedanken hinter der neuen Datenbank-Generation mehr entspricht.

Derzeit existiert bereits eine Reihe von Datenbanken, die sich der wachsenden NoSQL-Gemeinde zuordnen lassen. Ein guter Marktüberblick befindet sich unter nosql-database.org [1]. Obwohl die Systeme sich in ihren theoretischen Grundlagen teilweise signifikant unterscheiden, zielen alle auf ähnliche Projektanforderungen hinsichtlich Skalierbarkeit, verteilten Datenabfragen sowie flexiblen Speichermodellen für Dateninhalte des Web-2.0-Zeitalters. Einige Systeme entstanden nicht am grünen Tisch, sondern durch Unternehmen der Web-2.0-Szene, die Schwierigkeiten hatten, den mit wachsenden Zugriffszahlen verbundenen Anforderungen bezüglich der Skalierbarkeit mit den am Markt verfügbaren relationalen (Cluster-)Systemen nachzukommen. Da es keine für sie passende Alternative am Datenbankmarkt gab, haben sie sich für die Eigenentwicklung entschieden.

Einen anderen Ursprung hat das CouchDB-Projekt. Seine Historie zeigt, wie schnell eine gute Idee das Interesse von Firmen und Investoren wecken kann. Sein Gründer, Damien Katz, hatte es 2005 ins Leben gerufen. Er führte es zunächst privat, ab 2008 dann als IBM-Angestellter fort. Ende 2009 gründeten Katz und einige Mitstreiter eine Start-up-Firma namens Relaxed Inc., und zwar mit 2 Millionen Dollar Venture-Kapital ausgestattet. Unter ihrem Dach soll die Weiterentwicklung von CouchDB erfolgen. Der Name CouchDB ist übrigens die Abkürzung für "Cluster of unreliable commodity hardware Data Base".

Innenleben & Sicherheit

CouchDB ist in Erlang implementiert. Zugriffe auf die Datenbank erfolgen nicht über SQL-Befehle, sondern nach den Prinzipien des REST-Paradigmas (Represential State Transfer; siehe Glossar) über HTTP-Befehle: Speicheroperationen über HTTP PUT beziehungsweise POST und Leseoperationen über HTTP GET. Gemäß dem Oberbegriff "NoSQL" wird aus einem SELECT * FROM <Tabelle> ein http://<SERVER>:<PORT>/<DBName>/<Ressource>. Abfrageergebnisse wiederum lassen sich über ein Map/Reduce-Verfahren (siehe Glossar) mit JavaScript-Funktionen ermitteln. Ein weiterer für Webentwickler bekannter Begriff ist das JSON-Datenformat, das CouchDB verwendet.

Wer sich in der Vergangenheit mit der Entwicklung von Webanwendungen beschäftigt hat, findet sich in CouchDB schnell zurecht, und wird bestätigen, dass CouchDB das Rad nicht neu erfindet, sondern auf seit Langem in der Praxis bewährten Prinzipien aufbaut. Am Beispiel des verwendeten JSON-Formats (siehe Glossar) erfolgt das etwa mit der Überlegung, dass es sinnig ist, in Webanwendungen mit dem JSON-Format ausgetauschte Objekte auch in dem Format zu speichern. Man vermeidet dadurch Performance-Einbußen bei der alternativen Umwandlung der JSON-Objekte in andere (Speicher-)Formate.

Das grundlegende CouchDB-Speicherprinzip ist – wie bei vielen anderen NoSQL-Datenbanken – die Speicherung von Key-Value-Paaren. Die interne Speicherung erfolgt in B-Bäumen. CouchDB besitzt eine Plug-in-Architektur, das heißt, es lassen sich Erweiterungen in unterschiedlichen Sprachen entwickeln und hinzufügen. Das alles hört sich noch nicht grundlegend neu an. Was ist also das Besondere von CouchDB?

CouchDB speichert Dokumente ohne Schemavorgabe, das heißt Dokumente mit beliebiger Syntax. Im Gegensatz zu relationalen Datenbanken, bei denen man in der Regel als ersten Schritt ein Datenbankschema entwirft, das den Vorgaben der Projektspezifikation entspricht, benötigt CouchDB solch präzisen Vorgaben nicht. Grundsätzlich lässt sich jedes Dokument in einer CouchDB-Instanz ablegen. Die Dokumente liegen mit einer eindeutigen ID versehen in der Datenbank und sind über sie zudem wieder auszulesen. Das allein wäre noch kein Grund, ein Datenbanksystem einzusetzen, denn das könnte man auch erreichen, indem man die Dokumente einfach ins Dateisystem ablegt. Wer eine Datenbank verwendet, will auch komplexere Abfragen über mehrere Dokumente unterschiedlichen Typs durchführen.

Bei CouchDB übernehmen das Views. Eine solche zu erstellen bedeutet, eine JavaScript-Funktion zu schreiben (andere Sprachen sind ebenfalls denkbar). Sie wird anschließend für jedes Dokument aufgerufen und erzeugt Einträge in einem Index. Solche Einträge sind über JavaScript ermittelte Teile des Dokuments. Konkret legt sie die JavaScript-Funktionen in sogenannten Design-Dokumenten ab, mit deren Hilfe die Indizes und damit die nach außen sichtbaren Views immer auf dem neuen Stand zu halten sind.

Wie sieht es mit der Zugriffssicherheit aus?

Wie in anderen Datenbanken gibt es für die Zugriffssicherheit ein Nutzersystem mit unterschiedlichen Rechten. Administratoren haben unter anderem Zugriff auf die Design-Dokumente, in denen die View-Funktionen abgelegt sind. Pro Dokument lässt sich festlegen, welche Nutzer das Dokument (oder Teile davon über Views) lesen dürfen. Auch zur Rechteprüfung bei Schreiboperationen lassen sich mit JavaScript-Funktion Regeln festlegen.

Ein wichtiges Thema im Umfeld von Web- und Cloud-Anwendungen ist das Thema Replikation. Ein logischer Datenbankserver kann aus mehreren physikalischen Servern mit eigenen Datenbeständen bestehen. CouchDB ist ein verteiltes Datenbanksystem, mit dem es – auch im Offline-Modus – möglich ist, von mehreren unabhängigen Stellen aus Änderungen am gesamten Datenbestand durchzuführen, die anschließend vom Nutzer aufgerufene Datenbankmechanismen auf Konsistenz prüfen und in den Gesamtbestand übernehmen.

Installation und erste Schritte

Eine Installation von CouchDB unter Linux erfolgt über die aus anderen Apache-Projekten bekannten Installier-Skripte, die in der jeweils aktuellen Download-Version [2] enthalten sind. Für die Windows-Plattform gibt es zum jetzigen Zeitpunkt eine Beta-Version eines Binär-Installers [3], für die noch manuelle Vorarbeiten durch die Installation von Erlang, Visual C++ Redistributables und OpenSSL erforderlich sind. Wem das zu aufwendig ist, findet eine vollständige Windows-Installer-Datei inklusive der Bestandteile außerhalb des offiziellen CouchDB-Projekts, etwa hier [4]. Nach der Installation auf dem lokalen Windows-Rechner (unter einem Benutzer mit Admin-Rechten) ist CouchDB per Default über folgende URL erreichbar: http://localhost:5984. Wie kommen nun Daten beziehungsweise Dokumente in die frisch installierte CouchDB? Ein Grundsatz bei der Entwicklung von CouchDB war "ease of use". In dem Zusammenhang ist ein Blick in das Logfile der CouchDB unmittelbar nach Start der Instanz aufschlussreich. Man findet dort unter anderem folgende Angaben:

CouchDB 0.10.0 - prepare to relax...
Eshell V5.7.2  (abort with ^G)
1> Apache CouchDB 0.10.0 (LogLevel=info) is starting.
1> Apache CouchDB has started. Time to relax.
1> [info] [<0.1.0>] Apache CouchDB has started on http://127.0.0.1:5984/

Weboberfläche Futon

Entspannt kann man nun entweder manuell (zum Beispiel über curl-Aufrufe) oder über die mitgelieferte Weboberfläche Futon (siehe Abbildung), die über http://localhost:5984/_utils erreichbar ist, Datenbanken anlegen und anschließend Dokumente eintragen. Eine initialeAnlage von Tabellen oder Ähnlichem ist durch die Schemafreiheit nicht erforderlich. Das Anlegen einer Datenbank mit Namen my_first_db erfolgt entweder mit einer GUI über den CreateDatabase-Button in der Futon-Oberfläche oder über einen curl-Aufruf:

curl -X PUT http://localhost:5984/my_first_db

Ein neuer Eintrag in die soeben angelegte Datenbank erfolgt ebenfalls mit der Futon-GUI oder manuell:

curl -X PUT http://localhost:5984/my_first_db/4711
     -d '{"title":"HelloWorldInCouchDB"}'

Es lässt sich ein Dokument mit der ID 4711 anlegen, das über die -d-Option in JSON-Notation angegeben ist. Das Auslesen des Dokuments ist über HTTP GET möglich, etwa wie folgt:

curl -X GET http://localhost:5984/my_first_db/4711

Das fragt gemäß den REST-Prinzipien die Ressource mit der ID 4711 in der Datenbank my_first_db ab, die Antwort lautet:

{"_id":"4711","title":"HelloWorldInCouchDB"}

Sowohl die Weboberfläche Futon als auch die Option, manuelle curl-HTTP-Befehle abzusetzen, sind für die Kennenlern- und Einarbeitungsphase von CouchDB-Neueinsteigern geeignet. In realen Projekten dagegen sind auch andere Zugriffsmöglichkeiten erforderlich. Neben diversen HTTP-Frameworks existieren einige Bibliotheken für Programmiersprachen, mit denen sich CouchDB-Anwendungen erstellen lassen. Beispielhaft sei JCouchDB [5] genannt, mit dem man Java-Anwendungen erzeugen kann, bei denen sich normale Java-Objekte (POJOs) über die Svenson JSON Libary [6] in das JSON-Format bringen lassen und dadurch CouchDB-kompatibel werden.

Sind NoSQL-Datenbanken im Allgemeinen und CouchDB im Speziellen nur eine Spielwiese für erklärte Gegner relationaler Datenbanken, oder steckt mehr hinter der neuen Generation von Datenbanken? Wer die Situation nicht ausschließlich durch die Brille eines Vertriebsbeauftragten einer relationalen Datenbank betrachtet, merkt schnell, dass tatsächlich eine attraktive Alternative entsteht.

Wenn auch die Bezeichnung NoSQL-Datenbanken zunächst etwas anderes vermuten lässt, sind CouchDB und die anderen NoSQL-Vertreter nicht angetreten, um die relationalen Datenbanken komplett zu verdrängen. Das wollen und können sie nicht. Stattdessen haben sowohl NoSQL- als auch relationale Datenbanken ihre Stärken, die sie bei passenden Projektanforderungen ausspielen können. Die erwähnte Schemafreiheit der NoSQL-Datenbanken lässt sie zwar flexibler für die Ablage von beliebigen Dokumenten sein. Die durch ein Datenbankschema vorgegebene exakte Struktur der Tabelleninhalte ermöglichen dagegen in der relationalen Welt zudem (Ad-hoc-)Abfragen auf ungewöhnlichen Spaltenkombinationen. Wer so etwas benötigt oder sich dafür Optionen offen halten will, bleibt in der relationalen Welt.

Relationale Datenbanken sind dafür gebaut, auf einem zentralen Server zu laufen. Im Zeitalter des Cloud Computing werden aber häufig viele kleinere Rechner zusammen verwendet, das heißt, die Verteilung von Anfragen gestaltet sich immer wichtiger. Relationale Datenbanken bieten dafür zwar Cluster-Lösungen, sind aber vom Grunddesign eben nicht dafür gebaut. Als Folge kommt man insbesondere in neueren Webanwendungen selbst mit relationalen Cluster-Lösungen an ihre Grenzen.

CouchDB bietet weniger Funktionen als Oracle, DB2, MySQL und die meisten anderen relationalen Systeme und ist daher wesentlich schlanker. Das erkennt man am Sourcecode-Umfang, der bei circa 13.000 Zeilen liegt. Zum Vergleich: Der MySQL-Sourcecode liegt oberhalb der Millionen-Grenze. Eine eierlegende Wollmilchsau ist CouchDB nicht und wird es auch nie werden. Wer das aber nicht sucht, sondern eine Speichertechnik für Dokumente, bei der sich die Flexibilität sowie die oben genannten Funktionen von CouchDB nutzen lassen, dem sei ein Blick auf CouchDB empfohlen. Ein Prototyp ist durch die mit der Schemafreiheit verbundene Flexibilität schnell erstellt.

Rudolf Jansen
arbeitet als freiberuflicher Software-Entwickler und Journalist in Aachen. Seine Tätigkeitsschwerpunkte liegen in den Bereichen Java, C++, XML und Datenbanken.

JSON (JavaScript Object Notation) ist ein im Webumfeld bekanntes programmiersprachenunabhängiges Datenaustauschformat. JSON-Objekte bestehen syntaktisch aus einer durch Kommata getrennten Liste von Eigenschaften. Jede Eigenschaft wiederum ist ein Key-Value-Paar, wobei der Value wiederum eine Eigenschaft sein kann. Ein Beispiel:

{
  "Zeitschrift" : "IX",
  "Jahrgang"  : 2010,
  "Ausgabe"   : 2,
  "Verlag"      : {
       "Name" : "Heise",
       "Ort"     : "Hannover"
   }
}

Map/Reduce ist ein Verfahren zur effizienten Verarbeitung von Abfragen auf großen Datenmengen. Es beruht auf Prinzipien der funktionalen Programmierung und hat durch die Methoden map und reduce seinen Namen erhalten. Die verteilte Verarbeitung einer Anfrage erfolgt in zwei Schritten. Im ersten Schritt berechnet eine Map-Funktion lokal Zwischenergebnisse und legt sie ab, die im zweiten Schritt eine Reduce-Funktion zum Gesamtergebnis zusammenfasst. Über die Implementierung der beiden Map- und Reduce-Funktionen ergibt sich somit in Cluster-Umgebungen die Chance, eine komplexe Abfrage auf großen Datenmengen durch Parallelisierung in akzeptabler Antwortzeit durchzuführen.

REST (Representational State Transfer): Grundlage des von Roy Thomas Fielding in seiner Dissertation [7] entworfenen REST-Verfahrens ist der Ansatz, jeder Ressource innerhalb einer Anwendung einen URI zuzuordnen. Alle Zugriffe auf die Ressource erfolgen über HTTP-Aufrufe. Insbesondere in Webanwendungen ergibt sich somit eine einfache und durch die Verbreitung von HTTP weitverbreitete Zugriffsmöglichkeit, die sich mit den anderen aus der HTTP-Welt bekannten Funktionen verbinden lässt.

Siehe dazu auch:

(ane [9])

URL dieses Artikels:
https://www.heise.de/-929070

Links in diesem Artikel:
[1] http://nosql-database.org/
[2] http://couchdb.apache.org/downloads.html
[3] http://wiki.apache.org/couchdb/Windows_binary_installer
[4] http://www.stefan-reimers.de/blog/couchdb-0-10-als-windows-binary.php
[5] http://code.google.com/p/jcouchdb/
[6] http://code.google.com/p/svenson/
[7] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
[8] http://www.heise.de/developer/artikel/Episode-17-Einstieg-in-REST-921652.html
[9] mailto:ane@heise.de

Copyright © 2010 Heise Medien