• Anzeigen
• Bearbeiten
• Versionen
• Druckansicht

Apache CouchDB

„Apache CouchDB is running [...], time to relax“ [1] – der Anspruch von Apache CouchDB, über einfache Grundkonzepte im NoSQL -Bereich selbst für Laien gebrauchstauglich zu sein, wird bereits bei den ersten Kontakten sichtbar. [vgl. 2] Apache CouchDB ist eine Implementierung des dokumentenorientierten Datenbankparadigmas, die unter der Apache 2.0-Lizenz zur Verfügung gestellt wird und orientiert sich an Google BigTable. Dabei ist CouchDB ein Akronym und steht für Cluster of unreliable commodity hardware Data Base. Die herauszustellenden Merkmale dieses dokumentenorientierten DBS sind:

1. JSON -Dokumente als Datenspeicher,
2. HTTP (per REST) für Anfragen, und
3. Zuverlässigkeit sowie
4. Konsistenz der Datenspeicherung.

Da es für dokumentenorientierte Datenbanken keine mit SQL vergleichbare Standardisierung gibt, unterscheiden sich die jeweiligen Anwendungsprogramme deutlich stärker als beispielsweise bei relationalen Datenbanken. Mit "Couch is Lotus Notes built from the ground up for the Web" [8] setzte Damien Katz, der Erfinder von CouchDB, den primären Einsatzbereich des DBS auf die Entwicklung von Webanwendungen. Des Weiteren ist Apache CouchDB über die zugrundeliegende Apache Lizenz 2.0 [3] nach der Open Source Initiative als Open Source Software einzuordnen [vgl. 4], nutzt MapReduce über JavaScript, und stellt die eingebetteten Anwendungen CouchApps [vgl. 5] im Sinne eines Anwendungsservers bereit. [vgl. 6]

Über das Apache CouchDB Web-Interface Futon können viele Verwendungsschritte leicht verständlich ausgeführt werden.

Im Folgenden werden die spezifischen Eigenschaften von Apache CouchDB näher vorgestellt, so dass ein umfassendes Bild dieser Datenbank entsteht.

Steckbrief

Tabelle: CouchDB-Steckbrief, entnommen aus Edlich (2011)

Historie - Entwicklung, Zusammenhänge und Einordnung

Lotus Notes wurde in den 80er-Jahren bei Iris Associates entwickelt [vgl. 7] und stellt eines der ersten dokumentenorientierten DBS dar. Nachdem Iris Associates 1995 von IBM übernommen und Lotus Notes später IBM Notes genannt wurde, entwickelte der im darauf folgenden Zeitraum bei IBM im Bereich Lotus Notes tätige Damien Katz schließlich 2005 CouchDB. Die Apache Software Foundation übernahm 2008 die weitere Entwicklung, daher auch der aktuelle Name Apache CouchDB.

2009 gründete unter anderem Damien Katz CouchOne [vgl. 9] (ehemals Couch.io [vgl. 10]), welches 2011 mit Membase Inc. (ehemals Northscale) fusionierte. [vgl. 11] Aus den entsprechenden beiden Produkten CouchDB und Membase entstand Couchbase, in Bezug zu Apache CouchDB vor allem als Weiterentwicklung hinsichtlich Performance, Verteilung und Skalierbarkeit. [vgl. 12] Derzeit existieren noch einige weitere Forks von Apache CouchDB. rcouch [13] bspw. bietet viele experimentelle Erweiterungen wie Dropbox-unterstützende Datenbanken. CouchDB-Lounge [14] wartet mit Partitionierung basierend auf Proxys auf, wird allerdings seit 2010 nicht mehr aktualisiert. Für den Bereich Clustering eignet sich aktuell daher BigCouch [15].

Architektur und Implementierung des CouchDB-Servers [16]

Architektur und Implementierung

Dokumente werden über eine HTTP API ( REST) erstellt, gelesen oder aktualisiert. Dabei nutzt die Anfragespache wie beschrieben JavaScript und MapReduce, um auf die internen Module zuzugreifen. [vgl. 17] CouchDB ist auf der Erlang OTP Plattform aufgebaut. [vgl. 18] Das Modul für Views nutzt die JavaScript-Engine SpiderMonkey und Unicode Collation für die Kodierung von Zeichen [vgl. 19], legt aber auch Views (genauer permanente Views) im physischen Speicher ab. Apache Lucene kann für Textsuche und Indizierung hinzugefügt werden. Ad-hoc-Abfragen sind über Virtuelle Dokumente (Temporary Views) möglich [vgl. 20], somit kann jedes Field eines Dokuments jederzeit abgefragt werden, und der User kann eine Anfrage formulieren, „ohne ein vollständiges Programm schreiben zu müssen“ [21]. CouchDB wendet asynchrone Replikation [vgl. 33] an, des Weiteren handelt es sich um ein Disk-basierend speicherndes DBS, alle Schreibvorgänge werden direkt auf die Festplatte geschrieben, ohne länger im Arbeitsspeicher oder dergleichen temporär gespeichert zu werden. [vgl. 22] Das Modul mod_couch sammelt und wandelt JSON -Dokumente über URL's des Datenbankzugriffs entsprechend um, dabei ersetzt hauptsächlich dieses Modul die mittlere Software-Schicht hin zu einer 2-Schichten-Architektur. [vgl. 23]

