Apache Cassandra – Was kann die NoSQL-Datenbank?

Seit einigen Monaten ist das Thema NoSQL omnipräsent. Einfache Googlesuchen fördern massenhaft Beiträge zutage, denen eines gemeinsam ist: Sie sind für Datenbankexperten geschrieben und daher für Otto Normalwebentwickler großteils unverständlich. Dabei hat es die Technologie es durchaus verdient, von einer breiteren Basis aktiver Internetschaffender verstanden zu werden. Dr. Web bemüht sich daher im folgenden um eine verständliche, dabei natürlich schon aus Vereinfachungsgründen unvollständige Darstellung des Hot Topic Cassandra und NoSQL.

Was ist NoSQL?

NoSQL wird im allgemeinen mit „not only SQL“ übersetzt, was soviel bedeuten soll, dass „nicht nur SQL“-basierte Lösungen für jeden Anwendungsfall in Betracht gezogen werden sollten. Vielmehr können NoSQL-Datenbanken als nicht-relationale Datenbanken, respektive bloße Datenspeicher in ihren Spezialgebieten deutliche Vorteile gegenüber relationalen Datenbanksystemen wie zum Beispiel MySQL erzielen. Dabei ist der Hauptanwendungsfall, sowie der eigentliche Grund, warum NoSQL-Systeme überhaupt entwickelt wurden, der rasante Anstieg zu speichernder Daten, den Web-2.0-Anwendungen, allen voran die Social Networks wie Twitter oder Facebook mit sich bringen.

Der Begriff NoSQL-Datenbank bezeichnet keine homogene Einheit entsprechender Lösungen, wie es etwa bei SQL-Systemen der Fall ist, die mindestens durch die Abfragesprache verbunden sind. Vielmehr gibt es eine Reihe unterschiedlicher Ansätze, die im Wesentlichen wie folgt voneinander abgegrenzt werden können:

Key Value Store / Eventually Consistent Key Value Store: Diese Systeme speichern einen einzelnen Wert mit einem Schlüssel versehen ab. Ein Beispiel dafür ist Amazons Dynamo. Darauf aufbauend haben sich eine ganze Reihe weiterer Alternativen entwickelt.

Document Store: Dieser NoSQL-Typ zielt auf die unstrukturierte Speicherung kompletter Dokumente nach dem Vorbild von Lotus Notes, wobei zumeist XML oder JSON zum Einsatz kommt. Ein Beispiel für diese Gattung ist das Apache-Projekt CouchDB.

Graph Databases: Streng genommen handelt es sich bei dieser Gattung eher um ein erweitertes SQL-System. Es gibt Relationen und es gibt eine Abfragesprache namens GQL, die SQL nicht unähnlich ist. Dabei arbeiten GraphDBs aber nicht mit Table-Strukturen, sondern mit freien Datenstrukturen auch über die Grenzen mehrerer Nodes (Rechner mit DB-Installation) hinweg. Dabei sind sie in der Lage, Verbindungen zwischen Einträgen über mehrere Nodes zu halten. So kann man sich, vereinfacht ausgedrückt, GraphDB als eine flexibilisierte, horizontal skalierte MySQL-Installation vorstellen, also etwas, dass es mit MySQL so gar nicht gibt. Ältester und ausgereiftester Vertreter dieser Gattung dürfte Neo4j sein.

Wide Column Store / Column Families: Ersonnen von den Großen der Branche, namentlich Google mit Big Table und Facebook mit Cassandra, speichern Column Stores die Daten so ab, wie sie auch beim Aufruf wieder benötigt werden. Auf diese Weise ist für die Anzeige nur ein Datenabruf erforderlich, während bei der herkömmlichen Verfahrensweise via MySQL je nach Anwendungsfall umfangreiche Queries über mehrere Tabellen gefahren werden müssen, was sich bei großen Datenmengen in der Performance ganz deutlich bemerkbar macht.

Wofür wird NoSQL eingesetzt?

