Datenmodell optimiert auf High 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“:

  • Map: Assoziiert Schlüssel mit Werten
  • Sorted: Geordnet nach dem Schlüssel
  • Multi-dimensional: Die Werte können weiter geschachtelt werden
  • Persistent: Einmal geschrieben, muss es explizit gelöscht werden
  • Distributed: Verteilt über mehre verschiedene Knoten
  • Sparse: Nicht jeder Wert muss gefüllt sein.

Der Schlüssel einer Map kann dabei aus mehreren Werten bestehen. In Cassandra ist dies der Partition Key, der zur Berechnung der Positition im Token Ring genutzt wird, sowie optionale Clustering Columns.

In der obigen Tabellendefinition ist die sensorId der Partition Key, die Zeit ist die Clustering Column. Nun können problemlos zu einem Sensor verschiedene Werte (hier Temperatur und Luftfeuchtigkeit) über die Zeit hinweg gespeichert werden und über die Angabe des Schlüssels schnell gelesen werden.

Um Queries auf verschiedene Schlüssel zu unterstützen, müssen die Daten in Cassandra mehrfach gespeichert werden. Seit Cassandra 3.0 unterstützen hier auch die Materialized Views. Ähnlich verhält es sich bei mit der Auflösung von Joins. Die Projektionen der Joins werden materialisiert in der Datenbank gespeichert. Um beispielsweise genau Positition unserer fest installierten Sensoren zu speichern, würde diese nicht in einer eigenen Tabelle geschrieben werden, sondern zur bestehenden Tabelle hinzugefügt werden. Durch das Schlüsselwort static wird der Wert für jede Partition (in diesem Fall pro Sensor) nur einmal gespeichert und nicht für jede Metrik & Zeit erneut.

CREATE TABLE temperaturdaten (
    sensorId uuid,
    zeit timestamp,
    temperatur double,
    luftfeuchtigkeit double,
    PRIMARY KEY((sensorId),zeit)
)
CREATE TABLE temperaturDaten (
  sensorId uuid,
  sensorLatitude double static,
  sensorLongitude double static,
  metrik text
  zeit timestamp,
  wert int,
  primary key((sensorId),metric,zeit)
)

Performance - sehr gute Ergebnisse unabhängig vom Workload

Cassandra wurde in verschiedenen Benchmarks mit den wichtigsten NoSQL-Datenbanken verglichen. Dazu gehören vor allem HBase und MongoDB aber auch Couchbase und Redis sowie MySQL als relationale Datenbank. Auch wenn jede Datenbank für bestimmte Use Cases besser geeignet ist, ist Cassandra die Datenbank, die unabhängig vom Workload die besten Ergebnisse erzielt. Hervorzuheben ist dabei die lineare Korrelation zwischen den Operationen pro Sekunde und der Anzahl der Nodes. Keine andere Datenbank kann in diesem Maße skaliert werden.

Aufgrund des Tokenrings und des sequentiellen Schreibverhaltens eines Append Only Index bietet Cassandra eine sehr gute Performance sowohl beim Schreiben als auch beim Lesen. Sie eignet sich also auch für einen Einsatz in einem Mixed-Load-Szenario oder bei einem gemischten Workload aus operationalen und analytischen Anfragen.