Cassandra: Wartung

Ich bin unerfahren mit Cassandra, habe aber einige Erfahrungen mit SQL-basierten relationalen Datenbanken.

Ich konnte keine Best-Practice-Informationen zur Wartung von Cassandra nach der Bereitstellung finden. Muss die Datenbank VACUUMIERT werden? Ich sollte denken, dass Lese- / Schreiblasten eine Fragmentierung im Speicher verursachen.

Oder allgemeiner: Was sind die Best Practices für die Aufrechterhaltung einer Cassandra-Produktionsbereitstellung? Was muss in regelmäßigen Abständen getan werden, um den Zustand des Systems zu erhalten? Das Betriebshandbuch behandelt diesen Aspekt wirklich nicht.

Vielen Dank.

Im Allgemeinen kann ein gut gestalteter Cluster JAHRE lang leben, ohne berührt zu werden. Ich hatte Cluster, die jahrelang ohne Probleme liefen. Hier sind jedoch einige Richtlinien:

Überwachung ist enorm wichtig:

1) Überwachen Sie die Latenzen. Verwenden Sie opscenter oder Ihre bevorzugten Metrik-Tools, um die Latenzen zu verfolgen. Steigende Latenzen können Anzeichen für Probleme sein, einschließlich GC-Pausen (häufiger bei Lese-Workloads als bei Schreib-Workloads), stabile Probleme und dergleichen.

2) Überwachung der stabilen Anzahl. Die Anzahl der SSTables erhöht sich, wenn Sie die Komprimierung überschreiten (jede sstable wird genau einmal geschrieben - Löschvorgänge werden durch Kombinieren alter sstables zu neuen sstables durch Komprimierung behandelt).

3) Überwachen Sie Änderungen des Knotenstatus (nach oben / unten usw.). Wenn Knoten flattern, untersuchen Sie dies, da dies nicht normal ist.

4) Behalten Sie den Überblick über Ihre Festplattennutzung - traditionell müssen Sie unter 50% bleiben (insbesondere, wenn Sie die STCS-Komprimierung verwenden).

Es gibt einige grundlegende Dinge, die Sie regelmäßig tun sollten und nicht tun sollten:

1) Nicht explizit ausführen nodetool compact. Sie erwähnen, dass Sie es getan haben, es ist nicht tödlich, aber es erzeugt sehr große Ställe, die dann weniger wahrscheinlich an der zukünftigen Verdichtung teilnehmen. Sie müssen es nicht unbedingt weiter ausführen, aber manchmal kann es hilfreich sein, gelöschte / überschriebene Daten zu entfernen.

2) nodetool repairwird normalerweise alle gc_grace_seconds(standardmäßig 10 Tage) empfohlen . Es gibt Workloads, bei denen dies weniger wichtig ist. Der Hauptgrund für die Reparatur besteht darin, sicherzustellen, dass Löschmarkierungen ( tombstones) übertragen werden, bevor sie ablaufen (sie leben gc_grace_seconds, wenn ein Knoten zum Zeitpunkt des Löschens ausgefallen ist , werden diese Daten möglicherweise wieder lebendig ohne die Reparatur!). Wenn Sie keine Löschvorgänge ausführen und mit ausreichender Konsistenz abfragen (z. B. Lesen und Schreiben bei QUORUM), können Sie tatsächlich ein Leben ohne Reparatur führen.

3) Wenn Sie reparieren möchten, sollten Sie eine inkrementelle Reparatur in Betracht ziehen und jeweils kleine Bereiche reparieren.

4) Verdichtungsstrategien sind wichtig - sehr viel. STCS eignet sich hervorragend zum Schreiben, LCS eignet sich hervorragend zum Lesen. DTCS hat einige Macken.

5) Datenmodelle sind wichtig - genau wie RDBMS / SQL-Umgebungen Probleme bekommen, wenn nicht indizierte Abfragen große Tabellen treffen, kann Cassandra bei sehr großen Zeilen / Partitionen problematisch sein.

6) Schnappschüsse sind billig. Sehr billig. Fast augenblicklich, nur harte Links, kosten sie fast sofort keinen Speicherplatz. Verwenden Sie Snapshot, bevor Sie Versionen aktualisieren, insbesondere Hauptversionen.

7) Seien Sie vorsichtig beim Löschen. Wie in # 2 angedeutet, erstellt delete mehr Daten auf der Festplatte und gibt sie MINDESTENS nicht frei gc_grace_seconds.

Wenn alles andere schief geht:

Ich habe Artikel gesehen, die darauf hinweisen, dass Cassandra in Prod einen dedizierten Kopf für die Verwaltung von Clustern jeder Größe benötigt. Ich weiß nicht, dass dies unbedingt der Fall ist. Wenn Sie jedoch Bedenken haben, sollten Sie einen externen Berater (TheLastPickle, Pythian) beauftragen ) oder haben Sie einen Supportvertrag (Datastax), um sich zu beruhigen.

Nach Angaben der Cassandra Reparaturdokumentation , nodetool repairsollte in den folgenden Situationen ausgeführt werden:

• Als bewährte Methode sollten Sie Reparaturen wöchentlich planen. Hinweis: Wenn Löschungen nie auftreten, sollten Sie dennoch regelmäßige Reparaturen einplanen. Beachten Sie, dass das Setzen einer Spalte auf null ein Löschen ist.
• Während der Knotenwiederherstellung. Zum Beispiel, wenn ein Knoten nach einem Fehler wieder in den Cluster gebracht wird.
• Auf Knoten mit Daten, die nicht häufig gelesen werden.
• So aktualisieren Sie Daten auf einem Knoten, der ausgefallen ist.

Ich sollte denken, dass Lese- / Schreiblasten eine Fragmentierung im Speicher verursachen.

Daten in Cassandra "fragmentieren" nicht so, wie Sie denken. Löschvorgänge lösen jedoch die Platzierung von Grabsteinen aus, und der normale kompakte Vorgang entfernt die Grabsteine.

Ich verstehe jetzt, dass die Verdichtung eine große Sache ist und automatisch abläuft

Richtig. Ein DataStax-Mitarbeiter sagte mir, dass Sie es nach der compactmanuellen Ausführung immer manuell ausführen müssen. Der Grund dafür ist, dass die Komprimierung funktioniert, indem alle vorhandenen SSTABLES in einem Schlüsselbereich in eine einzige SSTABLE-Datei "komprimiert" werden. Möglicherweise enthält diese SSTABLE-Datei einige Spaltenfamilien, die klein sind und so lange dauern, bis sie über den Komprimierungsschwellenwert hinaus ansteigen, dass die Wahrscheinlichkeit, dass die automatische Komprimierung jemals wieder ausgeführt wird, sehr gering ist.

Stellen Sie im Wesentlichen sicher, dass Sie eine regelmäßige Strategie planen nodetool repair, niemals ausführen nodetool compactund eine Sicherungsstrategie implementieren (Snapshots, inkrementelle Sicherungen oder beides).