Die wesentlichen Vertreter der NoSQL-Bewegung sind Amazon, Google und Facebook. Mittlerweile sind auch Twitter und Digg auf den fahrenden Zug aufgesprungen. All diesen Unternehmen ist gemeinsam, dass sie in sehr kurzer Zeit sehr viele Zugriffe auf ihren Datenbestand mit Lese- und Schreibtransaktionen bewältigen müssen.

Wachsende Datenvolumen meistern

Weiterhin gemeinsam ist all diesen Diensten, dass das zu speichernde und damit auch zu lesende Volumen mit rasender Geschwindigkeit anwächst. So sind etwa bei Twitter die Tweets pro Tag im Zeitraum eines halben Jahres von rund 10 Millionen auf rund 50 Milionen angestiegen. Herkömmliche Datenbanksysteme sind vor allem hinsichtlich ihrer Skalierbarkeit in diesen Dimensionen schnell überfordert beziehungsweise benötigen unverhältnismäßig viel technische Ressourcen und Bereich Manpower.

Woher kommt Cassandra und wer nutzt es?

Cassandra, mittlerweile ein Top-Level-Projekt der Apache Foundation, wurde ursprünglich von Facebook entwickelt und 2008 an die Open Source Gemeinde übergeben, wo es zunächst in Googles Summer Of Code betreut und danach von Apache übernommen wurde.

Im Überblick der NoSQL-Lösungen wird Cassandra in der Regel den Wide Column Stores zugeordnet, was eine etwas verengende Einordnung darstellt. Zwar verfolgt Cassandra einen ganz ähnlichen Ansatz wie Google mit Big Table, zusätzlich bedient sich Cassandra aber des Key Value Store Konzeptes (siehe oben) aus Amazons Dynamo. Vor allem die einfache Skalierbarkeit basiert im Wesentlichen auf der Verwendung von Dynamokonzepten.

Cassandra wurde natürlich zuerst bei Facebook genutzt und ist dort nach wie vor im Einsatz. Facebook betreibt auch den größten bekannten Cluster (Gruppe von Rechnern, auf denen eine einzige Datenbank läuft) mit einer Größe von über 150 Rechnern. Dabei dient dieser Cluster ausschließlich dazu, die Suchfunktionalitäten in den Inboxes der Facebookuser bereit zu stellen.

Die vor allem in den USA erfolgreiche Site Digg setzt ebenfalls seit einigen Monaten Cassandra ein. Auch bei Digg stellte man fest, dass die exorbitant wachsende Zahl an usergenerierten Inhalten mit herkömmlichen SQL-Lösungen nicht mehr vernünftig bewältigt werden kann. Digg-Wettbewerber Reddit fand etwa zeitgleich ähnliche Gründe für den Umstieg auf Cassandra. Im selben Prozess befindet sich Twitter.

Cassandra technisch

Auf der technischen Seite ist Cassandra mittels Java und Ruby + Gems implementiert, zur Versionsverwaltung kommt Git zum Einsatz. Cassandra läuft nur unter UNIX-basierten Systemen wie zum Beispiel Mac OS X. Eine grafische Benutzeroberfläche zu Verwaltungszwecken gibt es (noch) nicht. Die gesamte Systemverwaltung wird per Terminal erledigt, die grundlegenden Einstellungen werden in der Dateien storage-conf.xml und cassandra.in.sh hinterlegt. Letztgenannte Datei ist besonders wichtig für den Betrieb mehrere Rechner mit der gleichen Datenbank. Diese werden in Cassandra Nodes genannt.

Wollen Sie einer Cassandra-Installation weitere Rechner beziehungsweise Nodes hinzufügen, so ist das vergleichsweise einfach. Nach der Erstinstallation eines Nodes wird das komplette Cassandrapaket inklusive der Konfigurationsdateien auf die anderen Nodes verteilt. Hierfür gibt es verschiedene Tools, eines davon ist Capistrano. Auf allen installierten Nodes wird nun automatisch nach Peer-To-Peer-Manier nach weiteren Nodes gesucht. Diese verbinden sich ohne weiteres Zutun zu einem Cluster.