Speicherung der Daten (Dokumente in CouchDB)

Es existieren im Rahmen von CouchDB diverse Dokumentarten, die jeweils eine eigene Verantwortung haben. Von zentraler Bedeutung sind

1. Daten-,
2. Virtuelle (nicht persistent) und
3. Design Dokumente.

Die Dokumente in CouchDB werden in der Java Script Object Notation (JSON) gespeichert, wobei dies schemafrei abläuft. Dennoch werden für ein korrektes Auslesen semi-strukturierte Daten benötigt [vgl. 34], denn die (Web-)Anwendungen, nicht die Datenbank selbst, haben die Schemaverantwortung, zudem gibt JSON eine gewisse Ordnung durch die Syntax vor. [vgl. 24] Die Dokumente selbst können in benennbaren Unterdatenbanken, die man sich am besten als Dokumentenverzeichnisse vorstellen kann, gespeichert werden. Dabei verfügt jedes persistente Dokument über eine vom Benutzer bestimmbare Dokument-ID, die innerhalb einer Datenbank eindeutig sein muss, und über eine von CouchDB verwaltete Revisions-ID, die angibt, in welcher Version ein Dokument vorliegt. Die einfachste Form, Dokumente zu erzeugen, ist über eine REST-Konforme HTTP-Anfrage, welche in einem internen B-Plus-Bäumen gespeichert werden.

Datendokumente

Datendokumente sind Dokumente wie sie im dokumentenorientierten Datenbankparadigma aufgefasst werden. Sie stellen eine geschlossene Einheit von Informationen dar und werden mit zusätzlichen Metadaten in der Datenbank gespeichert. Als Metadatum muss zu jeder Erzeugung eines Dokuments eine Dokument-ID mitgegeben werden. Hierfür wird eine Universally Unique Identifier (UUID) empfohlen, was jedoch nicht zwingend notwendig ist. [vgl. 25] Diese können auch benutzerdefinierte IDs sein. CouchDB kann selbst mittels eines GET-Request an die URL http://127.0.0.1:5984/_uuids UUIDs generieren und zur Weiterverwendung liefern. Im Folgenden ist ein Beispiel für ein Datendokument dargestellt, wobei die Dokument-ID als Wert zum Schlüssel „_id“ vorliegt.

{

	"_id"       :	"00a271787f89c0ef2e10e88a0c00048b", 
	"_rev"      :	"1-60e25d93dc12884676d037400a6fa189", 
	"item"      :	"Banane", 
	"preise"    : 
		{
			"Markt"   : 0.10, 
			"Lebensmitteldiscounter" : 0.08, 
			"Bauern"  : 0.25 
		} 

}

Virtuelle Dokumente

Alle Informationen in einem Dokument zu verwalten, entspricht dem Paradigma und bietet zu den Vorteilen eines dokumentenorientierten Persistierens einige Nachteile in der Umsetzung CouchDB (z.B. Konfliktwahrscheinlichkeit). Daher bietet es sich an, in manchen Fällen Dokumente in mehrere logische Dokument-Typen zu zerteilen. Als gängiges Beispiel seien hier Blogposts und die zugehörigen Kommentare erwähnt. In solchen Fällen möchte man dennoch mittels einer Anfrage die geteilten Informationen zusammen erhalten. Hierzu werden virtuelle Dokumente verwendet, welche Views darstellen. In ihrer nicht-persistierten Form stellen diese Views virtuelle Dokumente dar und können als Ad-Hoc-Abfragen bezeichnet werden. Im Web-Interface Futon von CouchDB können diese virtuellen Views unter dem Punkt „Temporary view“ erstellt werden.

Design Dokumente

