Cassandra generează pietre funerare atunci când ștergeți datele. În anumite circumstanțe, excesul de pietre funerare poate provoca pauze lungi de GC, latență, eșecuri de citire sau erori din heap. Acest articol oferă sfaturi pentru gestionarea pietrelor funerare.

cuprins

ce este o piatră funerară?

în Cassandra, datele șterse nu sunt șterse imediat de pe disc. În schimb, Cassandra scrie o valoare specială, cunoscută sub numele de piatră funerară, pentru a indica faptul că datele au fost șterse. Pietrele funerare împiedică returnarea datelor șterse în timpul citirilor și, în cele din urmă, vor permite abandonarea datelor prin compactare.pietrele funerare sunt scrieri – trec prin calea normală de scriere, ocupă spațiu pe disc și folosesc mecanismele de consistență ale Cassandrei. Pietrele funerare pot fi propagate prin cluster prin sugestii și reparații. Dacă un cluster este gestionat corect, acest lucru asigură că datele vor rămâne șterse chiar dacă un nod este dezactivat atunci când ștergerea este emisă.

pietrele funerare sunt generate de:

• ștergeți declarațiile
• setarea TTLs
• inserarea valorilor nule
• Inserarea datelor în părți ale unei colecții.

care este ciclul normal de viață al pietrelor funerare?

pietrele funerare sunt scrise cu o marcă de timp. În condiții ideale, pietrele funerare (și datele asociate acestora) vor fi abandonate în timpul compactărilor după ce a trecut o anumită perioadă de timp.

următoarele trei criterii trebuie îndeplinite pentru ca pietrele funerare să fie eliminate:

• pietrele funerare au fost create cu mai mult de gc_grace_seconds în urmă.
• tabelul care conține piatra funerară este implicat într-o compactare.
• toate sstables care ar putea conține datele relevante sunt implicate în compactarea.

fiecare tabel are o setare gc_grace_seconds. În mod implicit, acesta este setat la 864000, care este echivalent cu 10 zile. Intenția este de a oferi timp clusterului pentru a obține consecvență prin reparații (și, prin urmare, pentru a preveni învierea datelor șterse).

pietrele funerare vor fi aruncate printr-o compactare numai dacă toate sstables care ar putea conține datele relevante sunt implicate în compactare. Dacă a trecut mult timp între scrierea datelor originale și emiterea ștergerii, acest lucru devine mai puțin probabil:

• strategia de compactare pe niveluri de dimensiune va compacta sstables de dimensiuni similare împreună. Datele tind să se mute în sstables mai mari pe măsură ce îmbătrânesc, astfel încât piatra funerară (într-un sstable nou, mic) este puțin probabil să fie compactată cu datele (într-un sstable vechi, mare).
• nivelat strategie de compactare este împărțit în mai multe niveluri, care sunt compactate separat. Piatra funerară va fi scrisă la nivelul 0 și va urmări efectiv datele prin niveluri – în cele din urmă ar trebui să ajungă din urmă.
• strategia de compactare a ferestrei de timp (sau strategia de compactare pe niveluri de dată) nu va compacta niciodată piatra funerară cu datele dacă sunt scrise în ferestre de timp diferite.

când pietrele funerare provoacă probleme?

utilizarea discului

când datele sunt șterse, spațiul nu va fi eliberat pentru cel puțin perioada gc_grace setată în setările tabelului. Acest lucru poate cauza probleme dacă un cluster se umple rapid.

în anumite circumstanțe, spațiul nu va fi niciodată eliberat fără intervenție manuală.

performanța citirii

pot apărea probleme grave de performanță dacă citirile întâlnesc un număr mare de pietre funerare.

problemele de performanță sunt cel mai probabil să apară cu următoarele tipuri de interogări:

