apache cassandra

Big Data – Informationen neu gelebt (Teil II)

Apache Cassandra

In den ORDIX® news-Ausgaben 3/2012 bis 2/2013 [1- 4] gab es bereits eine Artikelreihe über NoSQL-Datenbanken. Im Rahmen unserer Big-Data-Reihe folgt in dieser Ausgabe nun eine Zugabe mit einem Artikel über Apache Cassandra.


Eingruppierung

Ursprünglich wurde Cassandra von Facebook entwickelt und vereint wichtige Eigenschaften von Googles BigTable- und Amazons Dynamo-Datenbank. Cassandra gehört zu den spaltenorientierten Datenbanken und ist zum Beispiel mit HBase vergleichbar. Zu den wichtigsten Funktiona­litäten von Cassandra gehören Skalierbarkeit und Hoch­verfügbarkeit sowie sehr schnelles Schreiben und Lesen einzelner Datensätze. Neben der Open-Source-Version, die unter dem Dach der Apache Foundation entwickelt wird, gibt es von DataStax eine kommerzielle Enterprise Edition.

Architektur

Cassandra ist eine verteilte Datenbank und wird in einem Cluster betrieben. Dabei kann der Cluster auch aus einem einzelnen Knoten bestehen. Das ist insbesondere für die Entwicklung und für Tests sehr praktisch. Ein Cassandra Cluster besteht aus einem Ring von gleichberechtigten Knoten. Es gibt keinen Master-Knoten und somit auch keinen Single Point of Failure. Innerhalb des Cluster werden die Daten in der Regel redundant abgelegt. Üblicherweise wird ein Replikationsfaktor von zwei oder drei gewählt. Die Replikation der Daten erfolgt dabei automatisch.

Beim Ausfall eines Knotens übernehmen die verbleibenden Knoten die Arbeit und nach einiger Zeit werden die Daten automatisch neu verteilt, um den gewählten Replikationsfaktor wieder zu erreichen. Weiterhin ist es sehr leicht möglich, den Cluster durch das Hinzufügen neuer Knoten zu erweitern (siehe Abbildung 1). Sowohl der Speicherplatz als auch der Durchsatz an Operationen skalieren dabei nahezu linear. Der Aufbau eines hoch­verfügbaren und leicht skalierbaren Systems ist dadurch sehr einfach möglich.

Logical & Physical IO

Das extrem schnelle Schreiben und Lesen von Daten wird durch eine Architektur erreicht, die man auch von relationalen Datenbanken kennt (siehe Abbildung 2 und 3). Physikalisch speichert Cassandra die Daten in so­genannten SSTables. Beim Schreiben von Daten wird nicht direkt in eine SSTable geschrieben. Stattdessen wird die Opera­tion in der Commit-Log-Datei protokolliert und die Memtable im Speicher wird aktualisiert. Damit ist die Schreiboperation aus Sicht des Clients abgeschlossen. Das Schreiben der Daten aus der Memtable in die SSTable wird asynchron durchgeführt. Das Commit Log garantiert die Dauerhaftigkeit der Operation, wird aber aus Performance-Gründen auch asynchron geschrieben  [Q8].

Beim Lesen wird zuerst über den Bloom-Filter ermittelt, wo die angefragten Daten am wahrscheinlichsten gespeichert sind. Anschließend wird mithilfe eines Cache die Position des Datensatzes innerhalb einer Datei bestimmt. Im letzten Schritt werden die Daten dann von Platte gelesen und an den Client geliefert.

Datenmodellierung

Das logische Modell von Cassandra ähnelt dem Modell einer relationalen Datenbank. So gibt es Tabellen, Spalten und Primary Keys. Die Abbildung 4 zeigt die wichtigsten Elemente.