Eine letzte Dokumentenart stellen die Design-Dokumente dar. Die Besonderheit, die Design-Dokumente von Daten-Dokumenten unterscheidet, ist, dass sie Quellcode enthalten, für dessen Ausführung der in CouchDB eingebaute JavaScript-Query-Server notwendig ist. Design-Dokumente können als einzelne Oberflächen von Webanwendungen verstanden werden. CouchDB speichert und behandelt Design-Dokumente wie Daten-Dokumente. Beispielsweise werden diese im Rahmen einer Replikation ebenfalls auf die Zieldatenbank kopiert. Eine Restriktion ist dennoch einzuhalten: die ID eines Design-Dokuments muss mit dem Präfix „_design/“ beginnen. Einzelne Komponenten eines Design-Dokuments können sein :

1. View-Funktionen,
2. Show-Funktionen,
3. List-Funktionen,
4. Update-Funktionen und
5. Validierungs-Funktionen. [vgl. 27]

Kommunikation

Die Kommunikation mit CouchDB wird durch HTTP-Anfragen realisiert, so dass kein eigenes Kommunikationsprotokoll definiert werden muss. Die Verwendung von HTTP erleichtert zudem die Anbindung an Web-Anwendungen enorm, des Weiteren ist das Protokoll ein allgemein bekannter Standard und leicht zu verwenden. Da es sich bei HTTP um ein zustandsloses Protokoll handelt, müssen alle relevanten Transaktionsdaten in einer Anfrage übergeben werden. Man spricht in diesem Zusammenhang von REST (Representational State Transfer). Um mit CouchDB zu kommunizieren, bietet sich u.a. das Kommandozeilenwerkzeug cURL an. Im Folgenden werden einige Beispiele der Kommunikation mit CouchDB aufgelistet. Die Eingabe wird mit curl in einer Kommandozeilenumgebung durchgeführt, die Ausgabe wird ebenfalls auf der Kommandozeile dargestellt. Die Ausgabe erfolgt in Form eines JSON -Objekts.

• Statusabfrage an CouchDB

Eingabe: curl -X GET http://127.0.0.1:5984/
Ausgabe: {"couchdb":"Welcome","version":"1.0.2"}
Bedeutung: Diese Anfrage dient dazu, zu bestätigen, dass eine CouchDB ausgeführt wird und auf Anfragen reagiert.

• Abfrage aller Datenbanken

Eingabe: curl -X GET http://127.0.0.1:5984/_all_dbs
Ausgabe: [“db1",“db2", …, “dbn”]
Bedeutung: Durch diese Anfrage werden die Namen aller in CouchDB angelegten Datenbanken zurückgegeben.

• Anlegen einer Datenbank

Eingabe: curl -X PUT http://127.0.0.1:5984/mydb
Ausgabe: {"ok":true}
Bedeutung: Diese Anfrage legt eine Datenbank mit dem Namen "mydb" an. In dieser Datenbank können nun Dokumente angelegt werden.

• Anlegen eines Dokuments

Eingabe: curl -X PUT http://127.0.0.1:5984/mydb/123 \ -H "Content-Type: application/json" -d {\"Name\":\"Ich\"}
Ausgabe: {"ok":true,"id":"123","rev":"1-3378341fc22f9bd91304fec679fa91ca"}
Bedeutung: Durch diese Anfrage wird in der Datenbank "mydb" ein Dokument mit der ID "123" angelegt, welches das Feld mit dem Schlüssel "Name" und dem Wert "Ich" enthält. In der Ausgabe wird zudem die von CouchDB erstellte Revisions-ID übermittelt. Warum dies wichtig ist, wird beim Punkt "Ändern eines Dokuments" deutlich.

• Abfragen eines Dokuments

Eingabe: curl -X GET http://127.0.0.1:5984/mydb/123
Ausgabe: {"_id":"123","_rev":"1-3378341fc22f9bd91304fec679fa91ca","Name":"Ich"}
Bedeutung: Diese Abfrage gibt das Dokument mit der ID "123" in der Datenbank "mydb" aus. Neben den vom Benutzer gefüllten Feldern "_id" und "name" wird die Revisions-ID übergeben. Ein Dokument wird immer komplett mit allen enthaltenen Feldern übergeben.

• Ändern eines Dokuments

