Donnerstag, 24. Mai 2012


Artikel

Dezember 2009 | Artikel

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

Teil 1   Teil 2   Teil 3   

Apache Cassandra

Das Cassandra-Projekt ist eine Art hybride, hoch skalierbare Open-Source-Datenbank. Das Projekt wurde von einem der Autoren des Dynamo-Papiers entworfen und 2008 von Facebook an die Apache Software Foundation übergeben. Sie basiert auf Googles BigTable-Datenmodel, wobei sich die Infrastruktur an dem Dynamo-Papier orientiert. Da die Daten in Spalten gespeichert werden, besitzt Cassandra etwas mehr Struktur als einfache Key/Value-Datenbanken.

Durch die Verwendung einer Java-API ist der Einsatz für Java-Entwickler intuitiv. Nach dem Start der Datenbank kann der Benutzer beliebige Daten über eine geöffnete Verbindung mit dem folgenden Aufruf speichern:

  1. client.insert("Keyspace1",key_user_id,
  2. new ColumnPath("column_family1", null, "artikel".getBytes("UTF-8")),
  3. "NoSQL Artikel".getBytes("UTF-8"),timestamp, ConsistencyLevel.ONE);

Über den Client werden die Daten anhand einer frei definierbaren key_user_id, eines Zeitstempels sowie des ConsitencyLevels (von asynchron im Hintergrund bis "streng" konsistent) in einer Column mit dem Namen artikel, die zu dem Keyspace Keyspace1 gehören, gespeichert.

Ein Keyspace stellt dabei eine Ansammlung von Tabellen dar, ähnlich eines Schemas oder einer Datenbank in RDBMS. Zu einem Keyspace gehören so genannte Column Families, die in etwa den Tabellen eines RDBMS entsprechen. Zu den Column Families wiederum gehören Columns, wie in unserem Beispiel die Column-Artikel, die den Spalten einer relationalen Datenbanktabelle entsprechen. Diese sind allerdings für jeden Datensatz einer Column Family frei definierbar. Eine sehr gute Einführung in das vollständige Datenmodel von Cassandra bietet. Mit dem folgenden Aufruf kann anschließend auf die gespeicherten Daten zugegriffen werden:

  1. ColumnPath path = new ColumnPath("column_family1", null,
  2. "artikel".getBytes("UTF-8"));
  3. client.get("Keyspace1", key_user_id, path, ConsistencyLevel.ONE));

Nach dem Erstellen des columnPath kann durch die Angabe der key_user_id, des ConsistencyLevels und des Keyspace auf die Daten zugegriffen werden. Das Cassandra-Projekt befindet sich noch in einer relativ frühen Phase, sodass die Strukturen und die API durchaus noch größere Änderungen erfahren könnten.

Fazit und Ausblick

Die NoSQL-Bewegung ist kreativ – keine Frage. Dieser Artikel konnte lediglich auf einige Aspekte weniger Systeme eingehen. Allerdings kann man bereits daran wunderbar erkennen, wie im Augenblick zahlreiche NoSQL-Storage-Systeme entstehen. Ein bisschen erinnert dieser Trend an die Geschichte der (Java-)Webframeworks. Böse Zungen behaupten, dass jeder, der nicht 100%ig mit dem vorhandenem zufrieden ist, sich direkt sein eigenes System schreibt.

Fakt ist, dass die NoSQL-Bewegung am Anfang steht und eine Konsolidierung auch hier eintreten wird. Die zahlreichen Projekte sind teilweise sehr fortgeschritten, z. B. Jackrabbit oder CouchDB. Andere stecken jedoch noch in den Kinderschuhen, beispielsweise Apache Cassandra oder HBase (Unterprojekt von Apache Hadoop). Trotzdem werden diese Systeme bereits in produktiven Umgebungen wie Digg.com, Twitter oder Rackspace eingesetzt. Ebenfalls basiert der Datastore von Googles AppEngine auf einer Bigtable-Implementierung. Die Zukunft dieser neuen Bewegung bleibt spannend. Die Ideen der jungen Systeme sind innovativ und es macht Spaß, mit ihnen Anwendungen und Prototypen zu entwickeln.

Bartosch Warzecha ist Software Engineer bei dem IT-Dienstleistungs- und Beratungsunternehmen adesso AG. Er beschäftigt sich mit der Entwicklung von JEE-Anwendungen.

Matthias Weßendorf ist PMC Chair von Apache MyFaces. Beruflich beschäftigt er sich mit Themen rund um das „Next Generation Web“. Matthias blogt regelmäßig auf http://matthiaswessendorf.wordpress.com (Twitter: @mwessendorf).

  1. http://www.allthingsdistributed.com/2008/12/eventually_consistent.html
  2. http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/
  3. http://labs.google.com/papers/bigtable.html
  4. http://hadoop.apache.org/hbase/
  5. http://www.hypertable.org/
  6. http://riak.basho.com/
  7. http://s3.amazonaws.com/AllThingsDistributed/sosp/amazon-dynamo-sosp2007.pdf
  8. http://incubator.apache.org/cassandra/
  9. http://jackrabbit.apache.org
  10. http://www.oracle.com/technology/products/berkeley-db/index.html
  11. http://www.erlang.org/
  12. http://labs.google.com/papers/mapreduce.html
  13. http://www.infoq.com/interviews/CouchDB-Damien-Katz
  14. http://wiki.apache.org/couchdb/Getting_started_with_Java
  15. http://code.google.com/p/jcouchdb/
  16. https://mozillalabs.com/raindrop/2009/10/22/introducing-raindrop/
  17. http://damienkatz.net/2009/10/koala_on_the_loose.html
  18. http://books.couchdb.org/relax/
  19. http://couchio.com/
  20. http://cloudant.com/
  21. http://arin.me/code/wtf-is-a-supercolumn-cassandra-data-model
  22. http://en.wikipedia.org/wiki/Nosql
  23. http://googleappengine.blogspot.com/2009/02/back-to-future-for-data-storage.html

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