NoSQL im Überblick

Inhaltsverzeichnis

Der Aufstieg von NoSQL-Datenbanken stellt das traditionelle relationale Datenbankmodell als Lösung für alle Probleme in Frage – nicht nur in der Theorie, sondern auch in der Praxis. In seinem Kern bedeutet NoSQL allerdings keine grundsätzliche Ablehnung von SQL: NoSQL steht eher für "Not Only SQL" (nicht nur SQL) als für "No SQL" (kein SQL). Die neue Strömung greift interessanterweise Datenbankmodelle auf, die in der Vergangenheit aus verschiedensten Gründen in Vergessenheit geraten sind. Dabei erfolgt die Innovation in erster Linie durch praktische Entwicklungen – häufig auf der Basis von Open-Source-Software –, nicht in Form datenbanktheoretischer Überlegungen. NoSQL, das schon vorweg, ist jedoch kein Wundermittel für alle Datenbankansprüche.

Der derzeitige NoSQL-Trend bringt die relationalen SQL-Datenbank allerdings nicht zum ersten Mal unter Beschuss. In den neunziger Jahren zum Beispiel machten die objektorientierten Datenbanken von sich reden. Sie boten Entwicklern auf den ersten Blick einen Ausweg aus der mühseligen Konvertierung ihrer Datenobjekte in Reihen und Spalten. In der Praxis waren die Implementierungen von objektorientierten Datenbanken jedoch häufig sehr komplex und fragil, sodass desillusionierte Entwickler sich erneut auf die Suche nach besseren Möglichkeiten begaben. In der Folge entstanden die objektrelationalen Mapper (ORM), die einen Großteil der Konvertierungsarbeit von Datenobjekten zwecks Speicherung in einer SQL-Datenbank erledigten.

Die aktuellen NoSQL-Datenbanken haben einige Eigenschaften gemeinsam: Sie verzichten in der Regel auf die starren Schemata der Tabellen ihrer relationalen Pendants. Als schemafreie Datenbanken setzen sie auf flexiblere Techniken, um festzulegen, wie Daten gespeichert werden; oder sie überlassen das gleich komplett den Anwendungen. Namensgebend ist der Einsatz anderer Protokolle für die Kommunikation mit den Clients als SQL. Die Architektur vieler NoSQL-Datenbanken ist auf Skalierbarkeit ausgelegt, sodass sich große Datenbestände in einem Cluster aus Standardsystemen verwalten lassen, statt sie auf einem einzigen Superserver zu speichern.

Bei näherer Betrachtung lassen sich die verschiedenen NoSQL-Ausprägungen in vier Hauptkategorien aufteilen: dokumentenorientierte Datenbanken ("document stores"), Key-Value-Datenbanken, spaltenorientierte Datenbanken und Graphendatenbanken.

Dokumentenorientierte Datenbanken: CouchDB

Dokumentenorientierte Datenbanken speichern "Texte" von beliebiger Länge mit unstrukturierten Informationen und ermöglichen das Suchen auf Basis von Dokumentinhalten. Ein Beispieldokument wäre das Folgende:

"Vorname": "Wallace"
"Adresse": "62 West Wallaby Street"
"Interessen": ["Käse","Cracker","Mond"]

Die gespeicherten Dokumente müssen nicht die gleichen Felder enthalten: Eine Datenbankabfrage nach "Vorname" = "Wallace" würde nur Dokumente finden, die das Feld "Vorname" mit dem Wert "Wallace" enthalten. XML-Datenbanken sind dokumentorientierte Datenbanken mit semi-strukturierten Daten.

CouchDB ist ein typischer Vertreter der dokumentorientierten Gattung. Die Datenbank speichert Dokumente wie im obigen Beispiel. Abfragen – so genannte Views – definiert man in CouchDB mit Hilfe von Javascript-Funktionen. Sie erzeugen beim Aufruf Einträge in einem Index. Views können eine "Reduce"-Funktion enthalten, die die Suchergebnisse als sortierte Liste für weitere Filterungen oder Evaluierungen aufbereitet.

Die Views selbst werden auf dem Server als CouchDB-Dokumente abgelegt. Sie lassen sich jederzeit reaktivieren und aktualisieren. Durch dieses Vorhalten der Ergebnisse kann die Serverlast reduziert werden.

Als verteiltes Datenbanksystem mit einem effizienten Replikationsmechanismus zwischen verschiedenen Systemen lässt sich CouchDB gut skalieren. Die Replikation funktioniert dabei auch mit Systemen, die nicht immer online sind. Canonicals Speicherdienst Ubuntu One zum Beispiel setzt auf CouchDB, um Daten zwischen Client-PCs zu synchronisieren. Auch bei der BBC kommt die Datenbank als interne Datenablage für die diversen Webdienste des englischen Radio- und Fernsehsenders zum Einsatz.