Eine wichtige Eigenschaft von Cassandra sind Wide Rows. Diese Eigenschaft kann man sich als eine Tabelle innerhalb eines Datensatzes vorstellen. Ein Beispiel für den Einsatz von Wide Rows ist die Speicherung von Messwerten einer Wetterstation. Für jeden Tag wird eine neue Zeile angelegt. Innerhalb der Zeile wird dann für jeden Messwert ein Daten­satz mit den gemessenen Daten abgespeichert (siehe Abbildung 5). Alle Daten eines Tages können dann sehr effizient über den Partition Key abgefragt werden und auf einen einzelnen Messwert kann mit dem vollständigen Primary Key direkt zugegriffen werden.

Ein effizienter Datenzugriff ist in Cassandra nur über den Partition Key bzw. den vollständigen Primary Key möglich. Ein normalisiertes Datenmodell wird somit in vielen Fällen nicht funktionieren. Bereits bei der Datenmodellierung ist es wichtig, die benötigten Abfragen zu kennen und die Daten so abzulegen, dass effiziente Abfragen möglich sind. Eine redundante Speicherung der Daten ist dadurch nicht immer zu vermeiden.

Um das Datenmodell zu erweitern, wird kein exklusiver Zugriff auf Objekte der Datenbank benötigt. Somit ist es problemlos möglich, unter voller Last neue Tabellen anzulegen oder neue Spalten hinzuzufügen. Wie in Abbildung 5 dargestellt, dürfen unterschiedliche Datensätze einer Tabelle auch unterschiedliche Spalten haben.

Neben dem Speichern von Daten in einzelnen Spalten der Datenbank ist es auch üblich, komplexere Objekte als BLOB- oder als JSON-Dokument zu speichern. Dafür bietet Cassandra keine native Unterstützung an, sodass die Serialisierung und Deserialisierung von der Anwendung durchgeführt werden muss. In der Praxis ist das allerdings kein großes Problem, da es eine Vielzahl an frei verfügbaren Bibliotheken für diese Aufgaben gibt.

Eine weitere sehr interessante Funktionalität ist die sogenannte „Time to live“ (TTL). Beim INSERT oder UPDATE kann über die TTL eine Lebenszeit für einzelne Attribute eines Datensatzes angegeben werden. Nachdem die Zeit abgelaufen ist, sind die Daten in den Abfragen nicht mehr sichtbar und werden automatisch gelöscht.

CQL - das etwas andere SQL

Eine weitere Ähnlichkeit mit relationalen Datenbanken gibt es bei der Abfragesprache CQL (Cassandra Query Language) und der Shell cqlsh. CQL ist SQL sehr ähnlich. Neben Befehlen zur Abfrage von Daten gehören auch DML- und DDL-Befehle zum Sprachumfang. Im Gegensatz zu SQL gibt es aber zum Beispiel kein JOIN und kein GROUP BY. Die Shell ist vergleichbar mit sqlplus von Oracle. Sie dient der interaktiven Arbeit mit der Datenbank und erlaubt die Ausführung von CQL-Befehlen. Zusätzlich beherrscht die Shell noch eigene Befehle, mit denen zum Beispiel der Datenbankkatalog ausgegeben (DESCRIBE) oder Daten importiert bzw. exportiert werden können (COPY).

Transaktionen

Wie bereits erwähnt, ist Cassandra ideal geeignet, um sehr schnell einzelne Datensätze zu schreiben und zu lesen. Für ein OLTP-System fehlt somit noch die Möglichkeit, Transaktionen auszuführen. Eine vollständige Unterstützung von ACID-Transaktionen gibt es in Cassandra nicht. Mit Tunable Consistency, Lightweight Transactions und Batch-Operationen bietet Cassandra aber einige sehr nützliche Funktionalitäten, mit denen viele Anforderungen erfüllt werden können.

