NoSQL – Jenseits der relationalen Datenbanken

Jochen Schnelle

Futon, die Weboberfläche von CouchDB

Key-Value Stores

Key-Value Stores, in der Kurzform auch nur KV-Store genannt, speichern Daten in Form von Schlüssel-Werte-Paaren. Jeder Schlüssel kann ein beliebiger, aber eindeutiger (=einmaliger) String sein. Was als Wert zulässig ist, hängt vom verwendeten KV-Store ab. Zulässig ist immer ein String; einige Programme unterstützen aber auch binäre Daten, Listen und Sets. Auf eine relationale Datenbanken übertragen kann man sich KV-Stores als eine Datenbank mit genau einer zweispaltigen Tabelle vorstellen. Die erste Spalte enthält den Schlüssel, welcher auch der Index ist, die zweite Spalte speichert den Wert.

Schaut man auf die Homepage der diversen KV-Stores, so fällt auf, dass so gut wie alle Benchmarkergebnisse auf die Startseite verlinken. Dies ist insofern bemerkenswert, dass man bei relationalen oder dokumentenorientierten Datenbanken dafür in der Regel tiefer in die Homepage hinabsteigen muss – wenn überhaupt Benchmarks angegeben werden. Der Grund hierfür ist aber relativ simpel: KV-Stores sind schnell, sehr schnell. Eine 6-stellige Anzahl an Schreib-/Leseoperationen pro Sekunde ist nicht unüblich – und das auf normaler Hardware, also nicht auf speziellen Datenbankservern. Manche KV-Stores sind beim Schreiben sogar schneller als beim Lesen, was bei relationalen und dokumentenorientierten Datenbanken nie der Fall ist. Auch hier ist der Grund recht offensichtlich: KV-Stores haben aufgrund der einfachen Struktur sehr wenig Overhead beim Zugriff auf die Datenbank, im Gegensatz zu den beiden anderen Datenbanktypen. Es gibt keine Verwaltungstabellen (oder Dokumente), die die Datenbank im Hintergrund aktuell halten muss, es müssen keine Indexe aktualisiert werden usw. Bei Schreiboperationen in einem KV-Store wird im günstigsten Fall nur geprüft, ob der zu schreibende Schlüssel schon existiert und dann das neue Schlüssel-Werte-Paar ans Ende der Datenbank angehängt.

Nutzung von Key-Value Stores

KV-Stores eigenen sich besonders für Anwendungen, wo die Daten gut in Schlüssel-Werte-Paaren organisiert werden können. Dies ist z.B. bei Microblogging-Diensten der Fall. Hier kann der Schlüssel z.B. eine Kombination aus fortlaufender Nummer des Beitrags, Benutzername und Zeitstempel sein. Ein sehr gutes und absolut lesenswertes Beispiel findet man in der Dokumentation von Redis, welches weiter unten noch vorgestellt wird. In diesem Beispiel wird sehr anschaulich und nachvollziehbar erklärt, wie man die Daten für einen Twitter-Klon sinnvoll und effektiv in einem Key-Value Store organisiert. Ein weiterer Vorteil ist auch hier die Geschwindigkeit von KV-Stores. Viele quasi-parallele Schreib- und Lesezugriffe sind kein Problem.

Aber der Einsatz von KV-Stores ist natürlich nicht auf Microblogging limitiert. Andere denkbare Anwendungen sind z.B. Notizbücher, bei denen der Schlüssel die Überschrift (oder der Zeitstempel) der Notiz ist und der Wert die Notiz an sich. Im gewerblichen Umfeld können KV-Stores z.B. dafür genutzt werden, Prüfwerte einer Serienfertigung oder ähnliches zu speichern. Der Schlüssel ist dann die Seriennummer oder die fortlaufende Nummer des produzierten Produkts, der Wert die Prüfwerte. Aufgrund der Geschwindigkeit der Datenbank entsteht hier auch kein Stau beim Schreiben der Daten, selbst bei sehr schnellen Fertigungsprozessen nicht.

Was bei der Nutzung bei KV-Stores wichtig ist: Die Schlüssel müssen keine einfachen Textstrings (wie z.B. abc oder eintrag1) sein, sondern können ebenfalls ein Schema haben; gleiches gilt für den Wert. Dazu ein kurzes und einfaches Beispiel: Ein einfaches Blogsystem, bei dem mehrere Autoren schreiben, soll die Daten in einem KV-Store speichern. Im Schlüssel soll das Erstellungsdatum und der Vorname des Autors stehen, im Wert der Titel und der Text. Schlüssel und Wert könnten dann z.B. so aussehen:

Schlüssel:: 2010-6-23:Jochen
Wert:: KV-Stores|KV-Stores ist die Kurzform für Key-Value Stores...

Der Trick ist, dass man einfach ein beliebiges, aber eindeutiges Trennzeichen einfügt. In diesem Beispiel sind das der Doppelpunkt : im Schlüssel und das Pipe-Zeichen | im Wert. Nach dem Auslesen des Schlüssel- und Wert-Strings kann man diese dann einfach mittels der split-Funktion der genutzten Programmiersprache in zwei Strings aufteilen und weiter verarbeiten. Diese Methode des sprechenden Schlüssels wird auch im oben genannten Beispiel ausführlich erklärt.

Bei KV-Stores ist es nicht möglich, einen zu einem Wert zugehörigen Schlüssel suchen zu lassen. Es wird grundsätzlich immer ein Schlüssel abgefragt und der zugehörige Wert zurückgegeben.

Open-Source-Key-Value-Stores

Einer der ältesten, noch aktiv genutzten KV-Stores ist BerkeleyDB, welches heute zu Oracle gehört. BerkeleyDB kommt oft als eingebetteter KV-Store zum Einsatz oder dient im Hintergrund zum Speichern auf die Festplatte, während der vom Programm/Nutzer direkt angesprochene KV-Store im Speicher läuft. So ist z.B. MemcachedDB aufgebaut.

Ein Key-Value Store mit erweiterter Funktionalität und sehr aktiver Entwicklung ist Redis. Redis kann als Wert nicht nur Strings speichern, sondern auch Listen und Sets. Die Größe eines Werts kann bis zu 1 GB betragen, was für die meisten Fälle ausreichen sollte. Weiterhin beherrscht Redis Operationen mit Sets (z.B. Schnittmengen berechnen) und Sortierung von Listen und Sets nach vorzugebenden Kriterien. Praktisch ist auch, dass man Werte, sofern es sich um eine Ganzzahl handelt, um einen beliebigen Wert oder um eins erhöhen oder verringern kann. So lassen sich sehr einfache Zähler mit Bordmitteln innerhalb der Datenbank realisieren, z.B. für die aktuelle, fortlaufende Nummer eines neuen Eintrags in einem Microblog. Redis hat weiterhin eine Schnittstelle für die Kommandozeile, kann also aus der Shell heraus interaktiv genutzt werden. Redis hält die Daten im RAM des Rechners, man kann diese aber natürlich auch auf Festplatte schreiben. Wie oft dies geschieht, ist konfigurierbar. Das Schreiben erfolgt dabei asynchron im Hintergrund; die Datenbank ist währenddessen voll erreichbar, es werden keine Sperren gesetzt.

Tokyo Cabinet verfolgt einen anderen Ansatz. Hierbei handelt es sich um einen reinen Server, der einen KV-Store bereitstellt. Interessant ist dabei, dass Tokyo Cabinet verschiedene Implementierungen des KV-Stores beherrscht. Diese unterscheiden sich primär darin, wie der Schlüssel indiziert wird und wie komplex der Wert sein kann bzw. darf. Die Unterschiede und Vorteile werden auf der Homepage ausführlich erklärt. Somit kann man bei Tokyo Cabinet immer die für die eigene Anwendung optimale Implementierung auswählen. Weiterhin gibt es für Tokyo Cabinet verschiedene Erweiterungen, wie z.B. eine optimierte Volltextsuche über Werte. Die Erweiterungen sind ebenfalls auf der Homepage verfügbar.

Keyspace ist ein weiterer KV-Store. Hier liegt ein Schwerpunkt auf guter und einfacher Replizierbarkeit und horizontaler Skalierbarkeit. Daher eignet sich Keyspace z.B. für Datenbanken, die eine sehr hohe Ausfallsicherheit und sehr hohe Erreichbarkeit haben müssen. Interessant ist weiterhin, dass Keyspace auch eine HTTP-basierte API bietet. Abfragen werden als HTTP-Request gesendet; das Ergebnis erhält man entweder als Text, JSON oder HTML-Seite zurück.