Eingabe: curl -X PUT http://127.0.0.1:5984/mydb/123 \ -H "Content-Type: application/json" -d {\"_rev\":\"1-3378341fc22f9bd91304fec679fa91ca\“ ,\"Name\":\"Du\",\"Alter\":\"0\"}
Ausgabe: {"ok":true,"id":"123","rev":"2-2ff1ff51c44458a94264b10fae148376"}
Bedeutung: Durch diese Abfrage wird das Dokument mit der ID "123" in der Datenbank "mydb" durch eine neuere Version ersetzt. Die neue Version des Dokuments enthält ein neues Feld "Alter" mit dem Wert "0", der Wert des Felds "Name" wird auf den Wert "Du" geändert. Um ein Dokument zu ändern bzw. eine neue Version eines Dokuments zu erstellen, muss die Revisions-ID der alten Version des Dokuments übertragen werden. Dadurch wird sichergestellt, dass der Benutzer die alte Version des Dokuments kennt. Stimmt die angegebene Revisions-ID nicht mit der gespeicherten überein, ist keine Änderung des Dokuments möglich. Daher wird die Revisions-ID bei Abfragen an das Dokument mit ausgegeben. Ältere Versionen des Dokuments werden zwar gespeichert, für eine Aktualisierung muss jedoch immer die Revisions-ID der jeweils aktuellsten Version angegeben werden. Alternativ besteht die Möglichkeit, CouchDB mit Hilfe des integrierten Web-Interface Futon zu verwenden. Dadurch ist das Erstellen, Bearbeiten und Betrachten von Dokumenten wesentlich simpler und komfortabler als die Verwendung eines Kommandozeilenwerkzeugs wie curl. CouchDB erfüllt im lokalen Einsatz die ACID-Eigenschaften?. Jede Transaktion ist eine in sich abgeschlossene Operation, die entweder ganz oder gar nicht ausgeführt wird. Seiteneffekte zwischen den Anfragen treten nicht auf, ebenso wird die Datenbank immer in einem konsistenten Zustand hinterlassen. Bis zu ihrer eventuellen Löschung bleiben Dokumente in der Datenbank gespeichert, sie verfügen über kein "Verfallsdatum".

Weiterführendes Tutorial: http://curl.haxx.se/libcurl/c/libcurl-tutorial.html

CouchDB im CAP-Theorem, entnommen aus Anderson(2011)

Views

Um Daten innerhalb von Dokumenten abzufragen oder zu aggregieren, existieren in Apache CouchDB Views. Diese sind MapReduce-Funktionen in JavaScript-Programmiersprache. Neben dem erwähnten Einsatzbereich können View-Funktionen zudem verwendet werden, um

• Dokumente zu filtern,
• Informationen aus Dokumenten zu extrahieren und in einer spezifischen Form darzustellen,
• Nach Informationen oder Strukturen zu suchen oder
• Berechnungen durchzuführen.

Es sei explizit darauf hingewiesen, dass View-Funktionen nicht vom Anwender, sondern von Apache CouchDB ausgeführt werden. Fragt man eine View ab, wendet das DBS die Map-Funktion auf alle Dokumente an. „You query your view to retrieve the view result.“ [28] Das Ergebnis der Map-Funktion wird als View-Ergebnismenge bzw. View-Rows bezeichnet. Die Einträge in der Ergebnismenge sind Schlüssel/Werte-Paare. Wird die Map-Funktion auf ein Dokument angewendet, können hieraus beliebig viele Einträge in der Ergebnismenge resultieren. Im Folgenden ist eine Map-Funktion dargestellt.

function(doc) {

	if (doc.item && doc.price) {
		emit([ doc.item, doc.price ], 1);
	}

}

Der Map-Funktion wird ein Parameter („doc“) übergeben, die ein Dokument darstellt. In der if-Anweisung wird überprüft, ob das Dokument bestimmte Schlüssel hat. Dies ist erforderlich, da die Map-Funktion auf alle Dokumente angewendet wird und nur Dokumente mit bestimmten Eigenschaften von Interesse sind. In diesem Beispiel sind es Dokumente, die die Eigenschaft „item“ und „price“ haben. Hiernach wird mit der emit-Funktion ein Schlüssel/Werte-Paar in die Ergebnismenge eingetragen. Die emit-Funktion kann innerhalb der Map-Funktion auch mehrere Male aufgerufen werden, wobei mehrere Einträge pro Dokument möglich sind. Von Bedeutung ist zudem, dass die Ergebnismenge nach dem Schlüssel sortiert zurückgegeben wird. In dem Beispiel wird eine Kombination aus der Eigenschaft „item“ und der Eigenschaft „price“ in einem Array als Schlüssel zurückgegeben, womit eine Sortierung der Ergebnismenge erst nach der Eigenschaft „item“ und dann nach der Eigenschaft „price“ vorgenommen wird. Um die Reduce-Funktion innerhalb einer View zu verstehen, muss bekannt sein, dass die Ergebnismenge der Map-Funktion als ein B+-Baum verwalten wird. Eine einfache Reduce-Funktion sieht wie folgt aus:

function(keys, values, rereduce) {

   return sum(values);

}

