Apache Cassandra

Cassandra ist der Name eines Open Source NoSQL-Datenbankverwaltungssystems, das als freie Software mit Apache Lizenz vertrieben wird. Apache Cassandra startete 2008 als Gemeinschaftsprojekt eines Facebook- und eines Amazon-Dynamo-Entwicklers. Später nahm sich die Apache Software Foundation der weiteren Ausarbeitung an. Die NoSQL Datenbank Cassandra kommt unter anderem bei Apple, Instagram, Netflix, Comcast, Twitter und Reddit zum Einsatz.[1]


Funktionsweise und Architektur[Bearbeiten]

Apache Cassandra ist auf eine Hochgeschwindigkeitstübermittlung von großen Datenmengen über eine Vielzahl von Commodity-Servern ausgelegt. Kennzeichnend für Cassandra ist, dass das Datenbankverwaltungssystem ohne Single Point of Failure (SPOF) auskommt und eine enorm hohe Fehlertoleranz aufweist.[2] Diese ist unter anderem dem Einsatz eines (P2P)-Kommunikationssystems, dem Gossip Protocol, geschuldet, das über die Rechner-Rechner-Verbindung den Informationsaustausch innerhalb eines dezentralisierten Netzwerkes verantwortet.

Anders als bei einem Master-Slave-Kommunikationsprozess stellt das Gossip Protocol sicher, dass bei Ausfall eines Netzwerkknotens ein anderer Netzknoten die Aufgaben und Verantwortlichkeiten des ausgefallenen Nodes übernimmt. So lange, bis der funktionsuntüchtige Knoten wieder arbeitet. Bei der Kommunikation via Gossip Protocol werden in den Nachrichten gespeicherte Versionen älterer Informationen fortlaufend mit aktuelleren Versionen überschrieben. Dank dieser P2P-Kommunikation bietet Apache Cassandra mehr Ressourcen als andere NoSQL-Datenbanken, etwa weniger Latenz bei der Dateneinspeisung und -verarbeitung.


Datenmodell[Bearbeiten]

Zwar ähnelt Cassandra in Aufbau und Einführungsstrategien einer Datenbank, unterstützt aber kein relationales Datenmodell. Stattdessen stellt Apache Cassandra Usern ein simples Datenmodell zur Verfügung, das dynamische Kontrolle über Datenlayout und -format unterstützt. Das Datenbankverwaltungssystem Cassandra wurde eigens für einen hohen Datendurchlauf konzipiert, ohne die Verarbeitungseffizienz der Datenbank zu beeinträchtigen. Cassandra kann man sich wie eine Hashtabelle vorstellen, die Daten in Schlüssel-Werte-Paaren speichert.

Ein RowKey einer solchen Tabelle ist ein String von üblicherweise 16 bis 36 Bytes. Wenngleich sie in der Größe nicht begrenzt sind. Die Spalten werden in Sets gruppiert, in Simple Column Families oder Super Column Families, die sich nach Zeitcode oder Namen ordnen lassen. Üblicherweise verwenden Anwendungen einen zugehörigen Cassandra Cluster und verwalten ihn, während die Applikation in Betrieb ist. Zwar unterstützt das System ein multitabellarisches Konzept, dennoch hat jedes Deployment nur eine Tabelle in seinem Schema.

Das Datenmodell erlaubt es Apache Cassandra unter anderem auch Metadaten-Information zu speichern und große Dateien mühelos um bis zu 80% zu komprimieren. Die Daten werden via Commit Log, einer Transaktionsaufzeichnung sowie durch integrierte Backup-Store Mechanismen geschützt. In Cassandra werden Daten zunächst in sogenannte Mem-Tables geschrieben. Erst wenn diese voll sind, werden sie auf Festplatten gespeichert.


