Donnerstag, 9. September 2010


Artikel

Dezember 2009 | Artikel

NoSQL – Schöne neue Welt? Fortsetzung, Teil 2

Teil 1   Teil 2   Teil 3   

CouchDB – Time to relax

Apache CouchDB ist eine dokumentenbasierte Datenbank, die in der Programmiersprache Erlang geschrieben ist. Die Abfrage und das Indizieren der Dokumente geschehen mit MapReduce via JavaScript. Der geistige Vater Damien Katz, einst Entwickler bei Lotus Notes, arbeitet derzeit für IBM an dem Apache-CouchDB-Projekt. Die Installation ist allerdings nicht einfach, verläuft aber auf dem Linux/Mac-OS-System in der Regel problemlos. Das Besondere an CouchDB ist, dass sämtliche Dokumente (schemafrei) in der JSON-Syntax gespeichert werden und der Zugriff auf die Datenbank via HTTP/REST APIs erfolgt:

  1. curl -X POST http://woody:5984/articles -d
  2. '{"article":"NoSQL im JavaMagazin", "authors":["Warzecha", "Wessendorf"]}'

Mit dem Unix-Kommandozeilentool curl wird hier ein Dokument in der Datenbank articles angelegt. Im Erfolgsfall bekommt man ein weiteres JSON-Dokument zurückgeliefert:

  1. {"ok":true,"id":"3aa2d6b50934b1a7fa9064d8b9789447",
  2. "rev":"1-8f4e988fffd0787228bbe9a33909633e"}

Die ID des neuen JSON-Dokuments lässt sich nun für die Abfrage der Daten über HTTP/REST nutzen: curl -X GET http://woody:5984/articles/3aa2d6b50934b1a7fa9064d8b9789447. Das Ergebnis sieht anschließend wie folgt aus:

  1. {"_id":"3aa2d6b50934b1a7fa9064d8b9789447",
  2. "_rev":"1-8f4e988fffd0787228bbe9a33909633e",
  3. "article":"NoSQL im JavaMagazin","authors":["Warzecha","Wessendorf"]}

Alternativ können Dokumente/Datenbanken mit dem webbasierten Administrationswerkzeug Fluton (Abb. 1) verwaltet werden, dass durch seine Oberfläche überzeugt. Fluton bietet ebenfalls einen erstklassigen Support für die Erstellung von map/reduce-Funktionen. Der eingebaute Support für HTTP/REST bietet einem Java-Entwickler wiederum weitere Möglichkeiten, um mit CouchDB zu kommunizieren. Statt der direkten Nutzung der JDK-Klasse HttpURLConnection, stehen verschiedene APIs wie das hier benutzte jcouchdb-Projekt bereit:

  1. Database db = new Database("woody", "articles");
  2. Map doc = new HashMap();
  3. doc.put("article", "NoSQL im JavaMagazin");
  4. doc.put("authors", new String[] {"Bartosch Warzecha", "Matthias Wessendorf"});
  5. db.createDocument(doc);

Mit einer einfachen Syntax ermöglicht jcouchdb den Zugriff auf die Daten. Innerhalb von fünf Zeilen wird hier ein ähnliches Dokument erstellt wie bereits zuvor mit curl. Ein schöner Aspekt der jcouchdb ist die im Projekt enthaltene Beispielandwendung Hood, die den Umgang mit dem API veranschaulicht. CouchDB selbst ist ein sehr fortgeschrittenes NoSQL-System, das aktuell in einer BETA-Version (0.10.x) angeboten wird. Mit der Mozilla Foundation und der Ubuntu-9.10-Version hat das Apache-CouchDB-Projekt zwei populäre "Kunden". Für die CouchDB gibt es bereits verschiedene Publikationen, beispielsweise das "CouchDB: The Definitive Guide" -Buch, das auch online zugänglich ist. Es existieren bereits Unternehmen, die im Umfeld des Apache-CouchDB-Projekts Hosting, Schulungen und kommerziellen Support anbieten.

Teil 1   Teil 2   Teil 3   

Kommentare

Gravatar Peter Neubauer 01.12.2009
um 18:55 Uhr
Hallo,
guter Beitrag! Wenn man sich JCR und Apache Jackrabbit ansieht, sollte man nicht vergessen, dass gerade Graphen-datenbanken wie http://www.neo4j.org order http://www.sones.de sehr gut mit den hochvernetzten Datenstrukturen eines CMS zurechtkommen, während BigTable, CouchDB und Cassandra Verknüpfungen zwischen den "Shard"-Einheiten (Dokumente bei CouchDB) nur schlecht hantieren und sich mehr für Datenmengen eignen die sich leicht in viele unabhängige Bestandteile aufsplitten lassen.

