Was ist Apache Cassandra und wer nutzt es?

Apache Cassandra ist der populärste Vertreter der NoSQL-Datenbanken. Sie ist eine verteilte Datenbank zu Speicherung großer Datenmengen. Cassandra gehört in der NoSQL-Welt zur Gruppe der Wide Column Stores. Zu ihren Stärken zählen eine einfache horizontale Skalierung, ihre Ausfallsicherheit sowie die native Unterstützung mehrerer Datacenter. Genutzt wird sie von Internetunternehmen wie Netflix oder Apple, aber auch von der Metro AG, British Oil und verschiedenen Banken.

Was kann Cassandra besonders gut und warum?

Kein Single Point of Failure & horizontale Skalierung

Cassandra verfolgt einen masterlosen Ansatz und hat dementsprechend keinen Single Point of Failure. Jeder Knoten in einem verteilten Cassandra Cluster kann eine Anfrage an die Datenbank beantworten. Verteilt werden die Daten durch einen Tokenring. Jedem Knoten im Cluster wird ein bestimmter Bereich von Hashwerten innerhalb des Rings zugewiesen. Beim Schreiben und Lesen für die Datenbank wird für jeden Datensatz ein Hashwert berechnet, mit dem der Zugriff direkt auf den passenden Knoten erfolgen kann.

Die Abbildung rechts zeigt eine vereinfachte Darstellung eines Tokenrings. Der Cluster besteht aus vier Knoten und jedem Knoten ist ein Teil eines vereinfachten Tokenrings zugewiesen (0-24, 25-49, ..). Wenn nun eine Anfrage an den Cluster geschickt wird, übernimmt einer der Knoten die Rolle des Coordinators. Diese Rolle kann grundsätzlich jeder Knoten ausfüllen. Der Coordinator analysiert die Anfrage, ließt vom bzw. schreibt auf den zuständigen Knoten und gibt die Antwort an den Client zurück.

Durch den masterlosen Ansatz ist es zudem sehr einfach Cassandra horizontal zu skalieren. Die Skalierung erfolgt dabei nahezu linear: bei der doppelten Anzahl von Knoten kann auch die doppelte Anzahl Requests verarbeitet werden und die doppelte Menge Daten gespeichert werden.

Tokenring Apache Cassandra

Ausfallsicher & variabel im Konsistenzlevel

Nun kann zwar jeder Knoten prinzipiell eine Anfrage beantworten, allerdings liegen die Daten bislang nur auf einem Knoten. Um dieses Problem zu lösen, werden die Daten über mehrere Knoten hinweg repliziert. Bei einem Replikationsfaktor von drei werden die Daten auf drei Knoten gespeichert: Zum einen auf den Knoten, der über den Tokenring bestimmt wird und die anderen beiden auf den beiden folgenden Knoten im Tokenring.

Bei Abfragen kann zudem das Konsistenzlevel angegeben werden. Dieses gibt an wie viele der Replikas gelesen werden müssen, damit eine Query erfolgreich ist. Mögliche Werte reichen von ONE (1 Replika) über QUORUM (Die Hälfte + eins) zu ALL (alle Replikas). Dies wird auch als Tunable Consistency bezeichnet.

Native Unterstützung mehrerer Datacenter

Es gibt gute Gründe mehr als ein Datacenter zu betreiben:

  • Ausfallsicherheit: Datacenter werden an unterschiedlichen Orten betrieben, um vor physikalischen Ausfallszenarien geschützt zu sein.
  • Lastverteilung: Die Daten werden in zwei logisch getrennten Datacentern gespeichert: z.B. ein Datacenter für die Analyse, eines für den Online Betrieb
  • Latenzminderung: Betrieb der Datacenter in der Nähe des Nutzers, beispielsweise jeweils eines in Asien, Europa und den USA.

Cassandra besitzt eine native Unterstützung für mehrere Datacenter. Bei der Angabe des Replikationsfaktors kann für jedes Datacenter die Anzahl der Replika angegeben werden. Die Synchronisation übernimmt Cassandra vollautomatisch. Mit diesen Mitteln ist es auch möglich, Datenschutzbestimmungen zu erfüllen. Für Kundendaten in Deutschland kann beispielsweise ein Replikationsfaktor von 0 für das US Rechenzentrum festgelegt werden.

bild2

Cassandra Performance

Daten können effizient aus Cassandra gelesen werden, wenn der Key der Daten bekannt ist. Außerdem kann der Inhalt einer so gelesenen Zeile sehr schnell durchlaufen werden. Die ist insbesondere deshalb wichtig, da Zeilen in Cassandra auf Grund des verwendeten Datenmodells mehrere Millionen Werte enthalten können. Das Datenmodell entspricht einer „sparse distributed persistent multidimensional sorted map“.
Mehr erfahren

Cassandra, HBase, MongoDB, ...? Wo liegt der Unterschied?

Apache HBase

Apache HBase ist wie Cassandra ein Column Store. Es ist ein Teil von Hadoop und dementsprechend in allen Hadoop-Distributionen enthalten. Dies ist auch die größte Stärke von HBase: es wird von Tools wie Hive, Impala oder Pig direkt unterstützt. HBase basiert auf dem Hadoop File System (HDFS), ein verteiltes, fehlertolerantes Dateisystem. Die Datenbank kann riesige Mengen von Daten problemlos speichern und wird häufig als Data Lake genutzt. Der Performance Sweet Spot von HBase liegt im analytischen Bereich und weniger in einem operationalen oder gemischt operationalen/analytischen Umfeld. Es sollte somit nicht für eine Web- oder Mobile Anwendung verwendet werden, die eine OLTP Datenbank benötigen. Cassandra bietet im Vergleich zu HBase außerdem native Unterstützung mehrerer Datacenter sowie eine einfachere, masterlose Architektur ohne Single Point of Failure.