Die Reduce-Funktion wird, falls keine Filterung der Abfrage vorgenommen wird, auf jeden Knoten im B+-Baum angewendet. Im ersten Parameter befinden sich die Schlüssel und im zweiten die Werte, die in einem Knoten gespeichert sind. Das Ergebnis wird zwischengespeichert. Der dritte Parameter gibt an, ob ein Blätter-Knoten oder ein innerer Knoten bearbeitet wird. Der Wert des dritten Parameters ist „false“, wenn es sich um einen Blätter-Knoten handelt, wobei die anderen beiden Parameter wie bereits erwähnt belegt sind. Der Wert des dritten Parameters ist „true“, wenn es sich um einen inneren Knoten bei der Ausführung handelt. In diesem Fall ist der erste Parameter „null“ und der zweite Parameter ein Array aus Zwischenergebnissen der entsprechenden Kinder-Knoten. Erinnert man sich daran, dass die Nutzdaten in einem B+-Baum nur in den Blättern gespeichert werden, so versteht man in manchen Fällen die Notwendigkeit, eine Unterscheidung vorzunehmen. Während bei den Blättern Operationen bzgl. einzelner Einträge in der Ergebnismenge der Map-Funktion vorgenommen werden können, können deren Zwischenergebnisse bei der Bearbeitung der inneren Knoten weiter verwendet werden.

Replikation

Die Replikation, d.h. die Übertragung der Daten auf andere Knoten, ist bei Apache CouchDB ein inkrementeller Prozess [vgl. 30] per Push und Pull [vgl. 29]. Wie die Client-Server Kommunikationsvorgänge wird auch die Replikation über HTTP-Requests abgewickelt. Die Daten werden dokumentweise auf Server übertragen, die sich an geografisch stark unterschiedlichen Orten befinden, um geringe Latenzen bieten zu können („move data more closely to clients“ [29]). Über „Continuous Replication“ [vgl. 31] kann relativ komfortabel eine unidirektionale Replikation, welche als Backup dienen kann, faktisch aber keines darstellt, eingerichtet werden, diese kann zudem zu einer bidirektionalen Replikation erweitert werden. [vgl. 32] Die Backupserver sind hierbei nicht aktiv für Abfragen eingebunden. Um die bidirektionale Replikationen im Rahmen von Load-Balancing einsetzen zu können, müssen zusätzliche Frameworks wie „CouchDB Lounge“ verwendet werden. Für Partitionierung (bzw. Sharding) wird ebenfalls einer der genannten Forks von Apache CouchDB benötigt, um im Kontext von verteilter Einrichtung besser zu skalieren. [vgl. 35] Die dokumentweise Übertragung dient dazu, um bei Unterbrechung des Kommunikationsprozesses die Übertragung dort fortzusetzen, wo sie abgebrochen worden ist. Damit ist ein Neustart der Replikation nicht erforderlich und das System wird robuster gegenüber Fehlern.
Über Futon kann ein entsprechender Replikationsprozess couch-entsprechend bequem initialisiert werden.

Bei der Entwicklung des Replikationsverfahrens ging man davon aus, ein CouchDB-Knoten sei im Normalfall nicht erreichbar("offline by default"). Daher wurde bei CouchDB der Fokus auf eine hohe Ausfalltoleranz (siehe CAP-Theorem) gelegt.
Ein wesentliches Augenmerk bei der Entwicklung von CouchDB lag auf dem Aspekt der Verfügbarkeit. Bei Replikationsvorgängen bleiben die Daten dennoch weiter lesbar, es findet also kein Locking statt. Die Konsistenz wird dadurch jedoch nicht ignoriert, da jedes Dokument über eine Revisions-ID verfügt, so dass eventuelle Änderungen nachverfolgt werden können.

Da bei Datenbankzugriffen während des Replikationsvorgangs Versionskonflikte auftreten können, ist eine entsprechende Konfliktbehandlung nötig, welche über das Konsistenzmodell BASE mittels der Technik MVCC gewährleistet wird.

Konfliktbehandlung bei Manipulation und Replikation

CouchDB verwendet zur Konfliktlösung das MVCC -Paradigma, um LOCKING zu verhindern und die größtmögliche Verfügbarkeit zu gewährleisten. Vector Clocks?, welche im Übrigen nur der Erkennung, aber nicht der Lösung von Konflikten dienen [vgl. 38], werden nicht eingesetzt. Im Gegensatz zu relationalen DBMS ist dies bei einer dokumentenorientierten Datenbank einfacher, da die Daten innerhalb eines Dokuments keinen Einfluss auf den restlichen Datenbestand haben. Dokumente werden, im Gegensatz zu Tabellen, nicht geändert, sondern durch neuere Versionen überschrieben. Konflikte können also immer nur zwischen einzelnen Dokumenten auftreten, so dass auch nur in diesem Fall ein Lösungsverfahren geliefert werden muss.

