Untersuchen des Lebenszyklus von Grabsteinen in Apache Cassandra

Dieser Beitrag ist der erste Teil einer Reihe von Blogbeiträgen zum Lebenszyklus und zur Verwaltung von Grabsteinen.

Das Löschen und Ablaufen von Daten in Cassandra sollten Sie sorgfältig planen. Vor allem, wenn Sie eine große Datenmenge auf einmal löschen möchten. Ohne ordnungsgemäße Planung kann dies Probleme für den Cluster mit sich bringen, z. B. eine Erhöhung der Leselatenz und des Speicherplatzes für die Festplattennutzung. In diesem Beitrag werde ich einen Weg beschreiben, dies und seine Vorbehalte anzugehen.

Lassen Sie uns zunächst die Grundlagen durchgehen. In Cassandra sind die auf der Festplatte vorhandenen Datendateien (SSTables) unveränderliche Dateien. Wenn wir etwas in Cassandra löschen, wird eine neue SSTable erstellt, die einen Marker enthält. Diese Markierung gibt an, welche Partition, Zeile oder Zelle zusammen mit dem Zeitstempel für diese Löschung entfernt wurde. Dieser Löschmarker wird als Grabstein bezeichnet.

Die gelöschten Daten und der Grabstein können während eines Zeitraums namens gc_grace_seconds, der standardmäßig 10 Tage beträgt, gleichzeitig auf der Festplatte vorhanden sein. Während dieser Zeit können die Daten zwar noch auf dem Laufwerk vorhanden sein, werden jedoch bei Abfrage nicht an den Client zurückgegeben. Dies bedeutet, dass die Daten aus Sicht des Clients gelöscht werden, sobald Sie die delete-Anweisung ausführen. Aus betrieblicher Sicht können jedoch sowohl die Daten als auch der Grabstein weiterhin vorhanden sein und Speicherplatz auf der Festplatte belegen. Diese gelöschten Daten, die noch auf der Festplatte vorhanden sind, werden als „Shadowed Data“ bezeichnet.“

N.B.: Im vorherigen Absatz sage ich, dass die Daten und die Grabsteine „immer noch auf der Disc koexistieren können“ (Hervorhebung der „Dose“), denn wenn eine Verdichtung auftritt, die die Daten und die Grabsteine betrifft, werden die Daten entfernt. Der Grabstein bleibt jedoch erhalten, wenn gc_grace_seconds nicht bestanden wurde.

Der gc_grace_seconds ist ein Sicherheitsmechanismus, um sicherzustellen, dass der Tombstone genügend Zeit hat, um auf alle Knoten zu replizieren, die eine Replik der schattierten Daten haben. Damit dieser Sicherheitsmechanismus erfolgreich ist, müssen Sie in der Lage sein, den Cluster alle gc_grace_seconds zu reparieren. Das heißt, wenn Sie die standardmäßigen 10 Tage für gc_grace_seconds verwenden, muss eine Reparatur innerhalb von 10 Tagen gestartet und abgeschlossen werden. Die Reparatur dient dem Zweck, Zombie-Daten im Cluster zu verhindern. Ich werde nicht auf die Details eingehen, wie dies passieren kann, aber im Grunde treten Zombie-Daten auf, wenn Sie Daten löschen, aber sie kehren irgendwann später zurück.

Nach Ablauf von gc_grace_seconds können die Daten und der Tombstone endgültig von der Festplatte entfernt werden, wodurch der zuvor von ihnen verwendete Speicherplatz wiederhergestellt wird (Abbildung 1). Die ETA, um den Speicherplatz freizugeben, ist einer der ersten Punkte, die ich in diesem Beitrag klären möchte. Bei der Verwendung von Cassandra ist dieser Mechanismus für viele überraschend, dh nach dem Löschen von Daten sind die Daten noch auf der Festplatte vorhanden. Diese Verwirrung wird normalerweise schnell geklärt, sobald die Leute von tombstones und gc_grace_seconds erfahren. Es scheint jedoch, dass die Betreiber dazu neigen zu glauben, dass die Daten und die Grabsteine direkt nach Abschluss von gc_grace_seconds entfernt werden. In der Tat ist es wichtig zu wissen, dass dies möglicherweise nicht (und tendenziell nicht) wahr ist. Normalerweise dauert es länger als gc_grace_seconds, bis diese Räumung erfolgt und der Speicherplatz wiederhergestellt ist.

Abbildung 1 – Komprimieren von schattierten Daten mit abgelaufenen und nicht abgelaufenen Grabsteinen

Die oben erwähnte Räumung tritt auf, wenn eine Verdichtung auftritt, an der die SSTables mit den schattierten Daten und dem Grabstein beteiligt sind. Nur dann werden die Daten effektiv entfernt und der Speicherplatz wiederhergestellt. Es ist wichtig zu beachten, dass selbst wenn gc_grace_seconds vergangen ist und die SSTable mit den schattierten Daten mit einer anderen SSTable komprimiert wird, die den Tombstone nicht enthält, die schattierten Daten nicht bereinigt werden. Dasselbe passiert für die Tombstone-Marker, d. H. Wenn die SSTable mit dem Tombstone nicht mit allen SSTables komprimiert wird, die noch gelöschte Daten enthalten, wird der Tombstone nicht von der Festplatte entfernt. Der Grund dafür ist, dass Cassandra während der Verdichtung nicht weiß, was sich in den SSTables befindet, die nicht an der Verdichtung beteiligt sind. Es hat also keine Möglichkeit zu wissen, dass es die Daten verwerfen kann, da es den Grabstein nicht sehen kann. Sie können dies in Abbildung 2 sehen, wo, obwohl gc_grace_seconds für beide Grabsteine vergangen ist, nach der Verdichtung nichts mehr entfernt wird.

Abbildung 2 – Schattierte Daten und ihre Tombstones separat komprimieren

Aufgrund der Festplattennutzung durch die Daten und den Tombstone-Marker kann sich die Ansammlung von Tombstones auf die Leselatenz auswirken, da Cassandra viele Tombstones lesen muss, bevor Live-Daten zurückgegeben werden.

Das Löschen von Daten ist normalerweise kein Problem, wenn diese Löschungen klein und spärlich sind. Denn im Laufe des natürlichen Verdichtungslebenszyklus stellt Cassandra schließlich den Speicherplatz und die gelöschten Grabsteine wieder her. Wenn Sie jedoch eine große Datenmenge gleichzeitig löschen, entstehen viele Grabsteine und können sich schnell auf Ihre Leselatenz auswirken.

Wenn Sie eine große Datenmenge ad hoc löschen müssen, gibt es im nächsten Blogbeitrag einige Schritte, mit denen Sie Risiken mindern können.

e-Mail-Adresse

Verfasser

  • Pedro Gordo

Interessiert an einer Zusammenarbeit mit Pedro? Planen Sie einen technischen Anruf.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.