Einsatz der Cassandra-Datenbank

Es geht um die Beherrschung großer Datenmengen, um elegante Skalierbarkeit und professionelles Datawarehousing. Was Google dabei mit BigTable vorgemacht hat, wird heute in spaltenorientierten Datenbanken umgesetzt. Cassandra ist eine ihrer bekanntesten Vertreterinnen.

In Pocket speichern vorlesen Druckansicht 2 Kommentare lesen
Lesezeit: 9 Min.
Von
  • Rudolf Jansen
Inhaltsverzeichnis

Es geht um die Beherrschung großer Datenmengen, um elegante Skalierbarkeit und professionelles Datawarehousing. Was Google dabei mit BigTable vorgemacht hat, wird heute in spaltenorientierten Datenbanken umgesetzt. Cassandra ist eine ihrer bekanntesten Vertreterinnen.

Eine Gruppe der vieldiskutierten NoSQL-Datenbanken sind die spaltenorientierten Datenbanken (Wide Column Stores). Gekennzeichnet sind sie durch die Tatsache, dass sie im Gegensatz zu den relationalen Datenbanken ihre Daten nicht zeilenweise speichern, sondern eben pro Spalte, beziehungsweise in Gruppen von Spalten. Cassandra ist ein Vertreter dieser spaltenorientierten Datenbanken, der sich insbesondere für den Einsatz mit großen Datenmengen und bei Bedarf an hoher Skalierbarkeit anbietet.

Derzeit existieren eine Reihe von Datenbanken, die sich der wachsenden NoSQL-Gemeinde zuordnen lassen. Ein guter Marktüberblick befindet sich unter nosql-database.org. NoSQL-Datenbanken lassen sich in vier Gruppen einteilen:

  • KeyValue-Stores (wie Redis)
  • dokumentenorientierte Datenbanken (wie die CouchDB)
  • Graphendatenbanken (wie Neo4j)
  • spaltenorientierte Datenbanken

Ein großer Vorteil der beschriebenen Speicherung in Spalten liegt im Zusammenhang mit komplexen Datenanalysen, beispielsweise in Datawarehouse-Systemen. Dort führt man mit Abfragen oft Berechnungen über einzelne Attribute durch, zum Beispiel eine Summenbildung oder eine Minimum-/Maximum-Berechnung. Sind die zu Grunde liegenden Daten, wie in relationalen Systemen, zeilenorientiert gespeichert, so erfordert das umfangreichere sequentielle Lesezugriffe auf Zeilen-Tupel im Vergleich zur Ablage in spaltenorientierten Datenbanken.

Ein Grundsatz beim Design solcher Spaltendatenbanken lautet daher: Speichere die Daten so ab, wie sie später abgefragt werden. Bei passenden Queries zum Lesezeitpunkt kann das signifikante Performancevorteile bringen, es gibt jedoch einen Nachteil – die Performance bei Ad-Hoc-Abfragen. Mit relationalen Datenbanken ist es kein Problem, wenn zum Zeitpunkt des Datenbankdesigns noch nicht alle möglichen Abfragen bekannt sind, da sich beliebige Tabellen später über Joins miteinander verbinden lassen und sich durch den Einsatz passender Indizes die Performance solcher Abfragen (in Grenzen) optimieren lässt. Bei NoSQL-Datenbanken im Allgemeinen und speziell bei Spaltendatenbanken sind Ad-Hoc-Queries aber eher ein Argument gegen deren Einsatz, zumindest sind sie in Prototypen vorab umfangreich zu testen.

Neben Cassandra zählen auch HBase und Hypertable zu bekannten Vertretern der Spaltendatenbanken. Alle orientieren sich grundsätzlich am "großen Bruder", dem BigTable von Google, setzen aber jeweils noch zusätzliche Akzente. In Cassandra beispielsweise finden sich Konzepte aus den Key-Value-Datenbanken, dazu aber gleich mehr.

Die Entwicklung von Cassandra begann im Jahr 2007 bei Facebook durch Avinash Lakshman und Prashant Malik. Im Juli 2008 übergab man das Projekt dann der Open-Source-Community, seit März 2009 mit Incubator-Status innerhalb von Apache. Seit Juni diesen Jahres liegt Cassandra in Version 0.8 vor.

Cassandra selber ist in Java geschrieben, so dass die Installation zunächst nur aus dem Download der Jar-Datei sowie der Anpassung der Konfigurationsdateien auf die lokalen Gegebenheiten besteht. Ein großer Pluspunkt der meisten NoSQL-Datenbanken ist die gute Skalierbarkeit. Auch Cassandra kann an dieser Stelle bei der horizontalen Skalierung seine Stärken ausspielen. Läuft das Cassandra-System bereits auf mindestens einem Rechner, so reicht eine Kopie dieser Installation auf weiteren Rechnern aus, um auf dieser Weise dem System mehr Ressourcen zur Verfügung zu stellen. Cassandra verfügt intern über die Mechanismen, die für das Auffinden sowie die Anbindung der neuen Rechner in ein Cluster-System benötigt werden. Analog dazu übernimmt Cassandra selber die Reorganisation des Systems nach einem Ausfall, beziehungsweise dem Austausch eines einzelnen Rechners. Aufwändig zu erstellende Skripte für diese Cluster-Verwaltung sind in Cassandra-Systemen daher nicht erforderlich.