NoSQL im Überblick

Seite 2: Key-Value-Stores, Spaltendatenbanken

Inhaltsverzeichnis

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.

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.

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:

(odi)