Dokumente werden in CouchDB bei einer Änderung nicht überschrieben, sondern es wird ein neues Dokument mit der gleichen Dokument-ID, aber einer anderen Revisions-ID erzeugt. Die Revisions-ID stellt damit den MVCC -Token in Apache CouchDB dar. [vgl. 26] Jede Aktualisierung eines Dokuments erzeugt dabei eine neue Revision, welche sich aus einem Counter (Präfix) und, getrennt durch einen Bindestrich, dem MD5-Hashwert des Inhalts (Postfix) zusammensetzt. [vgl. 36] [vgl. 37] Dieser Postfix wird bei Apache CouchDB über den Binärwert verschiedener Eigenschaften des betreffenden Dokuments berechnet.

Ein Konflikt entsteht entsprechend dem MVCC -Konzept beim Zurückschreiben eines Dokuments, wobei die Revisions-ID nicht mit der aktuellen in der Datenbank übereinstimmt. Bei Änderungen seitens eines Benutzers wird die Änderung beim Konfliktfall zurückgewiesen. Die Anwendung muss in diesem Fall das Dokument aktualisieren, wonach die Änderungen erneut vorgenommen werden können. Zudem kann ein Konflikt mit der Replikation auftreten.

Ebenfalls kann ein Versionskonflikt in Zusammenhang mit der Replikation auftreten. Haben Quell-Knoten und Ziel-Knoten beide dasselbe Dokument (gleiche Dokument-ID), jedoch unterschiedliche Revisions-ID, so entsteht ein Konflikt im Rahmen der Replikation. In diesem Fall werden beide Versionen übernommen, respektive nicht gelöscht, wobei die Version als aktuelle Version bestimmt wird, die die höchste Anzahl an älteren Versionen besitzt (längste Historie, größerer Präfix in der Revisions-ID), und die andere ihr Vorgänger wird. Diese neuen Informationen werden dann wiederum repliziert. Durch diese Form der Konfliktlösung gehen keine Daten verloren, jedoch kann man sich auch nicht sicher sein, dass die Version eines Dokuments, die man von einem Knoten einer verteilten Datenbank abfragt, auch datenbankweit die aktuellste Version ist. Hierin äußert sich der Aspekt des Eventually-Consistent (und auch des Soft States), basierend auf dem BASE -Konsistenzmodell, welcher bei Apache CouchDB verwendet wird.

Skalierung

In der aktuell vorliegenden Version 1.2.0 verfügt CouchDB noch über keine eigene Unterstützung von Partitionierung bzw. Sharding, in Version 1.3.0 ebenfalls nicht.

Um diese Funktionen dennoch in Anspruch zu nehmen, muss das Open-Soruce-Framework "CouchDB Lounge" verwendet werden. Bei "CouchDB Lounge" handelt es sich um ein proxybasiertes Framework, das zur Partitionierung und Clusterung von CouchDB-Systemen dient. Im Zusammenhang mit diesen Verfahren spricht man auch von der horizontalen Skalierbarkeit von Datenbanksystemen. Neben den Funktionalitäten Partitionierung und Clustering wird auch das sogenannte Consistent-Hashing unterstützt. Das gewährleistet eine anwendungsbezogene Skalierung über verbundene CouchDB-Cluster.

CouchApps

CouchDB ist nicht nur eine dokumentenorientierte Datenbank, sondern auch ein Webserver. Mit CouchDB lassen sich HTML-Seiten mit JavaScript problemlos darstellen. Unter einer CouchApp versteht man eine durch CouchDB ausführbare Webapplikation. Wie schon bei Views werden zur Speicherung von CouchApps Design Documents verwendet. Die bekannteste CouchApp ist das Web-Interface Futon, welches CouchDB beiliegt und auf dem CouchDB-Server ausgeführt wird.

Zugriffskontrolle

Für den Schutz vor unberechtigten Zugriffen bietet CouchDB ein einfaches Modell der Zugriffskontrolle. Hier wird zwischen den folgenden Bereichen unterschieden:

• Administratorzugriff
• Lesende Zugriffe
• Update Validierung

Neue Accounts können von Administratoren angelegt werden. Diese haben ebenfalls den Zugriff auf die sogenannten design documents, in denen sich neue Views auf Basis von MapReduce-Funktionen in Form von JavaScript abbilden lassen. Mit Hilfe von erstellbaren Nutzerlisten kann die Leseberechtigung von Dokumenten eingeschränkt werden. Die Validierung der Schreibrechte erfolgt hier ebenfalls im Hintergrund durch entsprechende JavaScript-Funktionen.

Abschließende Betrachtung

Vorteile