Tunable Consistency bedeutet, dass für jede einzelne Schreib- und Leseoperation die Konsistenz der Daten (Consistency Level) und die Verfügbarkeit des Systems definiert werden kann. Mit einer höheren Anforderung an die Konsistenz wird dabei automatisch die Verfügbarkeit reduziert und umgekehrt. Cassandra bietet hier sehr viele Möglichkeiten für das Feintuning. Die drei wichtigsten werden in Abbildung 6 erklärt. Wenn in diesem Zusammenhang von Knoten die Rede ist, dann sind damit nur die Knoten gemeint, die an der Replikation der zu lesenden oder zu schreibenden Daten beteiligt sind.

Durch die Verwendung von Lightweight Transactions kann für eine einzelne Schreiboperation (INSERT oder UPDATE) sichergestellt werden, dass keine Updates verloren gehen. In CQL wird das über das Schlüsselwort IF erreicht. Das INSERT-Statement im Beispiel von Abbildung 7 wird nur ausgeführt, wenn es noch keinen Datensatz mit dem angegebenen Primärschlüssel gibt. Das UPDATE-Statement wird nur ausgeführt, wenn das Kennwort noch den erwarteten Wert von '123' hat. Lightweight Transactions werden immer als atomare Operation ausgeführt. Die Ausführung ist allerdings relativ zeitintensiv und sollte somit mit Vorsicht eingesetzt werden.

Mit Batch-Operationen ist es möglich, mehrere Schreib­operationen als einzelne atomare Operation auszuführen. Das kann verwendet werden, um die Konsistenz von Daten in mehreren Tabellen sicherzustellen. Wenn innerhalb einer Batch-Operation Daten auf mehrere Knoten verteilt werden, dann müssen sich die einzelnen Knoten allerdings synchronisieren. Das hat wiederum in der Regel negative Auswirkungen auf die Performance. Wenn sehr viele Daten auf einem einzelnen Knoten (zum Beispiel in eine einzelne Wide Row) eingefügt werden, dann kann mit Batch-Operationen die Performance deutlich gesteigert
werden.

Analytics

Cassandra selbst bietet keine analytischen Funktionen. In CQL sind nur einfache SELECT-Statements möglich. Wie bereits erwähnt, gibt es weder ein GROUP BY noch ein JOIN. Zusätzlich ist die WHERE-Bedingung stark eingeschränkt, denn es muss zwingend der Partitionsschlüssel angegeben werden.

Eine gängige Praxis ist es, für die benötigten analytischen Abfragen eigene Tabellen anzulegen. Dies kann eine Indextabelle sein, um die notwendigen Daten zu finden, oder die Daten werden in Tabellen mit „Counter Columns“ voraggregiert gespeichert.

Wenn das nicht reicht, dann kann extern nachgerüstet werden:

  • DataStax Enterprise:
    Die kommerzielle Cassandra-Version bietet die Möglichkeit, analytische Auswertungen sowohl in Echtzeit als auch im Batch durchzuführen.
  • BI-Tools:
    Viele BI-Tools bieten eine Anbindung an Cassandra an. Beispiele dafür sind Penthao, Talend oder Jaspersoft.
  • Treiber:
    Auf der DataStax-Homepage gibt es Treiber für Spark und Hunk [Q6]. Weitere Projekte gibt es zum Beispiel auf GitHub [Q7].

DataStax Enterprise

Neben der Open-Source-Version von Cassandra gibt es von DataStax auch das kommerzielle DataStax Enterprise (DSE). Dabei handelt es sich um eine besonders intensiv getestete Cassandra-Version (DataStax Enterprise Server), die um zusätzliche Werkzeuge und Funktionalitäten erweitert wurde. Insbesondere sind dies:

  • DataStax OpsCenter (Administrationsoberfläche)
  • Backup und Recovery
  • Service und Support (24x7)
  • Analytics (Hadoop und Spark)
  • Enterprise Search (Solr)
  • In-Memory-Option
  • Sicherheitsfunktionen (LDAP, Verschlüsselung)

Anwendungsfälle