Disclaimer: Ich bin Teils des Neo4j - Teams.
#zitieren
Gravatar Martin Wildam 07.12.2009
um 16:30 Uhr
Ich habe lange über diese Bewegung nachgedacht und auch einige Systeme ausprobiert, die über ganz freie Indexierungssysteme arbeiten - Lucene zähle ich da auch dazu.

Mir kommt vor, daß es vielen zu mühsam ist, eine Struktur/Ordnung in ihre Daten zu bekommen und da ist es angenehm, wenn ein System eigentlich alles und irgendwie "verkraftet". Das ganze System eignet sich dann hervorragend als Datenfriedhof.

Auf der anderen Seite ist es mir klar, daß manches sich nur schwer in komplexe Strukturen einordnen lässt...

Sehr amüsant dazu: http://entwickler.de/zonen/portale/psecom,id,99,news,52764.html
#zitieren
Gravatar Arne Kriedemann 02.02.2010
um 12:53 Uhr
Sehr schöner Artikel mit guter Übersicht über dieses doch nocht recht neue Feld der nicht-relationalen Datenbanken.
Auch den Artikel über die Gewährleistung der Konsistenz fand ich sehr interessant und gut geschrieben, auch wenn man etwas von Datenbanktechnik verstehen sollte, um ihn zu lesen.
Vielen Dank!
Greets, Arne
#zitieren
Gravatar Paul 15.03.2010
um 15:31 Uhr
Ich hab durch diesen Artikel das erste Mal etwas von diesem System gehört. Ich denke das eine Schnittstelle zusätzlich sich als sehr sinnvoll erweisen kann. Ich werde morgen mal meinem Professor darauf ansprechen. #zitieren
Gravatar LeMue 31.03.2010
um 10:32 Uhr
Na eigentlich sind nicht relationale Datenbanken mit proprietärer Indizierung doch ein alter Hut s. ISAM-Dateien und BTrieve. Einzig wird jetzt die Möglichkeit erwogen abhängig vom Anwendungsfall wieder auf diesen alten Ansatz zurückzugreifen. #zitieren
Gravatar TeBone 09.07.2010
um 11:59 Uhr
Btrieve und andere ISAM Systeme haben lange zeit einen negativen touch bekommen. Aufgrund der Anforderungen die heute stehen kann man es sich einfach nicht mehr leiste "nur" auf ein paradigma zu setzen. Gerade wenn heute Diskussionen auf Management Ebene geführt werden kommt oft die Frage "kann das SQL". Wir bei uns haben mehr und mehr spezialisierte Lösungen bei den Kunden. Wer heute zum Beispiel über HighFrequenzyTrading nachdenkt (http://www.dbcoretech.com/?p=129) der verwendet eventuelle SQLite Broker und Börsen können das nur noch mit Systemen wie VoltDB realisieren. Anders ist da die Frage bei DataWarehousing, hier sind es die Analytischen Fragen die im Vordergrund stehen. #zitieren
Gravatar Martin Wildam 09.07.2010
um 12:04 Uhr
Es ist doch immer dasselbe - da kommt irgendein "neues" Thema (oder auch älteres neu aufgeputzt) und immer wieder gibt es dann einen Schwarm von Leuten, die das dann überall als ultimative Lösung einsetzen wollen. Aber die Sachlage ist eben meist etwas genauer zu betrachten und die Anforderungen eben unterschiedlich. Da sind wir wieder bei der Hammer und Nagel-Geschichte... #zitieren
Gravatar RPR 10.07.2010
um 11:47 Uhr
Fakt ist, dass man bei Massendaten (schon immer) Probleme mit den traditionellen Datenbanken hat(te). Sie es:
- bei der Abfrage gigantischer Datenmengen,
- beim Massenimport oder
- beim ständigen Einfügen von Daten im laufenden Betrieb.

Und das schafft man eigentlich nur durch Skalierbarkeit auf mehr Festplatten bzw. Rechner mit Festplatten. Und das wiederum können bei trad. DBMS eigentlich nur extrem teure Systeme gut.

Eine "Systemart" zur Lösung wurde in dem Artikel noch nicht angesprochen: Column-oriented databases.
Und diese gibt es mit Vectorwise oder Calpont auch mit SQL-Frontend - und das wird IMHO die Zukunft in dem Bereich sein.
Sachen wie CouchDB könnte ich mir noch für Webfrickler vorstellen, die ohne Middleware arbeiten wollen.
#zitieren