{ "version": 1, "type": "tool", "canonicalUrl": "https://tools.utildesk.de/tools/apache-cassandra/", "markdownUrl": "https://tools.utildesk.de/markdown/tools/apache-cassandra.md", "data": { "slug": "apache-cassandra", "title": "Apache Cassandra", "url": "https://tools.utildesk.de/tools/apache-cassandra/", "category": "Entwickler-Tools", "priceModel": "Open Source", "tags": [ "database", "data", "open-source", "developer-tools" ], "description": "Apache Cassandra ist eine verteilte Open-Source-Datenbank für hochverfügbare, schreibintensive Workloads mit planbaren Zugriffsmustern über viele Knoten oder Regionen.", "officialUrl": "https://cassandra.apache.org/_/index.html", "affiliateUrl": null, "inLanguage": "de-DE", "tier": "C", "editorialStatus": "curated", "featureList": [ "Ereignis- und Telemetriedaten aus IoT, Infrastruktur oder Anwendungen", "Nachrichten-, Aktivitäts- und Timeline-Daten mit hohem Schreibaufkommen", "personalisierte oder geografisch verteilte Zustände, die regional verfügbar bleiben sollen", "große Zeitreihen, bei denen Aufbewahrung und Ablauf mit TTLs geplant werden", "Dienste, bei denen ein einzelner Primärknoten oder eine einzelne Region nicht akzeptabel ist", "Globale Event-Plattform: Events werden nach Mandant und Zeitfenster partitioniert, regional geschrieben und für definierte Abfragefenster gelesen. Vorab müssen maximale Partitionsgröße, TTL und Replay-Strategie feststehen.", "IoT- und Telemetriedaten: Geräte schreiben regelmäßig Messwerte; Zeit-Buckets und Ablaufregeln verhindern, dass eine einzelne Partition unbegrenzt wächst. Rohdaten und aggregierte Auswertungen sollten getrennt bewertet werden.", "Nachrichten- oder Aktivitäts-Feed: Ein Feed kann für bekannte Zugriffe materialisiert werden, statt bei jedem Request mehrere Tabellen zu joinen. Änderungen an der Anzeige erfordern dann eine geplante Backfill- oder Dual-Write-Strategie." ], "wordCount": 1139, "contentMarkdown": "# Apache Cassandra\r\n\r\nEin IoT-Dienst empfängt Messwerte aus mehreren Regionen und darf bei Ausfall eines Rechenzentrums nicht aufhören zu schreiben. Apache Cassandra kann solche verteilten, vorhersehbaren Zugriffsmuster mit Replikation und hoher Verfügbarkeit tragen. Der Preis dafür ist ein Datenmodell, das von Abfragen aus gedacht wird, und ein Betrieb, der Repair, Compaction und Konsistenz nicht dem Zufall überlässt.\r\n\r\n## Praxisbild: ein begrenzter Durchlauf\r\n\r\nModelliere nur drei echte Abfragen und lade ein repräsentatives Zeitfenster mit kontrollierten Duplikaten sowie verspäteten Daten. Führe Last- und Knotenausfalltests durch, prüfe Ergebnisse gegen bekannte Summen und beobachte Latenz, Tombstones, Speicher sowie Repair. Wenn eine neue Produktfrage einen Vollscan oder ständige Tabellenumbauten erzwingt, passt das Modell beziehungsweise die Datenbank nicht zum Workload.\r\n\r\n## Für wen ist Apache Cassandra geeignet?\r\n\r\nCassandra ist vor allem für Plattform-, Backend- und Data-Teams interessant, die eine operative Datenbasis über mehrere Knoten oder Standorte betreiben wollen. Typische Kandidaten sind:\r\n\r\n- Ereignis- und Telemetriedaten aus IoT, Infrastruktur oder Anwendungen\r\n- Nachrichten-, Aktivitäts- und Timeline-Daten mit hohem Schreibaufkommen\r\n- personalisierte oder geografisch verteilte Zustände, die regional verfügbar bleiben sollen\r\n- große Zeitreihen, bei denen Aufbewahrung und Ablauf mit TTLs geplant werden\r\n- Dienste, bei denen ein einzelner Primärknoten oder eine einzelne Region nicht akzeptabel ist\r\n\r\nFür ein kleines internes CRUD-Projekt, viele Joins oder ständig wechselnde Ad-hoc-Abfragen ist eine relationale oder dokumentorientierte Alternative meist der ruhigere Start.\r\n\r\n
\r\n \"Illustration\r\n
\r\n\r\n## Wie Cassandra Daten organisiert\r\n\r\nAnwendungen greifen über CQL, eine SQL-ähnliche Sprache, auf Keyspaces und Tabellen zu. Ein Keyspace beschreibt unter anderem die Replikationsstrategie und die Anzahl der Kopien. Die Partition Key entscheidet, auf welchen Knoten ein Datensatz landet; Clustering Columns bestimmen die Sortierung innerhalb einer Partition.\r\n\r\nDas macht Datenmodellierung zu einer fachlichen Aufgabe. Eine Tabelle wird nicht zuerst nach Entitäten normalisiert und später für alle Fragen verwendet. Stattdessen modelliert das Team die wichtigsten Abfragen, begrenzt die Partitionsgröße und entscheidet, ob Daten für unterschiedliche Lesemuster mehrfach gespeichert werden müssen. Denormalisierung ist hier oft bewusstes Design, nicht automatisch ein Fehler.\r\n\r\n## Typische Einsatzszenarien\r\n\r\n- **Globale Event-Plattform:** Events werden nach Mandant und Zeitfenster partitioniert, regional geschrieben und für definierte Abfragefenster gelesen. Vorab müssen maximale Partitionsgröße, TTL und Replay-Strategie feststehen.\r\n- **IoT- und Telemetriedaten:** Geräte schreiben regelmäßig Messwerte; Zeit-Buckets und Ablaufregeln verhindern, dass eine einzelne Partition unbegrenzt wächst. Rohdaten und aggregierte Auswertungen sollten getrennt bewertet werden.\r\n- **Nachrichten- oder Aktivitäts-Feed:** Ein Feed kann für bekannte Zugriffe materialisiert werden, statt bei jedem Request mehrere Tabellen zu joinen. Änderungen an der Anzeige erfordern dann eine geplante Backfill- oder Dual-Write-Strategie.\r\n- **Multi-Region-Betrieb:** Replikation über Rechenzentren reduziert die Abhängigkeit von einer Region. Anwendung und Treiber müssen dennoch lokale Konsistenz, Failover und mögliche Konflikte bewusst behandeln.\r\n\r\n## Konsistenz, Replikation und Verfügbarkeit\r\n\r\nCassandra lässt sich nicht mit dem Versprechen „immer konsistent und immer billig“ betreiben. Replikationsfaktor, Replikationsstrategie und Consistency Level bestimmen gemeinsam, wie viele Replikate eine Operation bestätigt sehen muss. `LOCAL_QUORUM` kann für regionale Zugriffe sinnvoll sein, ist aber kein Ersatz für ein fachliches Konfliktmodell. Lightweight Transactions helfen bei bestimmten bedingten Änderungen, machen Cassandra aber nicht zu einer allgemeinen relationalen Transaktionsdatenbank.\r\n\r\nEin Knoten-Ausfall kann während des Betriebs überbrückt werden. Hints und andere Mechanismen unterstützen die Konvergenz, ersetzen aber nicht den geplanten Repair. Für jedes Keyspace gehören Repair-Frequenz, Restore-Probe, Node-Replacement und das Verhalten nach einem längeren Ausfall in den Runbook-Entwurf.\r\n\r\n## Betrieb: Repair, Compaction und Monitoring\r\n\r\nDie Schreibstrecke nutzt Commit Log, Memtables und immutable SSTables. Updates, Deletes und TTL-Abläufe erzeugen neue Versionen oder Tombstones; Compaction führt SSTables zusammen und räumt veraltete Daten auf. Das ist kein unsichtbares Detail: Disk-Auslastung, Schreibverstärkung, Read Amplification, Tombstone-Dichte und Compaction-Backlog können die Latenz spürbar verändern.\r\n\r\nEin produktiver Pilot sollte deshalb nicht nur Requests pro Sekunde messen. Beobachtet werden sollten p95/p99-Latenz, Pending Compactions, Heap und Off-Heap-Ressourcen, Disk-Wasserstand, Streaming, Repair-Status, Read/Write Timeouts und die Verteilung der Partitionsgrößen. Dashboards ohne Alarmgrenzen und Besitzer sind noch kein Betriebskonzept.\r\n\r\n## Sicherheit und Datenverantwortung\r\n\r\nVor dem ersten produktiven Dataset müssen Authentifizierung, Autorisierung, Verschlüsselung zwischen Knoten und Clients, Netzwerkgrenzen, Secrets, Backups und Audit-Anforderungen geklärt sein. Personenbezogene Daten brauchen zusätzlich eine dokumentierte Lösch- und Aufbewahrungslogik. TTLs können helfen, aber sie ersetzen keine Prüfung, ob Replikate, Backups und Exporte dieselbe Löschanforderung erfüllen.\r\n\r\nBei selbst betriebenen Clustern liegt die Verantwortung für Patches, Versionen, Kapazitätsplanung und Restore-Tests beim Team. Ein gemanagter Dienst kann Betriebsarbeit reduzieren, ändert aber nicht die Aufgaben rund um Datenmodell, Zugriffsmuster, Region, Vertragslage und Kostenkontrolle.\r\n\r\n## Preise und tatsächliche Kosten\r\n\r\nApache Cassandra selbst ist Open Source und ohne klassische Lizenzgebühr nutzbar. Bezahlt werden trotzdem Infrastruktur, SSD-Kapazität, Replikationsplatz, Datenverkehr zwischen Regionen, Backups, Monitoring, Bereitschaft und Engineering-Zeit. Bei einem gemanagten Angebot kommen Dienst- und Transferpreise nach Anbieter hinzu.\r\n\r\nFür einen Vergleich sollte das Team einen repräsentativen Workload mit realistischen Payloads und Replikationsfaktoren fahren. Wichtig sind nicht nur die durchschnittlichen Kosten pro Monat, sondern auch Spitzen, Egress, Reservekapazität, Repair- und Compaction-Last sowie die Kosten eines Restore- oder Region-Ausfalls.\r\n\r\n## Redaktionelle Einschätzung\r\n\r\nCassandra empfehlen wir erfahrenen Plattformteams mit hoher Schreiblast, klaren Zugriffsmustern und echten Verfügbarkeitsanforderungen über Knoten oder Regionen. Für relationale Transaktionen, flexible Ad-hoc-Abfragen oder kleine Teams ohne verteilten Datenbankbetrieb ist PostgreSQL oder ein verwalteter Dienst meist vernünftiger.\r\n\r\n\r\nUnsere Empfehlung: mit einem begrenzten, aber echten Workload starten. Erfolgskriterien sollten Partitionsgröße, p99-Latenz, Repair-Zeit, Wiederherstellungsdauer, Kosten pro Vorgang und das Verhalten bei Knoten- oder Regionsausfall enthalten. Wenn das Team diese Zahlen nicht messen oder den Cluster nicht zuverlässig reparieren und wiederherstellen kann, ist eine weniger anspruchsvolle Alternative wahrscheinlich die bessere Entscheidung.\r\n\r\n## Alternativen\r\n\r\n- [Amazon DynamoDB](/tools/amazon-dynamodb/): sinnvoll, wenn ein stark verwalteter Key-Value- und NoSQL-Dienst mit wenig Clusterbetrieb gesucht wird.\r\n- [MongoDB](/tools/mongodb/): passend, wenn dokumentorientierte Daten, flexible Dokumente und andere Abfragemuster wichtiger sind als Cassandras Wide-Column-Modell.\r\n- [CockroachDB](/tools/cockroachdb/): interessant für verteilte relationale Transaktionen, SQL und ein stärker relationales Datenmodell.\r\n- [Apache HBase](/tools/apache-hbase/): eine Option für große Tabellen im Hadoop-Ökosystem und Zugriffe, die zum HBase-Modell passen.\r\n- [ClickHouse](/tools/clickhouse/): besser für spaltenorientierte analytische Abfragen und Aggregationen als für den primären operativen Schreibpfad.\r\n\r\n## FAQ\r\n\r\n**Ist Apache Cassandra eine relationale SQL-Datenbank?**\r\n\r\nNein. Cassandra bietet mit CQL eine SQL-ähnliche Sprache, verwendet aber ein verteiltes Wide-Column-Modell und andere Konsistenz- und Transaktionsgrenzen. Joins und frei kombinierbare relationale Abfragen sind nicht ihr Schwerpunkt.\r\n\r\n**Muss ich Tabellen für konkrete Abfragen modellieren?**\r\n\r\nJa. Partition Key und Clustering Columns sollten aus den wichtigsten Zugriffsmustern abgeleitet werden. Wer erst ein universelles Schema baut und die Queries später erfindet, riskiert Hot Partitions, große Scans oder unbrauchbare Latenzen.\r\n\r\n**Ersetzt Replikation den Backup- und Restore-Test?**\r\n\r\nNein. Replikation schützt vor bestimmten Knotenausfällen, ist aber kein unabhängiges Backup und keine Garantie gegen Fehlbedienung oder fehlerhafte Daten. Restore und Wiederanlauf müssen regelmäßig mit realistischen Daten getestet werden.\r\n\r\n**Ist Cassandra für klassische Business-Reports geeignet?**\r\n\r\nMeist nicht als primäre Reporting-Datenbank. Operative Daten können in ein Analyse-System exportiert werden; für Ad-hoc-Joins und breite Aggregationen sind relationale Warehouses oder spaltenorientierte Systeme häufig geeigneter.\r\n\r\n**Wann sollte ich Cassandra nicht wählen?**\r\n\r\nWenn das Projekt klein ist, die Abfragen noch völlig offen sind, starke relationale Transaktionen benötigt werden oder niemand Repair, Compaction, Monitoring und Restore verantworten kann. In diesen Fällen reduziert eine passendere Alternative das Betriebsrisiko." } }