• interogări care rulează peste toate partițiile dintr-un tabel („select * from keyspace.tabel”)
• interogări de gamă („selectați * din keyspace.tabel unde valoare> x” sau „unde valoare în (value1, value2,…) „
• orice interogare care poate fi rulată numai cu o clauză „permite filtrarea”.

aceste probleme de performanță apar din cauza comportamentului pietrelor funerare în timpul citirilor. Cassandra va folosi în mod normal paginarea, ceea ce permite nodurilor să returneze un număr limitat de răspunsuri la un moment dat. Când sunt implicate pietre funerare cassandra, nodul trebuie să păstreze pietrele funerare pe care le-a întâlnit în memorie și să le returneze coordonatorului, în cazul în care una dintre celelalte replici nu știe că datele relevante au fost șterse. Pietrele funerare nu pot fi paginate, deoarece este esențial să le returnați pe toate, astfel încât latența și utilizarea memoriei cresc proporțional cu numărul de pietre funerare întâlnite.

dacă pietrele funerare vor fi întâlnite depinde de modul în care datele sunt stocate și preluate. De exemplu, dacă Cassandra este utilizată pentru a stoca date într-o coadă (ceea ce nu este recomandat), interogările pot întâlni zeci de mii de pietre funerare pentru a returna câteva rânduri de date.

Cum pot diagnostica problemele legate de pietrele funerare?

interogările care întâlnesc un număr mare de pietre funerare vor apărea în jurnale. În mod implicit, o citire care întâlnește mai mult de o mie de pietre funerare va genera un avertisment:

WARN org.apache.cassandra.P. B.ReadCommand citește 0 rânduri vii și 87051 celule tombstone pentru interogare selectați * din exemplu.tabel

în mod implicit, se confruntă cu mai mult de 100.000 de pietre funerare va determina interogarea să eșueze cu un TombstoneOverwhelmingException.

pentru a verifica dacă citirile tombstone cauzează probleme de performanță, verificați dacă citirile se corelează cu o creștere a latenței de citire și a duratei de pauză GC.

dacă este clar că pietrele funerare sunt problemele, următoarele tehnici pot ajuta la restrângerea domeniului problemei:

• numărul de pietre funerare returnate într-o anumită interogare poate fi găsit rulând interogarea în cqlsh cu urmărirea activată.
• statisticile pentru numărul de pietre funerare întâlnite recent în fiecare tabel sunt disponibile în ieșirea dinnodetool cfstats.
• pentru clusterele din serviciul nostru gestionat, statisticile pentru pietrele funerare întâlnite recent sunt disponibile pe pagina clusterului în listele de valori> informații despre tabel. Aceasta include celule vii pe citire și pietre funerare medii și maxime pe citire, defalcate pe nod sau tabel pentru o anumită perioadă de timp.
• informații mai detaliate despre pietrele funerare stocate pot fi găsite folosind ic-tools.

Cum pot evita problemele de piatră funerară?

următoarele opțiuni vă pot ajuta:

• evitați interogările care vor rula pe toate partițiile din tabel (de exemplu, interogări fără clauza WHERE sau orice interogare care necesită permite filtrarea).
• modificați interogările de gamă pentru a evita interogarea datelor șterse sau pentru a opera pe o gamă mai restrânsă de date. Problemele de performanță apar numai dacă pietrele funerare sunt citite și se scalează cu numărul de pietre funerare citite.
• proiectați modelul de date pentru a evita ștergerea unor cantități mari de date.
• dacă intenționați să ștergeți toate datele dintr-un tabel, trunchiați sau aruncați tabelul pentru a elimina toate datele fără a genera pietre funerare.
• utilizați o valoare implicită time-to-live. Acest lucru funcționează eficient numai dacă cheia primară a datelor dvs. este bazată pe timp, datele dvs. sunt scrise în ordine cronologică și datele vor fi șterse la o dată cunoscută. Pentru a face acest lucru, setați un TTL implicit în opțiunile la nivel de tabel și setați o strategie de compactare bazată pe timp (TimeWindowCompactionStrategy dacă este disponibil, DateTieredCompactionStrategy altfel). Acest lucru va crea în continuare pietre funerare, dar sstables întregi vor fi eliminate în mod eficient odată ce TTL pe tot conținutul lor au trecut.

Cum pot scăpa de pietrele funerare existente?

în majoritatea circumstanțelor, cea mai bună abordare este să așteptați ca piatra funerară să se compacteze în mod normal. Dacă problemele urgente de performanță sau de utilizare a discului necesită o acțiune mai imediată, există două comenzi nodetool care pot fi utilizate pentru a forța compactările, care pot ajuta la căderea pietrelor funerare. Acestea ar trebui considerate o ultimă soluție – într-un cluster sănătos cu un model de date bine conceput, nu este necesar să rulați compactări manuale.

rulareanodetool compact forțează o compactare a tuturor sstables. Acest lucru necesită o cantitate mare de spațiu liber pe disc. Argumentele Keyspace și table ar trebui utilizate pentru a limita compactarea la tabelele în care pietrele funerare sunt o problemă. Pe tabelele în care se utilizează strategia de compactare pe niveluri de dimensiune, Această comandă poate duce la crearea unui sstable enorm care nu va avea niciodată colegi de compactat; dacă este disponibil steagul–split-output, acesta trebuie utilizat.

comandanodetool garbagecollect este disponibilă începând cu Cassandra 3.10. Această comandă rulează o serie de compacții mai mici, care verifică, de asemenea, sstables suprapuse. Este mai intensiv CPU și consumă mult timp decât nodetool compact, dar necesită mai puțin spațiu liber pe disc.

pietrele funerare vor fi eliminate numai dacă au trecut gc_grace_seconds de la crearea pietrelor funerare. Scopul propus al gc_grace_seconds este de a oferi timp pentru reparații pentru a restabili consistența clusterului, așa că aveți grijă când îl modificați – îndepărtarea prematură a pietrelor funerare poate duce la învierea datelor șterse. De asemenea, setarea gc_grace_seconds afectează expirarea indicațiilor generate pentru transferul sugerat, deci este periculos să reduceți gc_grace_seconds sub durata ferestrei de transfer sugerat (implicit, 3 ore).

reparații

reparațiile pot întârzia sau preveni căderea pietrelor funerare. Când se execută o reparație completă sau incrementală, sstables pe care le-a afectat sunt marcate ca reparate; în compactările ulterioare, aceste tabele vor fi compactate separat de sstables care nu au fost reparate. Dacă pietrele funerare sunt în sstables nereparate și datele umbrite sunt în sstables reparate (sau invers), datele nu pot fi abandonate, deoarece sstables nu pot fi compactate împreună.
Dacă executați în mod regulat reparații complete sau incrementale pe cluster, aceasta nu ar trebui să fie o problemă prea mare, deoarece pietrele funerare și datele vor ajunge în cele din urmă reparate. Cu toate acestea, dacă aveți un amestec de date reparate și nereparate și nu efectuați în mod regulat reparații, aceasta poate deveni o problemă. sstablemetadata vă poate ajuta să inspectați starea reparată a sstables dvs. pentru a afla dacă acest lucru se întâmplă. Dacă este, poate fi recomandabil să setați toate sstables ca nereparate cu sstablerepairedset astfel încât acestea să poată fi compactate împreună.
vă rugăm să rețineți, reparațiile subrange nu marchează datele ca reparate.