Einfache Skalierbarkeit ist nicht gerade eine Stärke der klassischen, meist relationalen Datenbanken. Immer öfter ließen sich Admins von der Kombination der agilen Eigenschaften der NoSQL-Systeme [1] überzeugen. Zu den in Tabelle 1 erwähnten Features gesellt sich eine sehr flexible Schemafreiheit, bei der eine NoSQL-DB, zum Beispiel in Dokumentdatenbanken, zwar das Format kennen muss, etwa Json. Aber den Inhalt, also die Daten, kann der Entwickler völlig frei definieren und ändern (NoSQL-Elastizität).
Ein alter Hut?
NoSQL-Datenbanken gibt es spätestens seit 1979, als Ken Thompson die erste Hash-DB schrieb. Dennoch explodierte der Einsatz von NoSQL erst mit dem Web 2.0. Systeme wie Googles Big Table, Amazon Dynamo oder Simple DB waren dabei die Vorreiter.
Die NoSQL-Definition der Uni Frankfurt [2] beschreibt die Kernpunkte: “NoSQL bezeichnet eine neue Generation von Datenbanken, die unter anderem nicht-relational, hochgradig verteilt, Open-Source-Software und horizontal skalierbar sind.”
Hinzu kommen noch einfache Replikation und Installation sowie ein einfaches API. Sie bieten Eventually Consistency [3] und setzen auf Basically Available, Soft-State and Eventual Consistency anstelle von Atomicity, Consistency, Isolation, Durability – kurz: auf BASE statt ACID [4]. Bei der Installation von NoSQL-Datenbanken wie Redis [5] dauerte es im Test gerade mal 38 Sekunden vom Download bis zur ersten Speicheroperation.
Viele Schnittstellen
Abbildung 1 zeigt die Bedeutung und Verbreitung der Interfaces. NoSQL-Datenbanken bieten meist REST-Schnittstellen. Zum Zugriff mit fast allen Programmiersprachen ist Apache Thrift sehr beliebt, fast alle NoSQL-DBs bringen aber auch APIs für eine Vielzahl anderer Programmiersprachen. Mit denen lassen Programmierer besonders in Key-Value-Datenbanken wie Redis einfache Get-Put-Operationen ausführen. Zur Abfrage dient dann meist das etwas komplexere Map-Reduce-Verfahren [6].

Abbildung 1: Nur ein Ausschnitt: Es gibt mittlerweile zahlreiche NoSQL-Datenbankprojekte. Der Definition nach müssen sie Open-Source-Software sein.
Das Datenmodell besteht in der Regel aus einer großen Spaltenfamilie, einer Dokumenten-Datenbank (meist Json), Key-Value- oder auch Graphen-basierten Datenbanken, die gerade einen neuen Frühling erleben. Entwickler von NoSQL-DBs entscheiden sich in der Regel dafür, die Datenkonsistenz etwas zu lockern, die DBs aber immer verfügbar zu halten, und zwar durch Replikate auf anderen Rechenknoten (CAP-Theorem), was sie meistens mit Consistent Hashing zu erreichen suchen.
Bei der Persistenz setzen Admins zunehmend auf eine primäre Cache- und erst sekundär auf Platten-Speicherung. Viele NoSQL-Systeme erlauben es aber, für die tatsächliche Persistenz auch beliebige Datenbanken (auch relationale) zu konfigurieren. Hier wachsen echte Allrounder heran. (mfe)
| Infos |
|---|
| [1] NoSQL Database: [http://nosql-database.org]
[2] NoSQL an der Uni Frankfurt: [http://nosqlfrankfurt.de] [3] Eventually Consistency: [http://queue.acm.org/detail.cfm?id=1466448] [4] BASE oder ACID: [http://blog.namics.com/2009/05/skalierbare-dat.html] [5] Redis: [http://code.google.com/p/redis] [6] Map Reduce: [http://en.wikipedia.org/wiki/MapReduce] |