• Schemafreiheit
• Integrierter Webserver
• Kommunikation mit HTTP
• Einfache Anbindung an Web-Anwendungen
• Keine separaten Schnittstellen nötig
• Unter Apache Lizenz 2.0 verfügbar
• Nachträgliche Änderung von Dokumentenformaten möglich
• Verteilte Datenbank, allerdings fragwürdiges Prädikat "verteilt" (auch im Sinne des Akronyms "Cluster of ...") nur über Replikation [vgl. 39] [vgl. 42] [vgl. 43]
• Sehr hohe Verfügbarkeit
• Wird weiterentwickelt
• Views um Join-Funktionalität zu bieten
• gut bei Fokus auf Versionierung [vgl. 40]
• PHP unterstützt Apache CouchDB als Speichermedium (Clustering des PHP App Servers) [vgl. 44]

Nachteile

• Noch nicht völlig ausgereift
• Einige Features verteilter Datenbanken werden noch nicht unterstützt
• MapReduce bei aufwendigen Abfragen ggf. komplizierter als SQL
• Bietet nicht die Abfragemöglichkeiten relationaler DBMS
• Struktur der Dokumente erfordert Disziplin des Anwenders
• Umdenken vom relationalen Konzept nötig
• Sehr spezifisch auf Webanwendungen zugeschnitten
• Bug in Version 1.0 konnte zu Datenverlust führen, seit 1.0.1 behoben
• Im Zusammenhang mit den Map/Reduce-Funktionen sind JavaScript-Kenntnisse erforderlich
• kein Caching, alle Schreibvorgänge direkt auf Disk [vgl. 39]
• DB's können sehr groß werden, manuelle Datenkomprimierung nötig [vgl. 39] [vgl. 40] [vgl. 41] [vgl. 42] [vgl. 43]
• Erstellung von Views im Vergleich zu SQL -Queries zeitaufwändig [vgl. 41]
• vergleichsweise hohe Latenz aufgrund HTTP Document API [vgl. 42] [vgl. 43]
• keine offizielle Unterstützung partieller Updates von Dokumenten [vgl. 39], zukünftig allerdings geplant
• an sich nur für gelegentliche Veränderung von Daten [vgl. 40]

Fazit:

Für das spezifische Anwendungsfeld der Webanwendungen scheint CouchDB durchaus gut geeignet zu sein. Sollte es sich hauptsächlich ein System zur Eingabe und Speicherung von Daten handeln, eignet sich CouchDB bzw. allgemein eine dokumentenorientierte Datenbank. Ist häufiges Bearbeiten der Daten, etwa in Form von Berechnungen nötig, oder werden oft komplexe Anfragen durchgeführt, empfiehlt sich eher ein relationales System, da durch SQL ein entsprechend mächtiges Werkzeug geboten wird und in CouchDB die meisten Funktionen selbst programmiert werden müssen.
CouchDB ist kein Konkurrent für herkömmliche relationale DBMS und versucht auch nicht als ein solcher aufzutreten. Die Anwendungsbereiche der Systeme sind schlicht und einfach völlig verschieden. Durch seinen webanwendungsnahen Aufbau bringt CouchDB für Anwender in diesem Bereich eine Menge Komfort mit, so dass die Erwägung, CouchDB zu nutzen, durchaus berechtigt erscheint.

Literatur:

• Edlich et. Al.(2011), 2.Aufl.: „NoSQL – Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken „ Carl Hanser Verlag, München
• Lennon, J. (2009): „Beginning CouchDB" Springer Verlag, NewYork

• Anderson, C., „CouchDB: The Definitive Guide“, O‘Reily Books, http://guide.couchdb.org/index.html, 05/2011

• "The Apache CouchDB Project", http://couchdb.apache.org/ , 05/2011
• "CouchDB Wiki", http://wiki.apache.org/couchdb/FrontPage, 05/2011

• offizielle Curl-Website: http://curl.haxx.se/, 05/2012
• Gull, Clemens (2010): „Web-Applikationen entwickeln mit NoSQL“ Franzis Verlag, München
• [3] The Apache Software Foundation; 2004; Apache License, Version 2.0; http://www.apache.org/licenses/LICENSE-2.0, 24.06.13
• [4] Open Source Initiative (OSI); 2006; Open Source Licenses; http://opensource.org/licenses, 24.06.13
• [5] CouchApp.org; 2013; What the HTTP is CouchApp?; http://couchapp.org/page/what-is-couchapp, 24.06.13
• [6] Couchbase; 2013; Couchbase vs. Apache CouchDB, A comparison of two open source NoSQL database technologies; http://www.couchbase.com/couchbase-vs-couchdb#Couchbase vs. Apache CouchDB Technical Comparison Chart, 24.06.13

• [8] Damien Katz; 2005; What is Couch?; http://damienkatz.net/2005/12/what_is_couch.html, 24.06.13

