Was ist Cassandra eigentlich?
- Cassandra ist eine skalierbare, auf mehreren Servern verteilte Datenbank ohne sogenannten „Single Point of Failure“, da es keinen Masternode oder ähnliches zur Verwaltung besitzt.
- Jeder Cassandra-Node verwendet clusterübergreifend exakt die selbe Software und verwendet genau die selben Funktionen.
- Das Datenmodell entspricht dem von BigTable bzw. HBase.
- Cassandra ist eine nichtrelationale Datenbank, aber es steht eine limitierte „CQL-Abfragesprache“ zur Verfügung, welche an SQL angelehnt ist, jedoch einen sehr stark verringerten Funktionsumfang bereitstellt im Vergleich zu SQL (beispielsweise fehlen Joins von Tabellen oder Anfragen können nur mit Primärschlüssel erfolgen).
Das Design von Cassandra und das CAP-Theorem
Das CAP-Theorem (siehe dazu https://de.wikipedia.org/wiki/CAP-Theorem) besagt, dass es auf verteilten Systemen unmöglich ist, gleichzeitig die drei Eigenschaften Consitency (Konsistenz), Availability (Verfügbarkeit) und Partition Tolerance (Ausfalltoleranz) zu garantieren. Bei Big Data ist Ausfalltoleranz das oberste Gebot bzw. eine Eigenschaft, die bei allen Systemen dringend notwendig ist. Aus diesem Grund kann man bei Hadoop nur die Verfügbarkeit oder die Konsistenz sicherstellen.
Cassandra fokussiert sich auf die Sicherstellung von Verfügbarkeit und Ausfalltoleranz.
Konsistenz bedeutet, dass wenn ein Eintrag in eine Datenbank eingetragen wird, dieser Eintrag sofort und vollständig für alle Abfragen zur Verfügung steht. Cassandra-Datenbanken sind jedoch nur „eventuell konsistent“. Das bedeutet, dass wenn ein Eintrag geschrieben wird, dass der Eintrag eventuell erst ein paar Sekunden oder Minuten später mit den Abfragen zur Verfügung steht. Wenn du dir vorstellt, dass Facebook alle Benutzerposts abspeichert, ist es eher ein geringes Problem, wenn der Benutzer die neuen Einträge seiner Freunde erst ein paar Sekunden später bekommt, als dass er keine Einträge zu sehen bekommt und denkt, Facebook würde zur Zeit nicht funktionieren.
Zusätzlich habe ich dir noch HBase und MySQL, beides Datenbankmanagementsysteme, die ich dir in diesem Kurs schon vorgestellt habe, eingeordnet. HBase hat das Problem, dass sobald der HMaster nicht mehr verfügbar ist, auch die ganze Datenbank nicht mehr für Interaktionen zur Verfügung steht. Wir haben hier also ein Verfügbarkeitsproblem. HBase favorisiert also die Konsistenz statt der Verfügbarkeit. Dennoch kann HBase auch eine hohe Verfügbarkeit vorweisen, da man den HMaster auch hochverfügbar einrichten kann. Bei MySQL steht die Ausfallsicherheit nicht im Fokus der CAP-Theorem, da es hier keine Möglichkeit der verteilten Datenablage gibt. Wenn die Datenbank eine Störung hat, ist die gesamte Datenbank nicht mehr erreichbar.
Wie ist Cassandra aufgebaut? Wie sieht die Architektur von Cassandra aus?
In Cassandra kommuniziert ständig jeder Node mit jedem „nahestehendem“ Node, wer welche Aufgaben übernimmt und wann welche Daten repliziert werden. Der Client kann mit jedem der Cassandra-Nodes interagieren, um beispielsweise zu erfahren, auf welchem Node sich eine Datei befindet.
Weiter geht es mit: 6.1 Die Grundlagen von YARN