No-SQL-Shootout: Terrastore

Nachdem wir im vorigen Artikel den Testablauf vorgestellt haben, hier nun wie versprochen die Details zu den einzelnen Kandidaten.

Terrastore (http://code.google.com/p/terrastore/) ist eine verteilte Key-Value-Datenbank, die auf Terracotta basiert. Die Records, etwa serialisierte Java-Objekte aber auch JSON-Strings, legt Terrastore in einer hierarchischen Struktur bucket/key ab, so dass sich Terrastore vereinfacht als Funktion String x String -> Record interpretieren lässt. Ein Bucket entspricht in etwa einer Tabelle in einer SQL-Datenbank. Buckets können nicht verschachtelt werden und sind relativ schwergewichtige Objekte - einige hundert Buckets stellen das System vor kein großes Problem. Eine Größenordnung darüber ist aber nicht mehr realisierbar (OutOfMemory-Exceptions).

Terrastore benutzt zwei Arten von Prozessen:

• Ein Master-Prozess ist für die Datenhaltung verantwortlich. Die Datenbank unterscheidet zwei Arten von Mastern: ein aktiver Master ist derjenige, der Daten ausliefert. Ein passiver Master dient der Ausfallsicherheit und springt ein, wenn der aktive Master ausfällt. Die Daten werden dabei gespiegelt und nicht partitioniert. Ein passiver Master dient lediglich als "hot-spare" ist also nicht an einem Load-Balancing beteiligt.

• Ein Terrastore Server ist der zweite Typus eines Terrastore-Prozesses. Er dient zur Kommunikation mit einem Client und führt Berechnungen auf den Daten aus. In der Terrastore-Dokumentation wird Node oft als Synonym für den Begriff Server verwendet.

Der Zusammenschluss von mindestens einem Server, einem (aktiven) Master und beliebig vielen passiven Mastern wird als Cluster bezeichnet. Da Terrastore Berechnungen über Server verteilt, kann man durch das Benutzen mehrerer Server innerhalb eines Clusters den Durchsatz für Anfragen erhöhen. Der minimale Cluster besteht aus einem Server und einem Master. Cluster sind zur Laufzeit veränderbar, das heißt es ist möglich, passive Master und Server hinzuzufügen und zu entfernen.

Ein Terrastore Ensemble bezeichnet einen komplexeren Verbund von Clustern. Erst durch ein Ensemble können sehr hohe Lasten/Datenmengen bewältigt werden. Die Daten verteilt Terrastore dabei für den Benutzer transparent zwischen den Clustern. Jeder Server des Ensembles hat die Sicht auf alle Daten. Ein bereits bestehendes Ensemble ist in seiner Struktur unveränderbar, um beispielsweise zusätzlichen Plattenplatz verfügbar zu machen. Terrastore in diesem Sinne also nicht elastisch!

Range Queries werden über einen Snapshot - eine eingefrorene Sicht auf die Menge aller Keys in einem Bucket - realisiert. Jeder Snapshot hat ein Gültigkeitszeitraum (time-to-live), nach dessen Ablauf er verfällt. Bei einer Range Query überprüft der Server zunächst, ob er zu dem Bucket noch einen gültigen Snapshot hat. Falls nicht, wird ein neuer Snapshot erzeugt. Da das Erstellen eines Snapshots eine teure Operation ist, sollte man darauf achten, einen möglichst hohen Gültigkeitszeitraum zu setzen.

Die Installation von Terrastore erfolgt über ant-Skripte und lief problemlos out-of-the-box. Bei einem Benchmark auf einem Laptop konnten 10 Millionen Dokumente bei einer konstanten Rate von 1000 Dokumenten pro Sekunde eingefügt werden. Terrastore verhielt sich im Testbetrieb absolut stabil.

Die Zugriffe auf Terrastore erfolgen über REST. Dies ermöglicht es, die ersten "Hello World"-Schritte, etwa mit curl durchzuführen. Beispiele:

Die konsequente Benutzung einer Standardtechnologie eröffnet einem ebenfalls die Möglichkeit, einen voll funktionsfähigen, performanten Python-Client in gerade einmal 60 Zeilen zu implementieren. Dies ist - insbesondere in der Einstiegsphase in das System - ein großer Vorteil.

Terrastore hat eine kleine aber feine Community und ein hochengagiertes Entwicklerteam. In der Diskussionsgruppe gepostete Fragen wurden von den Entwicklern stets innerhalb weniger Stunden beantwortet, diese Form des Supports ist für eine kostenlose Software bemerkenswert.

Die Möglichkeit, Terrastore über einen kleinen Eintrag in der pom.xml embedded zu benutzen, klingt zunächst sehr gut, ermöglicht dies doch, automatische Tests mit einer echten Terrastore-Instanz auszustatten. Die andere Seite der Medaille ist ein Rattenschwanz transitiver Abhängigkeiten, denen man sich mit diesem Schritt unterwirft und die einen tief in die "JAR-Hölle" werfen. Es ist also sehr genau abzuwägen, ob zum Beispiel dieses Feature für das eigene Projekt tatsächlich nutzbringend ist. Dass es angeboten wird, ist auf jeden Fall begrüßenswert.