DataStax Enterprise – Cassandra des Big Data

Bei besonders hohen Anforderungen an Skalierbarkeit, Performance und Hochverfügbarkeit gibt es neben Hadoop-Distributionen kaum ebenbürtige Kontrahenten.

In Pocket speichern vorlesen Druckansicht 2 Kommentare lesen
DataStax Enterprise – Cassandra des Big Data
Lesezeit: 11 Min.
Von
  • Daniel Schulz
  • Alexander Neumann
Inhaltsverzeichnis

Die Gartner-Analysten bewerten DataStax in ihrem aktuellen Magic Quadrant für operative Datenbanksysteme als führend. Die wesentliche Technik der DSE zur Datenhaltung ist die NoSQL-Datenbank Apache Cassandra. Aus historischen Gründen wird sie auch mit C* bezeichnet, um auf "Eventual Consistency" hinzuweisen. Heute spricht DataStax der Klarheit halber von "Tunable Consistency", da sich strenge Konsistenz gegen Eintausch von Latenz und "ein wenig Hochverfügbarkeit" offenbar immer garantieren lässt.

Cassandra ist ein spaltenorientierter KeyValue-Store mit einer SQL-artigen Syntax namens CQL (Cassandra Query Language). Zudem gibt es APIs für den Zugriff auf Cassandra-Cluster (sog. Ringe) aus vielen Programmierplattformen heraus, etwa Java, Python, R, C#/.NET, Ruby, PHP und Node.js. Die vor gut einem halben Jahr in DSE hinzugekommene Graphendatenbank Titan nutzt mit Gremlin eine vergleichbare Abfragesprache für die Suche in Graphen.

Mit der DSE-Distribution samt ihren Hadoop-nahen Komponenten führt DataStax Big Data den ursprünglichen Business-Intelligence-Gedanken auf einer neuen Ebene fort. Altbewährte Zöpfe wie ETL-Strecken (Extract, Transform, Load), JOIN-Operationen und ACID-Transaktionen (Atomicity, Consistency, Isolation, Durability) werden zum Vorteil der Performance bewusst abgeschnitten.

Ursprünglich wurden jeweils Datenbanken für Management-Analysen (OLAP, Online Analytical Processing) wie geschäftliche Reports und Dashboards sowie für operative Systeme (OLTP, Online Transactional Processing) wie Eingabemasken, Stammdatenverwaltung, Bestellungen, Warenwirtschaft et cetera vorgehalten. Die Daten aus den OLTP-Datenbanken überführte man in der Regel durch nächtliche ETL-Jobs in die OLAP-Systeme. Letztere sind Data Cubes, Data Marts oder Ähnliches und jeweils einer Abteilung zugeordnet. Es besteht hier durchaus die Gefahr, dass Kennzahlen aus gleichen Daten in mehreren Abteilungen unterschiedlich verarbeitet beziehungsweise berechnet werden und dadurch eine unterschiedliche Sicht auf dasselbe Geschäft entsteht.

Big-Data-Techniken wie die Hadoop-Distributionen und DSE setzen auf Datenlokalität: Einmal gespeichert bleiben große Datenmengen dort, wo sie sind, und die wesentlich kleineren Algorithmen "kommen zu ihnen". Dadurch entfallen ETL-Jobs samt deren Verzögerungen, und es bilden sich keine Datensilos zwischen den Abteilungen mehr. Es entsteht eine echte "einzige Quelle der Wahrheit" (SSOT, Single Source of Truth).

Daten werden in der DSE, wie im Machine Learning üblich, in denormalisierter Form bereitgestellt und können je Spalte auch gerne Mengen enthalten. NoSQL-Datenbanken wie Cassandra unterstützen keine ACID-Transaktionen, JOIN-Operationen, Referenzen und können damit auch keine referentielle Integrität modellieren. Cassandra unterstützt als System nach dem CAP- oder auch Brewer-Theorem (C: zeilenweise Konsistenz, A: Verfügbarkeit, P: Partitionssicherheit gegen "Split Brain" im Netzwerk) lediglich atomare und bleibende Schreiboperationen. Strenge Konsistenz lässt sich je lesendem beziehungsweise schreibendem Zugriff konfigurieren. Durch die fehlenden ACID-Transaktionen kann man keine Isolation gewährleisten; in Cassandra lediglich auf Zeilen- genauer auf Wide-Row-Basis. Cassandra und andere NoSQL-Datenbanken folgen deswegen dem BASE-System (Basically Available, Soft State, Eventual Consistency).