Martin Hermes TimoCom Soft- und Hardware GmbH

Apache Cassandra entwickelt sich sehr schnell weiter, und einige der Punkte, die in dem hier vorgestellten Projekt als Schwachstellen empfunden wurden, werden in neueren Versionen bereits adressiert.

Philip Stroh TimoCom Soft- und Hardware GmbH

Cassandra ist eine spannende, Enterprise-reife Technologie, die durch ihre Fähigkeit, linear zu skalieren, überzeugt.

Apache Cassandra hat sich in den letzten Jahren zur populärsten spaltenorientierten Datenbank entwickelt. Bei der Implementierung einer Anwendung auf Basis von Cassandra ist von Entwicklern und Architekten allerdings an verschiedenen Stellen ein Umdenken erforderlich. Dies gilt insbesondere, wenn bisher hauptsächlich mit relationalen Datenbanken gearbeitet wurde.

Cassandra ist eine spaltenorientierte NoSQL-Datenbank, im Englischen auch „Wide Column Store“ genannt. Aufgrund der doppelten Begriffsbelegung sollte diese Art der Datenspeicher nicht mit spaltenorientierten RDBMS verwechselt werden, wie sie im Data-Warehouse-Bereich zum Einsatz kommen. Wide Column Stores speichern Daten in verteilten multidimensionalen Maps. Diese Maps werden bei Cassandra wie bei relationalen Datenbanken als Tabellen bezeichnet.

Cassandra wurde ursprünglich von Facebook entwickelt. Mittlerweile führt die Apache Software Foundation die Datenbank als Open-Source-Projekt. Die Firma DataStax bietet eine kommerzielle Enterprise-Distribution von Cassandra an und stellt gleichzeitig viele Committer im Apache-Projekt. Die Dokumentation, der Java-Treiber und ergänzende kostenfreie Tools sind dadurch beispielsweise direkt auf der Webseite von DataStax zu finden. Für ein tiefergehendes Studium verweisen wir auf die Dokumentation.

Architektur im Cluster

Cassandra-Datenbanken werden im Cluster betrieben. Im Cluster nimmt jeder Knoten die gleiche Rolle ein, das heißt es gibt keine zentrale Steuerung, keinen Master-Knoten. Die Daten werden über das Cluster verteilt. Eine Verdopplung der Knotenanzahl hat daher beispielsweise zur Folge, dass sich die Datenmenge halbiert, für die ein einzelner Knoten verantwortlich ist. Cassandra-Systeme lassen sich somit linear horizontal skalieren. Die Verteilung der Datensätze auf die Knoten wird über den so genannten Partition Key gesteuert. Eine oder mehrere Spalten jeder Tabelle werden als Partition Key festgelegt. In einer Tabelle, die Benutzerdaten vorhält, wäre dies zum Beispiel die User-ID. Alle Datensätze zur gleichen User-ID werden in diesem Fall auf demselben Rechner gespeichert. Zur gleichmäßigen Verteilung der Daten wird der Key nicht direkt genutzt, sondern zuvor ein Hash-Wert gebildet.

Um den Zugriff auf das Cluster auch beim Ausfall einzelner Knoten sicherzustellen, lassen sich Replikationen von Datensätzen über mehrere Knoten verteilen. Die Anzahl der Replikationen wird über den Replication Factor konfiguriert. Ein Replication Factor von 3 bedeutet, dass jeder Datensatz auf drei Knoten gespeichert ist. Jede der Replikationen ist gleichwertig. Beim Zugriff auf Datensätze wird die Last unter den Replikationen aufgeteilt.

Um Performance und Ausfallsicherheit zu optimieren, lassen sich für einen Cassandra-Cluster Data Centers und Racks definieren. Jeder Knoten wird einem Rack und einem Data Center zugeordnet. Der Replication Factor lässt sich dabei für jedes Data Center einzeln konfigurieren. Die Verteilung der Daten auf verschiedene Racks innerhalb eines Data Centers erfolgt automatisch. So lässt es sich vermeiden, dass bei einem Rack-Ausfall mehrere Replikationen einer Partition gleichzeitig betroffen sind.

Cassandra arbeitet nach dem Prinzip von Eventual Consistency. Datensätze werden zwar über alle Replikationen verteilt, aber zum Zeitpunkt einer Abfrage ist die Replizierung des Datensatzes nicht zwangsläufig abgeschlossen. Je nachdem, von welchem Knoten die Daten gelesen werden, kann das Resultat daher unterschiedlich ausfallen. Über den konfigurierbaren Consistency Level kann der Anteil der Replikationen festgelegt werden, auf deren Antwort bei einer Abfrage gewartet wird. Beispielsweise wird beim Standardwert ONE bereits die erste erhaltene Antwort akzeptiert. Beim Consistency Level QUORUM wird hingegen gewartet, bis die Mehrheit der Knoten geantwortet hat. Bei lesendem Zugriff wird in diesem Fall die Antwort mit dem aktuellsten Zeitstempel an den Client weitergeleitet. Wenn ein Datensatz mit QUORUM in das Cluster geschrieben und anschließend mit QUORUM wieder gelesen wird, ist sichergestellt, dass der aktuellste Datensatz vorliegt, bevor er an den Client weitergeleitet wird. Allerdings verschlechtern sich hierdurch die Performance und auch die Ausfallsicherheit, da eine der benötigten Antworten eventuell länger braucht, oder die Anfrage aufgrund eines Ausfalls der Mehrheit der Knoten nicht beantwortet werden kann. Für eine Auflistung und Erläuterung aller möglichen Consistency Levels verweisen wir auf die Dokumentation.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 5.16 - "Microservices: Ein Hype im Realitätscheck"

Im Java Magazin 5.16 bieten Martin Hermes und Philip Stroh einen Einblick in ein spannendes Apache-Cassandra-Projekt.

Alle Infos zum Heft
236749NoSQL-Datenbanken mit Apache Cassandra: Kein Problem!
X
- Gib Deinen Standort ein -
- or -