Rechnerkapazität bei Bedarf hinzufügen oder reduzieren

An dieser Stelle erkennen Sie sicherlich, wie einfach es ist, Rechnerkapazität bei Bedarf hinzu zu fügen oder auch zu reduzieren. Das kann im laufenden Betrieb passieren und beeinträchtigt die Funktionalität nicht. Diese Art der Erweiterbarkeit nennt man horizontale Skalierung: Mehr Leistung erforderlich, mehr Rechner anschalten. Durch die Möglichkeit, problemlos und ohne Zusatzaufwand auch über mehrere Data Center zu skalieren, gibt es nahezu keine Kapazitätsgrenze.

Bei SQL-basierten Lösungen hingegen findet Skalierung zumeist vertikal statt. Vertikale Skalierung bezeichnet das Aufrüsten der Hardware, also in der Regel den Ersatz des bisherigen Servers durch einen leistungsfähigeren. Das ist in SQL-Umgebungen stets die beste Lösung, dabei aber bei entsprechenden Anforderungen auch sehr kostenintensiv. Natürlich gibt es auch horizontale Skalierungsstrategien für SQL. Durch den bei horizontaler Skalierung in SQL-Systemen erforderlichen Verwaltungsmehraufwand führen diese Lösungen ab einem bestimmten Punkt dazu, dass sich die Vorteile von SQL ins Negative verkehren und die Performance für den User spürbar sinkt. Dies gilt umso mehr, je größer der Skalierungsbedarf wird.

Daten speichert Cassandra in Konstrukten, die man sich stark vereinfacht als große Exceltabellen vorstellen kann. Dabei ist es nicht nötig, von Beginn an alle erforderlichen Felder zu kennen und vorzusehen. An dieser Stelle arbeitet Cassandra wie ein Documentstore, der weitgehend unstrukturierte Daten aufnehmen kann. Etwa erforderlich werdende Felder werden einfach bei Bedarf hinzugefügt.

Flexibles Datenmodell

Im Datenmodell von Cassandra gibt es zunächst den Keyspace. Der Keyspace separiert die Datenhaltung X von der Datenhaltung Y. Wollte man beispielsweise eine Cassandraanwendung für Twitter schreiben, könnte das Wort Twitter eine gute Bezeichnung für den Keyspace sein. Danach kommt die Column Family. Column Families fassen die später im Datenmodell stattfindenden Columns und Super Columns zusammen und tragen Namen wie :Tweets, :Users, wobei eine Column Family nur entweder Columns oder Super Columns, nicht beide gleichzeitig beherbergen kann. Sie erkennen das Konzept? Als nächstes kommt der Key. Der Key ist der einzige eindeutige Index im Cassandrasystem. Jeder Key verweist auf einen eindeutigen Eintrag innerhalb einer Column Family.

Die eigentliche Datenspeicherung findet dann entweder in Columns oder Super Columns statt. In einer Column wird ein Name und ein Wert gespeichert und einem Key zugeordnet. Eine Super Column ist sozusagen eine Hierarchiestufe über der Column, da sie als Ordnungselement dient und in sich Columns trägt. Kompliziert? Stellen Sie es sich so vor: Columns wären „Privatanschrift: Musterstr. 13“, „Geschäftsanschrift: Arbeitsweg 8“, „Urlaubsadresse: Faraway 5“. Darüber legen wir jetzt eine Super Column mit dem Namen Adressen. So ist es einfach, eine 1 zu mehreren Beziehung direkt datenmäßig abzubilden und physikalisch zu speichern. Bei SQL würden wir mit Joins arbeiten, die bei großen Datenbeständen wiederum auf die Performance gehen.

Mapreduce statt SQL-Queries