Mehr Informationen zu CouchDB findet man in dem englischsprachigen CouchDB-Buch und auf der CouchDB-Website, die unter dem Dach der Apache Foundation beheimatet ist.

Graphen-Datenbanken: Neo4J

Eines der ressourcenintensivsten und kompliziertesten Dinge, die man in einer SQL-Datenbank speichern kann, ist die Beziehung zwischen verschiedenen Elementen – beispielsweise das Geflecht der Freunde, Follower etc. in einem sozialen Netz. Um eine Beziehung zu durchlaufen, können in einer SQL-Datenbank mehrere Abfragen erforderlich sein.

Graphen-Datenbanken legen den Fokus auf die Darstellung von Daten als Knotenpunkte und Beziehungen zwischen den Knoten. Neo4J ist ein Beispiel für diese Art von Datenbank. Statt herkömmlicher Datensätze erstellt man hier Knoten, die durch die Beziehungen, die man zwischen ihnen definiert, miteinander verknüpft werden. Ein Beispiel in Java-Code:

Node firstNode = graphDb.createNode();
Node secondNode = graphDb.createNode();
Relationship relationship = firstNode.createRelationshipTo(secondNode,MyRelationshipTypes.OWNS);

Hier werden zwei Knoten erstellt. Zwischen diesen beiden Elementen existiert eine Beziehung OWNS – "besitzt" –, die an anderer Stelle als einfaches Enum definiert ist.

Informationen zu den Knoten und ihre Beziehungen werden als Eigenschaften gespeichert:

firstNode.setProperty("name","Wallace");
secondNode.setProperty("name","Grommit");
relationship.setProperty("zahlt","Hundesteuer");

Der erste Knoten (Wallace) besitzt den zweiten Knoten (Grommit) – er zahlt Hundesteuer. Ausgehend von diesem einfachen Modell lassen sich leicht durchlaufbare Graphen von Beziehungen erstellen.

Ein anderes Beispiel für eine Graphen-Datenbank ist FlockDB, eine Schöpfung der Twitter-Entwickler. Sie wurde speziell dazu erstellt, aufzuzeigen, wer wem auf der Microblogging-Plattform folgt.

Graphen-Datenbanken spielen ihre Stärken bei der Darstellung von Elementen aus, bei denen die Beziehungen zueinander im Mittelpunkt stehen. Es lassen sich zwar auch nicht-beziehungsbezogene Informationen in einer Graphen-Datenbank speichern, doch stellt sich hier schnell die Frage, wie sinnvoll das ist.

Weitere Informationen zu Neo4J sind auf der Website des Projekts zu finden.

Key-Value-Stores, Spaltendatenbanken

Key-Value-Datenbanken: Redis

Key-Value-Stores sind vom Prinzip her noch einfacher: Ein bestimmter Schlüssel verweist auf einen Wert, der in seiner einfachsten Form eine willkürliche Zeichenkette sein kann. Key-Value-Datenbanken sind seit jeher Bestandteil von diversen Anwendungen, etwa in Form traditioneller Embedded-Datenbanken der Unix-Welt wie dbm, gdbm und Berkley DB. Ihre modernen NoSQL-Pendants laufen meistens als Standalone-Datenbankdienst und lassen sich über Web-Techniken wie REST ansteuern.

Key-Value-Stores lassen sich wiederum in zwei Untergruppen unterteilen: Die In-Memory-Variante behält die Daten im Speicher und sorgt dadurch für eine hohe Performanz. Die On-Disk-Versionen speichern ihre Daten direkt auf der Festplatte. In-Memory-Datenbanken bieten sich als verteilte Cache-Speichersysteme an; On-Disk-Datenbanken werden als Datenspeicher genutzt.

Redis ist ein Beispiel für eine On-Disk-Datenbank. Mit dem System können nicht nur einfache Strings gespeichert werden, sondern auch Listen, Sets und sortierte Sets. Redis hält das ganze Dataset im RAM vor, speichert es aber flexibel auf der Platte, wenn bestimmte Bedingungen erfüllt sind. Für jeden Datentyp, den Redis unterstützt, gibt es eine Serie von speziellen Befehlen, die mittels APIs für eine Reihe von Sprachen zur Verfügung stehen. Redis kommt unter anderem zum Einsatz bei Engine Yard, Github und Craigslist. Für mehr Informationen siehe die Redis-Website.

Spaltenorientierte Datenbanken: Cassandra

Eine typische SQL-Datenbank besteht aus Zeilen, wobei jede Zeile einen Datensatz mit verschiedenen Feldern repräsentiert. Für Menschen ist diese Sicht bequem. Sie passt zu der Art wie wir selbst Informationen speichern, zum Beispiel in einer Kartei. Wenn man jedoch eine Kartei als Beispiel nimmt, in der jede Karte einen Verkauf pro Vertriebsmitarbeiter enthält, und man möchte den Gesamtumsatz ermitteln, muss man sich jede einzelne Karte anschauen, das Verkaufsergebnis zur Gesamtsumme hinzuaddieren und zur nächsten Karte wechseln. Herkömmliche SQL-Datenbanken lassen sich durchaus für ein solches Vorgehen optimieren. Jedoch dauert der Vorgang umso länger, je mehr Daten es gibt.