• [10] Jan Lehnardt; 2013; The State of CouchDB; http://planet.couchdb.org/#who_am_i, 24.06.13
• [12] Curt Monash; 2011; Membase and CouchOne merged to form Couchbase; http://www.dbms2.com/2011/02/08/couchbase-membase-couchone-couchdb, 24.06.13
• [13] Refuge; 2013; Alternative Apache CouchDB distribution; http://rcouch.org, 24.06.13
• [14] Randall Leeds; 2010; Lounge; http://tilgovi.github.io/couchdb-lounge, 24.06.13
• [15] Cloudant; 2013; BigCouch; http://bigcouch.cloudant.com, 24.06.13
• [17] DataSift Developers; 2013; CouchDB; http://dev.datasift.com/docs/push/connectors/couchdb, 24.06.13
• [20] Dr. Thomas Schank; 2010; NoSQL, Folie 24; http://drtom.ch/talks/2010/12/NoSQL/talk-plain.html, 24.06.13
• [21] Sebastian Wehrmann; 2008; Effiziente Ad-Hoc-Abfragen in Objektdatenbanken am Beispiel der ZODB, Diplomarbeit, Seite 11; http://www.qucosa.de/fileadmin/data/qucosa/documents/5601/data/diplomarbeit.pdf
• [22] Rick Cattell; 2010; Scalable SQL and NoSQL Data Stores, Seite 16, Seite 27; http://www.sigmod.org/publications/sigmod-record/1012/pdfs/04.surveys.cattell.pdf
• [23] Mehul Bhatt; 2012; mod_couch, Description; https://github.com/mehulsbhatt/mod_couch#description, 24.06.13
• [25] Andreas Wenk, Till Klampäckel; 2011; CouchDB, Das Praxisbuch für Entwickler und Administratoren, Grundlegendes zu Dokumenten, Galileo Computing, Seite 77; http://www.galileocomputing.de/download/dateien/2598/galileocomputing_couchdb.pdf
• [27] Apache; 2013; Apache CouchDB 1.3 Manual, Design Docs; http://docs.couchdb.org/en/latest/ddocs.html, 24.06.13

• [33] Randy Guck; 2012; Survey distributed databases; http://www.toadworld.com/products/toad-for-cloud-databases/w/wiki/308.survey-distributed-databases.aspx#NoSQL_Databases, 24.06.13
• [34] DWBI Concepts; 2012; What is NoSQL, Key-value stores; http://www.dwbiconcepts.com/data-warehousing/18-dwbi-basic-concepts/102-nosql-database-tutorial.html, 24.06.13
• [37] csm Concern; 2012; How CouchDB Revision Number Generation Works; http://csm.tumblr.com/post/18963100318/how-couchdb-revision-number-generation-works, 24.06.13
• [38] Boddin D., Franke P., Beckers J., Wiatr S.; 2012; Migration von einem relationalen Datenbankmodell zu NoSQL, Vector Clocks; http://winfwiki.wi-fom.de/index.php/Migration_von_einem_relationalen_Datenbankmodell_zu_NoSQL#Vector_Clocks, 24.06.13
• [39] Mathias Meyer; 2010; 10 Annoying Things About CouchDB; http://www.paperplanes.de/2010/7/26/10_annoying_things_about_couchdb.html, 24.06.13
• [40] Kristóf Kovács; 2013; Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Couchbase vs Neo4j vs Hypertable vs ElasticSearch vs Accumulo vs VoltDB vs Scalaris comparison; http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis, 24.06.13
• [41] Marian Steinbach; 2011; What I learned about CouchDB; http://www.sendung.de/2011-11-11/what-i-learned-about-couchdb, 24.06.13
• [42] John Wood; 2012; Getting off the Couch(DB); http://blog.signalhq.com/2012/01/24/getting-off-the-couchdb, 24.06.13
• [43] MAHESH PAOLINI-SUBRAMANYA; 2012; COUCHDB - BLESSINGS AND CURSES; http://dieswaytoofast.blogspot.de/2012/02/couchdb-blessings-and-curses.html, 24.06.13
• [44] Adam Strohl; 2011; Why I Switched to CouchDB for Web Applications; http://www.ateamsystems.com/blog/Why-Switch-To-CouchDB-For-Web-Applications, 24.06.13

Weiterführende Links:

• http://couchapp.org/page/index - Bietet Hilfestellung bei der Entwicklung von CouchApps
• http://labs.mudynamics.com/wp-content/uploads/2009/04/icouch.html - Eine interaktive Version von CouchDB, in der z.B. online mit MapReduce experimentiert werden kann

Kategorie: Neue DB-Entwicklungen, Dokument-DB, NoSQL, C