Auch wenn Cassandra sehr flexibel ist, so ist die Datenbank nicht für alle Anwendungsfälle gleich gut geeignet. Hier ein paar Beispiele, in denen sich Cassandra in der Praxis sehr gut bewährt hat:

  • Internet of Things:
    Durch die sehr hohe Schreib­geschwindigkeit können Messwerte von Sensoren sehr effizient gespeichert und verarbeitet werden.
  • Fraud Detection:
    Aufgrund der hohen Geschwindigkeit kann innerhalb weniger Millisekunden entschieden werden, ob eine Transaktion ein möglicher Betrugsfall ist. Das flexible und zur Laufzeit erweiterbare Daten­modell erlaubt es, schnell auf neue Bedrohungen zu reagieren.
  • Logging:
    Anstatt Logfiles zu schreiben, ist es möglich, alle Daten in der Datenbank zu speichern.
  • Session Cache:
    In Webanwendungen kann Cassandra als sehr schneller und flexibler Session Cache eingesetzt werden.

Nicht die erste Wahl ist Cassandra immer dann, wenn die analytische Auswertung im Vordergrund steht. Auch wenn es dafür, zum Beispiel mit der DataStax Enterprise Edition, Lösungen gibt, so sollte im Einzelfall sehr genau geprüft werden, ob Cassandra das richtige Werkzeug ist.

Wird eine vollständige ACID-Unterstützung benötigt, dann ist die Entscheidung wiederum recht einfach. Da Cassandra das nicht leisten kann, muss entweder ein klassisches RDBMS oder aber eine ACID-konforme NoSQL-Datenbank, wie zum Beispiel Neo4J, verwendet werden.

Fazit

Dieser Artikel hat einen groben Überblick über Apache Cassandra und die möglichen Einsatzgebiete gegeben. Für die weitere Einarbeitung ist vor allem die Dokumentation auf der DataStax-Homepage eine sehr gute Wahl.

In der Praxis hat sich Cassandra bereits in vielen Projekten bewährt. Durch die vielen Ähnlichkeiten zu relationalen
Datenbanken fällt der Umstieg nicht schwer. Allerdings ist es  wichtig zu verstehen, dass die Datenbank intern anders arbeitet als ein RDBMS. Insbesondere beim Design der
Anwendung und des Datenmodells muss dies berück­sichtigt werden. Unsere Experten unterstützen Sie hierbei gerne.

Olaf Hein
()

Logo ORDIX<sup>®</sup>  news lang

Abbildungen

Die vollständigen Artikel mit allen Abbildungen finden Sie im blätterbaren PDF.
Eine Übersicht über alle Artikel sowie das PDF zum Download finden Sie im Inhaltsverzeichnis.

Impressum

Impressum der ORDIX® news 2/2015

Links

Reihe "NoSQL vs. SQL - Hype oder echte Alternative?"
[1] Teil I: Was sind NoSQL-Datenbanken?“
[2] Teil II: Oracle NoSQL“
[3] Teil III: CouchDB - Time to Relax”
[4] Teil IV: HBase – Spaltenorientiert“
Reihe „Big Data - Informationen neu gelebt“
[5] Teil I: „Wie big ist Big Data?“
[6] Seminarempfehlung:
Big Data: Informationen neu gelebt

Quellen

[Q1] Wikipedia „CAP-Theorem“
[Q2] Apache Cassandra Homepage
[Q3] DataStax Cassandra Dokumentation
[Q4] Datastax: DBA's Guide to NoSQL. Apache Cassandra, 2014
[Q5] Sharma, Sanjay: „Cassandra Design Patterns“; Birmingham: Packt Publishing; 2014
[Q6] DataStax Treiber
[Q7] GitHub
[Q8] Cassandra Durability

Bildnachweis

© istockphoto.com | miljko | Pure beauty
© 4-Designer.com | 4-Designer | The occlusion women