MongoDB

MongoDB gehört in der NoSQL-Welt zur Gruppe der Dokumentendatenbanken. Wie Cassandra auch propagiert MongoDB ein denormalisiertes Datenmodell. Bei Cassandra liegt der Fokus allerdings auf einer hoher Performance bei Schreib- und Leseoperationen sowie linearer Skalierbarkeit. MongoDB bietet flexiblere Abfragemöglichkeiten, nahe an SQL-Datenbanken, opfert dafür aber die Fähigkeit zu skalieren. Zusammenfassend lässt sich sagen: Cassandra für Skalierbarkeit & Big Data, MongoDB für denormalisierte Daten im kleineren Stil.

Neo4J

Neo4J hingegen gehört zur Gruppe der Graphdatenbanken. Die Daten werden anhand der Graphentheorie in Form von Knoten und Kanten modelliert. Neo4j lässt sich nicht beliebig horizontal skalieren. Datastax Enterprise Graph ist eine Graphdatenbanken, die Cassandra als Speicher nutzt und dementsprechend nahezu unbegrenzt skaliert werden kann.

Elasticsearch

Elasticsearch ist keine Datenbank sondern ein verteilter Suchindex. Dieser ermöglicht komplexere Abfragen gegen die Daten sowie effiziente Volltextsuchen. Dazu werden nicht nur die Rohdaten gespeichert, sondern zusätzlich ein Index angelegt, der bei jeder Änderung aktualisiert wird. Elasticsearch wird in der Regel nicht als Primärspeicher genutzt, sondern zusätzlich zu einer Datenbank.

Use Case für Cassandra

Cassandra wird häufig genutzt um Zeitreihen zu speichern, beispielsweise im IoT-Umfeld. Neben den großen Datenmengen die hier anfallen ist auch die Art der Daten in Form von Zeitserien wie gemacht für das sequentielle Schreibverhalten von Cassandra.

Auch die Themen Personalisierung und das Speichern von Playlisten lassen sich sehr gut mit Cassandra umsetzen. Hier werden in der Regel strukturierte Daten gespeichert, die als Gesamtes anhand eines Key, zum Beispiel einer UserID, gelesen werden müssen.

Ebenfalls eingesetzt wird es zudem auch in der Betrugserkennung, beispielsweise im Finanzbereich. In diesem Use Case erfolgt der Einsatz häufig gemeinsam mit Apache Spark.

Wo kann Cassandra nicht sein volles Potential entfalten? Wenn beispielsweise ACID-Transaktionen benötigt werden, ist eine verteilte, Eventual-Consistency-Datenbank wie Cassandra in der Regel keine Gute Wahl. Ebenso ist das Abbilden komplexerer Datenmodelle mit vielen Relationen häufig schwierig in Cassandra. Sehr gut möglich ist dies beispielsweise mit Graphdatenbanken wie zum Beispiel DSE Graph.

Enterprise-ready Big-Data-Plattform mit Spark & Solr

Neben dem Storage benötigt eine erfolgreiche Big & Fast Data Plattform ein skalierendes Tool zur Verarbeitung und Analyse der Daten. Apache Spark integriert sich dabei hervorragend mit Cassandra. Mit Spark ist es möglich performante ETL-Strecken aufzubauen, die in Cassandra gespeicherten Daten per Machine Learning zu analysieren und per SQL auf die Daten zuzugreifen. Außerdem können reaktive, fehlertolerante Streaming-Anwendungen gebaut werden, um beispielsweise Sensordaten zu analyiseren und in Cassandra zu speichern.

Mit der Search Engine Solr können zudem die in Cassandra gespeicherten Daten mit komplexen Abfragen durchsucht werden ohne die oben beschriebenen Einschränkungen zum Partition Key beachten zu müssen.

Die Enterprise Edition von Datastax (DSE) bietet eine fertige Integration von Cassandra, Spark & Solr. Dabei werden die Daten in Cassandra automatisch per Solr zur Verfügung gestellt. Spark wird auf den selben Knoten betrieben wie Cassandra, wodurch jeder Knoten nur die Daten verarbeitet, die auch auf ihm gespeichert sind. Neben diesen Integrationen bietet die DSE hilfreiche Tools zum Betrieb des Clusters und eine produktionsstabile Version von Cassandra.

Lunch Bild

Cassandra zum Lunch

Sie wollen mehr über Cassandra erfahren, aber Ihnen fehlt die Zeit für eine tiefergehende Recherche?
Oder sie haben bereits konkrete Use Cases im Blick und wollen mehr über NoSQL-Datenbanken erfahren?
Wir kommen gerne vorbei und stellen Ihnen die Technologien genauer vor.
Wir bringen für Sie ein Mittagsessen mit und während Sie die Snacks genießen, geben unsere Experten Ihnen tiefere Einblicke in die NoSQL-Welt.

Zum NoSQL-Lunch

Lessons from Apache Cassandra and Spark

Im Video erklären Matthias Niehoff und Stephan Kepser, welche Herausforderungen beim Erstellen einer Anwendung entstehen, die auf den Prinzipien von CQRS und Event Sourcing basieren und Apache Cassandra und Apache Spark nutzen.

Ansprechpartner:

Matthias Niehoff
IT Consultant

Zum Experten-Profil