Konzepte, Datenstruktur und Algorithmen[Bearbeiten]

  • Daten-Partitionierung: Apache Cassandra verwendet eine Shared-Nothing-Architektur (kurz auch: SN). Dabei wird eine singuläre, logische Datenbank über ein Netzwerkknotencluster verteilt, woraus der Bedarf an gleichmäßiger Verteilung der Daten auf alle Nodes resultiert. Hierdurch wird jeder Netzknoten für einen Teil der Daten verantwortlich.[3]
  • Hashing: Bei einer effizienten Datendistribution kann es zu zwei Hauptproblemen kommen. Einerseits muss ein bestimmter Netzwerkknoten definiert werden, auf dem ein bestimmter Datenanteil abgelegt wird. Andererseits muss der Datenstrom minimiert werden, wenn Netzknoten hinzugeschaltet oder entfernt werden. Erst die Hashfunktion macht es möglich, diese Probleme zu lösen. Ein Hashing-Algorithmus sorgt dafür, dass Cassandra RowKeys auf physischen Nodes abgebildet werden können. Die Werte aus einem solchen Algorithmus können als Ring dargestellt werden.[4]
  • Datenreplikation: Die Datenpartitionierung auf einem Shared-Nothing-System hat oft einen SPOF zur Folge. Das bedeutet, dass, wenn ein Netzwerkknoten ausfällt, kann auf Teile der Daten nicht zugegriffen werden. Durch die Datenreplikation umgeht Cassandra dieses Problem und erstellt Kopien der Daten. Die Speicherung solcher Kopien auf mehreren Netzknoten wird als Datenreplikation bezeichnet, die einen hohen Anteil an der Fehlertoleranz und Zuverlässigkeit des Datenbanksystems hat.ref>replication datastax.com. Abgerufen am 17. Juli 2019.
  • Konsistenz: Die Replikation verlangt nach einer Kopien übergreifenden Synchronisierung der Daten. Ist diese gewährleistet, spricht man von Datenkonsistenz (auch: weak oder eventual consistency), wie sie etwa auch beim Domain Name System angewendet wird. Damit soll sichergestellt werden, dass alle Netzknoten und Replikas schließlich die aktualisierten Werte ausgeben. Bei Cassandra können User selbst das Maß der Konsistenz (consistency level) bestimmen, indem sie es per Read-and-Write-Operationen an den eigenen Bedarf anpassen (tunable consistency)[5]. Sie können etwa die Anzahl der Repliken innerhalb eines Clusters konfigurieren. Der Consistency Level ist in Cassandra ein erforderlicher Parameter, weil er die genau Netzknotenanzahl festlegt, die eine Operation erfolgreich beenden müssen, bevor der gesamte Prozess abgeschlossen wird.
  • Replikationsstrategien: Die Datendistribution in Apache Cassandra kann konfiguriert werden. Hierzu stellt Cassandra Replikationsstrategien zur Verfügung, die festlegt, wie Daten Netzknoten und Rack übergreifend kopiert werden. Die Replikationsstrategien verwenden Umgebungsinformationen (Proximity), um eine geeignete Lokalität zur Speicherung einer Replik zu finden.ref>Data replication datastax.com. Abgerufen am 17. Juli 2019.
  • Gossip Protocol: Die Kommunikation in Cassandra ist nicht nach dem Master-Slave-System gestaffelt, sondern basiert auf dem Gossip Protocol. Dabei tauschen die Netzwerkknoten untereinander mit maximal 3 anderen Nodes Statusinformationen aus. Dadurch wird die Netzlast reduziert.[6]
  • Bloomfilter: Dank dem Bloomfilter, einer probabilistischen Datenstruktur, kann in Cassandra sehr schnell überprüft werden kann, ob ein Element innerhalb eines Datensets vorhanden ist oder nicht. Falsch positive Ergebnisse sind zwar möglich, falsch negative aber nicht. Mit Bloomfiltern lassen sich teure Ein-/Ausgabe-Operationen vermeiden.[7]
  • Sorted String Table (auch: SST): Eine sortierte String-Tabelle ist eine unveränderbare Schlüsselwertübersicht, mittels derer riesige sortierte Datensegmente in einer Datei gespeichert werden können.[8]
  • Write-Back Cache: Im Write-Back Cache wird die Schreib-Operation ausschließlich an den Cache verwiesen und ist umgehend abgeschlossen. Dies kürzt den Datenschreibprozess ab, der bei einem Write-Through Cache erst dann als abgeschlossen gilt, wenn die Informationen sowohl im Cache, als auch in der zugrunde liegenden Speicherstruktur hinterlegt sind. In Cassandra sind die Mem-Tables solche Write-Back Caches innerhalb eines Speichers.[9]
  • Cassandra Keyspace: Der Keyspace in Apache Cassandra ist schematisch ähnlich einem relationalen Datenbankmanagementsystem (kurz: RDBMS). Es handelt sich um Container, in denen alle Anwendungsdaten abgelegt werden. Wird ein Keyspace definiert, muss auch die Replikationsstrategie und ein Replikationsfaktor für den jeweiligen Container samt Inhalt festgelegt werden.[10]
  • Column Family (Spaltenfamilie): Die Column Family in Apache Cassandra ist das, was in einem RDBMS eine Tabelle ist. Dabei kann man sich die Column Family besser als eine Art Übersicht über eine sortierte Übersicht vorstellen. Eine Reihe in der Übersicht gibt Zugriff zu einem Spaltensatz, der in Form einer sortierten Übersicht dargestellt ist. Allerdings wird in CQL (Cassandra Query Language) von einer Tabelle (Table) gesprochen, wenn eine Spaltenfamilie gemeint ist.[11]
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
  • RowKey: Der RowKey ist der Partitionsschlüssel in Apache Cassandra. Ihm sind mehrere Spalten zugewiesen. Der RowKey ist verantwortlich dafür, wie die Daten über ein Cluster verteilt werden.[12]


