Cassandra ist eine Datenbank, die nicht eindeutig in die 5 Kategorien der NoSQL-Datenbanksysteme eingeordnet werden kann: Einesteils ist sie Spalten-orientiert, andererseits wird für den effizienten Zugriff auf Daten ein “Partition Key” benötigt, also ein eindeutiger Primärschlüssel. Dies entspricht damit eher einem Key-Value-Store. Die Datenmodellierung für Apache Cassandra muss diese Besonderheiten berücksichtigen, um eine effiziente Datenverarbeitung ermöglichen zu können.
CQL – Die Cassandra Query Language
Um die Datenmodellierung mit Cassandra zu erlernen scheint es in erster Näherung sinnvoll, sich mit der Abfragesprache CQL zu beschäftigen. Diese Sprache wird wie SQL sowohl zur Struktur-Definition als auch für lesende und schreibende Zugriffe benutzt.
Ein erster naiver Eindruck von CQL scheint nun zu zeigen, dass CQL und SQL sehr viel Analogien aufweisen. Es gibt ein CREATE TABLE ebenso wie ein SELECT FROM mit einer fast identischen Parametrisierung.
Allerdings zeigt schon eine erste konkrete Umsetzung, dass diese Analogie äußerst beschränkt ist.
So muss zu allererst ein so genannter Keyspace eingerichtet werden, der in jedem Falle einen Replikationsfaktor definiert.
CREATE KEYSPACE PUBLISHING
WITH REPLICATION = {
'class': 'SimpleStrategy',
'replication_factor': 1
};
Dies ist in der Ring-Cluster-Architektur von Cassandra begründet, die eine Ausfallsicherheit durch Daten-Replikation über Knoten hinweg realisiert.
Das Anlegen einer Tabelle erfolgt dann scheinbar analog zu SQL. So wird im Folgenden eine Tabelle PUBLISHING angelegt, deren Intention es sein soll, einem Verleger Bücher zuzuordnen:
CREATE TABLE PUBLISHING(publisher_name text,title text,isbn text,price double,pages int,available boolean,primary key(publisher_name, title));
Aber eine etwas genauere Analyse zeigt, dass diese Tabelle einen komplett anderen Aufbau hat als bei einem relationalen Modell. So würde ja in einem relationalen Datenbanksystem wohl eine Tabelle PUBLISHERS über einen Fremdschlüssel mit der Tabelle BOOKS verknüpft werden.
Was ist nun aber der Sinn der obigen Tabellen-Definition:
- Der angegebene Primärschlüssel ist komplett etwas anderes. Der erste Teil, hier der
publisher_name, ist der so genannte Partition Key. Cassandra verteilt die Datensätze an Hand des Partition Keys auf die Knoten des Clusters. Damit müssen effiziente Abfragen stets mit einer einleitendenWHERE <PARTITION_KEY> = <VALUE>eingeleitet werden. Ohne diese zentrale Selektion muss der Cluster die Abfrage auf allen Knoten des Rings ausführen, also eine Art “Full Table Scan” ausführen, was nicht sonderlich effizient ist. - Der zweite Teil des Primary Key ist eine Liste von so genannten “Clustering Columns”. Nur mit Hilfe einer Clustering Column kann ergänzend zum Partition Key die Abfrage erweitert werden. So kann in obigem Beispiel die Where-Klausel geschrieben werden als
WHERE pulisher_name = 'Manning' and title = 'Cassandra in Action'. Eine weitere Selektion, also beispielsweiseAND price = 19.99ist nicht möglich.
Die zweite obige Anmerkung zeigt den Spalten-orientierten Charakter von Cassandra. Die Clustering Column title ist nämlich ein Key in einer Map, dessen Value dann den zusätzlichen Buch-Informationen entspricht. Dieses Value wird von Cassandra aber als unstrukturiertes Dokument angenommen und wird deshalb in effizienten Abfragen nicht benutzt.
Was wäre aber die Konsequenz, wenn eine weitere Clustering Column, also beispielsweise die pages mit in den Primary Key aufgenommen werden würden:
primary key(publisher_name, title)
Fangen wir mit der Spalten-orientierten Arbeitsweise an: Die über den Partition Key definierte Map enthält als Schlüssel beispielsweise den Titel 'Cassandra in Action' . Das zugehörige Value ist nun aber wiederum eine Map! Und diese enthält für jeden Key-Eintrag der Seiten wiederum die restlichen Informationen des Buchs. Oder anders formuliert: Die PUBLISHING-Tabelle enthält für jeden Buch-Titel eine Liste von Seiten, die dann jeweils die ISBN, den Preis sowie die Verfügbarkeit enthält.
Eine Abfrage der Form WHERE publisher_name = 'Manning' AND title = 'Cassandra in Action' AND pages = 500 ist vollkommen korrekt, ebenso title = 'Cassandra in Action'. Falsch hingegen wäre WHERE publisher_name = 'Manning' AND pages = 500: Hier wird in der Navigation über die verschachtelten Maps eine Ebene ausgelassen, so dass wiederum eine sehr ineffiziente Abfrage resultieren würde.
Query First
Wir sehen damit, dass bei der Datenmodellierung mit Cassandra der Ausgangspunkt nicht das statische Datenmodell sein muss, sondern die auf den Datenbestand auszuführenden Abfragen. Dies wird als “Query First”-Ansatz bezeichnet.
Notwendige Konsequenz von Query First ist eine komplette Denormalisierung des Datenbestandes. Sollen verschiedene Kombinationen von Abfrage-Kriterien unterstützt werden so muss in Cassandra jeweils eine eigene Tabelle angelegt werden, so dass Daten redundant abgelegt werden müssen.
Moderne Cassandra-Versionen
Die durch den “Query First”-Ansatz entstandenen Daten-Redundanzen sind für viele Modellierer schwer zu akzeptieren. Die Cassandra-Community hat deshalb in den letzten Jahren immer mehr Features und Optimierungen eingeführt, die dieses Problem lösen sollen. So können beispielsweise durch Indizes sehr wohl auch Abfragen bis in die Ebene der Value-Dokumente durchgeführt werden. Weiterhin führen Abfragen ohne die Angaben des Partition Key “nur” zu einer Warnung. Trotzdem müssen für einen sinnvollen Einsatz des Apache Cassandra-Datenbanksystems auch in den neuesten Versionen die technische Grundlagen sicher beherrscht und berücksichtigt werden. Sonst ist eine Ergänzung oder sogar Ablösung eines relationalen Datenbanksystems durch Cassandra sinnlos bzw. sogar nachteilig.
