Erstmal das Wichtigste: Was zum Teufel sind Tombstones und warum verursachen sie so viele Probleme?

Tombstones sind Cassandras Methode, um gelöschte Daten zu markieren. Sie sind wie kleine Grabsteine für Ihre Bits und Bytes und sorgen dafür, dass gelöschte Daten bei allen Replikaten wirklich gelöscht bleiben.

Klingt in der Theorie großartig, oder? Aber in der Praxis können sich Tombstones schneller anhäufen als schmutzige Wäsche auf dem Boden eines Junggesellen. Das führt zu:

  • Erhöhter Latenzzeit beim Lesen
  • Aufgeblähten SSTables
  • Langsameren Kompaktierungsprozessen
  • Allgemeiner Leistungsverschlechterung

Und wenn Sie mit Multi-Cluster-Setups und der Einhaltung der DSGVO zu tun haben, verschärfen sich diese Probleme schneller als Zinseszinsen auf Ihrer Kreditkartenschuld.

Einführung in TimeWindowCompaction

TimeWindowCompaction ist wie Marie Kondo für Ihr Cassandra-Cluster – es hilft Ihnen, Ihre SSTables basierend auf Zeitfenstern aufzuräumen. So funktioniert es:

  1. SSTables werden in Zeitfenster gruppiert (z.B. stündlich, täglich)
  2. Kompaktierung erfolgt innerhalb jedes Zeitfensters
  3. Ältere Zeitfenster werden seltener kompaktiert

Um TimeWindowCompaction zu aktivieren, aktualisieren Sie Ihre cassandra.yaml-Datei:


compaction:
  class: org.apache.cassandra.db.compaction.TimeWindowCompactionStrategy
  max_threshold: 32
  min_threshold: 4
  timestamp_resolution: MICROSECONDS
  compaction_window_unit: DAYS
  compaction_window_size: 1

Diese Konfiguration richtet tägliche Zeitfenster ein und kompaktiert SSTables innerhalb jedes Fensters, wenn die Anzahl der SSTables zwischen 4 und 32 liegt.

SSTable Attachments: Ihr neuer bester Freund

SSTable Attachments sind wie diese praktischen kleinen Büroklammern, die Ihre Dokumente zusammenhalten. Sie ermöglichen es Ihnen, verwandte SSTables über Zeitfenster hinweg zu verknüpfen, wodurch unnötige Kompaktierungen reduziert und die Leseleistung verbessert werden.

Um SSTable Attachments zu aktivieren, fügen Sie dies Ihrer cassandra.yaml hinzu:


compaction:
  enable_sstable_attachment: true

Jetzt wird Cassandra versuchen, verwandte SSTables zusammenzuhalten, um den Tombstone-Streuungseffekt zu reduzieren.

Feinabstimmung von Read Repair und Hinted Handoff

Wenn es um DSGVO-konforme Löschungen geht, müssen Sie sicherstellen, dass gelöschte Daten bei allen Replikaten wirklich verschwunden sind. Hier kommen Read Repair und Hinted Handoff ins Spiel.

Read Repair: Der stille Wächter

Read Repair behebt leise Inkonsistenzen während Leseoperationen. Um es für löschintensive Workloads zu optimieren:


read_request_timeout_in_ms: 10000
read_repair_chance: 0.1
dclocal_read_repair_chance: 0.25

Diese Konfiguration erhöht die Chancen auf Read Repair, insbesondere innerhalb desselben Rechenzentrums, ohne zu viel Overhead einzuführen.

Hinted Handoff: Der beharrliche Bote

Hinted Handoff stellt sicher, dass Updates (einschließlich Löschungen) alle Replikate erreichen, auch wenn sie vorübergehend nicht verfügbar sind. Um die DSGVO-Konformität zu optimieren:


hinted_handoff_enabled: true
max_hint_window_in_ms: 10800000 # 3 Stunden
hinted_handoff_throttle_in_kb: 1024
max_hints_delivery_threads: 4

Diese Einrichtung stellt sicher, dass Löschoperationen bis zu 3 Stunden lang weitergegeben werden, was ein Gleichgewicht zwischen Konsistenz und Leistung schafft.

Alles zusammenfügen

Nachdem wir die einzelnen Teile behandelt haben, sehen wir uns an, wie sie in einem Multi-Cluster-Cassandra-Setup zusammenarbeiten:

  1. Implementieren Sie TimeWindowCompaction, um die Tombstone-Streuung zu reduzieren
  2. Aktivieren Sie SSTable Attachments, um die Leseleistung zu verbessern
  3. Feinabstimmung von Read Repair und Hinted Handoff für konsistente Löschungen
  4. Überwachen Sie die Leistung Ihres Clusters und passen Sie sie bei Bedarf an

Hier ist ein Beispiel für ein Überwachungsskript, um die tombstone-bezogenen Metriken im Auge zu behalten:


import subprocess
import json

def get_tombstone_metrics():
    nodetool_output = subprocess.check_output(["nodetool", "tablestats", "-H"])
    metrics = json.loads(nodetool_output)
    
    tombstone_metrics = {
        "total_tombstones": sum(table["LiveSSTableCount"] for table in metrics),
        "average_tombstones_per_read": sum(table["AvgTombstonesPerRead"] for table in metrics) / len(metrics),
        "max_tombstones_per_read": max(table["MaxTombstonesPerRead"] for table in metrics)
    }
    
    return tombstone_metrics

if __name__ == "__main__":
    print(get_tombstone_metrics())

Führen Sie dieses Skript regelmäßig aus, um Ihre Tombstone-Situation zu überwachen und Ihre Konfiguration bei Bedarf anzupassen.

Das Fazit

Mit einem Tombstone-Überfluss in einem Multi-Cluster-Cassandra-Setup umzugehen, ist wie das Jonglieren mit brennenden Kettensägen, während man auf einem Einrad fährt – es ist knifflig, aber nicht unmöglich. Durch die Nutzung von TimeWindowCompaction, SSTable Attachments und die Feinabstimmung von Read Repair und Hinted Handoff können Sie DSGVO-konforme Löschungen erreichen, ohne die Leistung zu opfern.

Denken Sie daran, dass es keine Einheitslösung gibt. Überwachen Sie die Leistung Ihres Clusters, experimentieren Sie mit verschiedenen Konfigurationen und scheuen Sie sich nicht, sich die Hände schmutzig zu machen. Ihr zukünftiges Ich (und das Rechtsteam Ihres Unternehmens) wird es Ihnen danken!

Profi-Tipp: Testen Sie diese Konfigurationen immer in einer Staging-Umgebung, bevor Sie sie auf Ihre Produktionscluster loslassen. Sie wollen nicht die Person sein, die das gesamte System wegen eines fehlplatzierten Kommas in der YAML-Datei lahmgelegt hat!

Jetzt gehen Sie los und bezwingen Sie diese Tombstones! Ihre Cassandra-Cluster zählen auf Sie.