Bereits angesprochen habe ich, dass es in NoSQL keine SQL-Queries gibt. Streng genommen wird in Cassandra auch keine Abfrage durchgeführt, sondern es erfolgt ein Mapreduce, also eine Reduzierung der Gesamtdatenmenge auf den gewünschten Umfang. Der Zugriff auf Cassandra-Bestände erfolgt über eine API. Die deutliche Nähe zum Web wird aus den zu verwendenden Funktionsaufrufen, wie get und andere deutlich.

Ein weiterer Unterschied zu SQL besteht darin, dass in Cassandra Daten direkt sortiert abgelegt werden. Dabei folgt die Sortierung dem Anwendungszweck. Mit anderen Worten: In Cassandra speichern Sie die Daten so, wie Sie sie auch wieder abrufen wollen. Auch diese Eigenschaft führt im Vergleich zu SQL, wo im Rahmen des Query die Sortierung stattfindet, zu einer deutlich schnelleren Verfügbarkeit der zu lesenden Daten. Dieser Slideshare-Präsentation (Seite 21) können Sie entnehmen, zu welchen Ergebnissen die Cassandraentwickler bei Facebook gekommen sind, als sie MySQL und Cassandra hinsichtlich ihrer Performance (im konkreten Fall der Suchfunktion in den Inboxen der User) verglichen hatten. Danach stellten sie fest, dass bei einer Datenmenge größer 50 GB MySQL zum Schreiben rund 300 Millisekunden (ms) und zum Lesen rund 350 ms benötigt, während Cassandra zum Schreiben nur 0,12 ms und zum Lesen lediglich 15 ms aufwenden musste.

Ich bin nicht Twitter – soll ich Cassandra verwenden?

Die Frage, ob Sie Cassandra verwenden sollen, stellt sich in den meisten Fällen nicht. Cassandra ist nur in der Anwendungsentwicklung sinnvoll. Man kann nicht MySQL einfach durch Cassandra ersetzen. Die gesamte Anwendung, etwa ein CMS, würde nicht mehr funktionieren. Stehen Sie aber tatsächlich vor der Entwicklung eines neuen Webservice, der noch dazu skalierbar sein soll, so lohnt es sich durchaus, NoSQL-Lösungen zumindest in die engere Auswahl zu nehmen.

Ein gutes Anwendungsbeispiel, dass meines Erachtens mit Cassandra besser liefe, ist WordPress. Eben erst hat Dr.Web-Kollege Dennis Knake ausführlich das Plugin WP-Supercache vorgestellt (Link zum Beitrag), dass darauf abzielt, die Datenabfragen durch die Bereitstellung statischer HTML-Seiten zu reduzieren und so die Performance stärker frequentierter Blogs zu verbessern. Funktionierte WordPress unter Cassandra, so müsste man die Nachteile eines solchen Plugin nicht in Kauf nehmen und hätte trotz permanent dynamischer Inhaltebereitstellung ein performantes Blog. Umso mehr Sinn würde der Einsatz von Cassandra auf der gehosteten Plattform WordPress.com machen.

Nachteil – fehlende Verwaltungsoberflächen

Zu berücksichtigen ist zudem, dass Cassandra nicht über sinnvolle Verwaltungsoberflächen verfügt. Produkte wie phpMyAdmin oder die diversen Desktop-Tools stehen nicht zur Verfügung. Cassandra verlangt entsprechend eine hohe Bereitschaft und Fähigkeit zur tiefen Einarbeitung. Nichts für das kleine Projekt nebenbei.

Schlussendlich muss gesagt werden, dass (My)SQL ohnehin nicht etwa durch NoSQL abgelöst werden wird. Für die meisten Anwendungsfälle wird SQL aus den verschiedensten Gründen erste Wahl bleiben. Dennoch ist es sinnvoll, für spezielle Aufgabenstellungen spezielle Tools an die Hand zu bekommen, die den jeweiligen Job besser, schneller, zuverlässiger erledigen können.

(mm),