Write Operations bzw. Schreib-Operationen[Bearbeiten]

Jede Eingabeaktivität der Netzknoten wird von den darin befindlichen Commit Logs erfasst. Später werden diese Daten aufgegriffen und in den Mem-Tables gespeichert. Sind diese voll, werden die Daten in die Sorted String Table Datei übertragen. Alle Schreib-Operationen werden im gesamten Cluster automatisch partitioniert und repliziert. In regelmäßigen Abständen fasst Apache Cassandra die SSTables zusammen und löscht dabei unnötige Daten.[13]


Read Operations bzw. Lese-Operationen[Bearbeiten]

Für die Lese-Operationen erhält Apache Cassandra Werte aus den Mem-Tables und überprüft die Bloomfilter, um die passende Sorted String Tabelle zu finden, in der sich die benötigten Daten befinden. Dabei werden drei unterschiedliche Lese-Anfragen an die Repliken übermittelt:

  • Direct Request
  • Digest Request
  • Read Repair Request

Der Koordinationsnetzknoten schickt einer der Repliken zunächst den Direct Request. Danach stellt er den Digest Request an die Menge Repliken, die im Consistency Level festgelegt wurden und überprüft, ob es sich bei den zurückgesandten Daten um aktualisierte Informationen handelt. Daraufhin wird der Digest Request auch an alle übrigen Repliken versandt. Gibt ein Netzwerkknoten veraltete Werte aus, aktualisiert der Read Repair Request im Hintergrund die Daten. Bei diesem Prozess spricht man entsprechend vom Read Repair Mechanism (Lese-Reparatur-Mechanismus).[14]


CQL Cassandra Query Language[Bearbeiten]

Cassandra Query Language ist die Datenbanksprache, über die man Zugriff auf Apache Cassandra erhält. CQL betrachtet die Datenbank (Keyspace) als einen Tabellen-Container. Der Client kann jeden Netzwerkknoten für seine Schreib-Operation ansprechen. Dieser Node stellt dann die Kommunikationsschnittstelle zwischen dem Client und den Netzknoten dar, die die Daten beinhalten.[15]


Einsatzbereiche[Bearbeiten]

Apache Cassandra kann überall dort eingesetzt werden, wo die Echtzeitverarbeitung großer Datenmengen wichtig ist, wo Skalierbarkeit, Hochverfügbarkeit und geringstmögliche Latenz gefragt sind. Cassandra führt Schreib- und Lese-Operationen sehr schnell und hocheffizient aus und ist nebenbei noch individuell konfigurierbar.

Cassandra kann — unter anderem in Kombination mit Apache Hadoop, einem Software-Framework zur Verarbeitung, Analyse, Speicherung und zum Durchsuchen großer Datenmengen — für eine beschleunigte und tiefergehende Informationsgewinnung aus stetig wachsenden Clustern sorgen. Damit ist Apache Cassandra für den Einsatz im Rahmen von Big Data geradezu prädestiniert.[16]


Einzelnachweise[Bearbeiten]

  1. Was ist Apach Cassandra? datastax.com. Abgerufen am 17. Juli 2019.
  2. Cassandra Introduction tutorialspoint.com. Abgerufen am 17. Juli 2019.
  3. An Introduction To NoSQL & Apache Cassandra dzone.com. Abgerufen am 17. Juli 2019.
  4. Consistent hashing datastax.com. Abgerufen am 17. Juli 2019.
  5. Cassandra: The Definitive Guide oreilly.com. Abgerufen am 17. Juli 2019.
  6. Internode communications datastax.com. Abgerufen am 17. Juli 2019.
  7. Bloom-Filter entwickler.de. Abgerufen am 17. Juli 2019.
  8. How is data maintained? datastax.com. Abgerufen am 17. Juli 2019.
  9. How is data written? datastax.com. Abgerufen am 17. Juli. 2019.
  10. Getting started with Cassandra gettingstartedwithcassandra.blogspot.com. Abgerufen am 17. Juli 2019.
  11. Cassandra - Data Model tutorialspoint.com. Abgerufen am 17. Juli 2019.
  12. Cassandra Data Modeling dzone.com. Abgerufen am 17. Juli 2019.
  13. How is data written? datastax.com. Abgerufen am 17. Juli 2019.
  14. How is data read? datastax.com. Abgerufen am 17. Juli 2019.
  15. The Cassandra Query Language cassandra.apache.org. Abgerufen am 17. Juli 2019.
  16. Hadoop vs Cassandra educba.com. Abgerufen am 17. Juli 2019.

Weblinks[Bearbeiten]