Eine andere Möglichkeit wäre, die jeweilige Verkaufszahl für einen Mitarbeiter auf eine Karte zu notieren, sie aber gleichzeitig auch auf eine Liste mit Verkaufszahlen aufzunehmen. Dann müsste man nur die Zahlen auf dieser Liste zusammenrechnen um den Gesamtbetrag zu errechnen. Diese viel schnellere Taktik ist im Wesentlichen das, was bei einer spaltenorientierten Datenbank passiert: Sie speichert die Daten so, dass sie schnell und mit weniger I/O-Aktivität zusammengerechnet werden können. Spaltenorientierte Datenbanken werden daher gerne von Data-Mining- und Analyse-Programmen verwendet, bei denen diese Speichermethode für die üblichen Operationen optimal ist.

Cassandra, seit Anfang 2010 Top-Level-Projekt bei Apache, ist eine Mischung aus dem spaltenorientierten und dem Key-Value-Ansatz. Das Ergebnis ist eine dezentralisierte und "letztendlich konsistente“ verteilte Datenbank.

Cassandra wurde ursprünglich von Facebook entwickelt, wird inzwischen jedoch als Apache-Projekt weiterentwickelt und ist als hoch skalierende, verteilte Datenbank unter anderem bei Digg, Twitter und Reddit im Einsatz. Cassandras Spalten haben einen Namen, einen Wert und einen Zeitstempel. Die Spalten lassen sich – analog zu einer Tabelle in einer relationalen Datenbank – als sogenannte Spaltenfamilien gruppieren. Spalten können auch als "Superspalte" gekennzeichnet werden. Damit lassen sie sich nicht nur nach Schlüsselnamen, sondern auch nach Zeitstempel sortieren.

Durch das Hybrid-Modell und die gute Skalierbarkeit bietet sich Cassandra für Situationen an, in denen große, sich ständig ändernde Datenmengen gespeichert werden sollen. Das beste Beispiel hierfür dürften die bereits genannten sozialen Netzwerke sein. Mehr Informationen zu Cassandra findet man auf der Projekt-Website.

Fazit: Was ist also eine NoSQL-Datenbank?

Wie die obigen Beispiele zeigen, spielen NoSQL-Datenbanken ihre Stärken vor allem in bestimmten Bereichen aus. Dazu gehören der flexible Umgang mit variablen Daten (dokumentorientierte Datenbanken), das Abbilden von Beziehungen (Graphen-Datenbanken) oder auch die Reduzierung einer Datenbank auf einen Behälter für Schlüssel-Werte-Paare (Key-Value-Datenbanken).

Für traditionelle Speicheranwendungen wird das relationale SQL-Modell noch lange Zeit maßgebend sein. Zum Teil durch ihr quelloffenes Entwicklungsmodell, zum Teil auch durch die Tatsache, dass sie in der Praxis für die Praxis entstanden sind, können die schnell besser werdenden NoSQL-Datenbanken aber eine gute Alternative oder Ergänzung sein.

SQL-Datenbanken haben Vorteile, wenn es auf ACID (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit) und relationale Fähigkeiten ankommt. In vielen Bereichen sind sie daher nach wie vor die erste Wahl. Auch steht die Entwicklung von SQL nicht still: So implementiert Ingres zum Beispiel die VectorWise-Technologie in seine SQL-Datenbank, um damit im Bereich Datenanalyse einen Vorsprung gegenüber spaltenorientierten Datenbanken zu erlangen.

Viele NoSQL-Datenbanken, etwa CouchDB und Cassandra, weichen die Konsistenzgarantien ein Stück weit auf und gewinnen dafür Vorteile, was die Skaliernbarkeit angeht. Andere sind, wie etwa die Graphen-Datenbanken, auf die Speicherung spezieller Daten optimiert, die sich in relationen Datenbanksystemen nur mühsam abbilden lassen.

So mischen die NoSQL-Systeme den Datenbankmarkt auf – oft auf Techniken, die lange Zeit ignoriert wurden, weil sie nicht in das Schema von SQL passten. Für das Datenspeicher-Ökosystem sind die neuen Entwicklungen auf jeden Fall ein Gewinn.

Siehe dazu auch:

• NoSQL Databases, eine Übersicht von NoSQL-Datenbanken
• CouchDB verlässt Beta-Status
• CouchDB – angesagter Vertreter der "NoSQL"-Datenbanken
• [-–] ein Artikel auf heise developer
• NoSQL-Datenbank Redis kommt zu VMware NoSQL-Datenbanken: Apache Cassandra 0.6 integriert Hadoop, Twitter veröffentlicht FlockDB

(odi)