examinarea ciclului de viață al pietrelor funerare în Apache Cassandra

această postare este prima parte a unei serii de postări pe blog cu privire la ciclul de viață și gestionarea pietrelor funerare.

ștergerea și expirarea datelor din Cassandra este ceva ce ar trebui să planificați cu atenție. Mai ales dacă sunteți pe cale să ștergeți o cantitate masivă de date simultan. Fără o planificare adecvată, acest lucru poate aduce probleme clusterului, cum ar fi o creștere a latenței de citire și a amprentei de utilizare a discului. De-a lungul acestui post, voi descrie o modalitate de a aborda acest lucru și avertismentele sale.

în primul rând, să trecem peste elementele de bază. În Cassandra, fișierele de date (SSTables) existente pe disc sunt fișiere imuabile. Când ștergem ceva în Cassandra, se creează un nou SSTable care conține un marker. Acest marker indică ce partiție, rând sau celulă a fost eliminată împreună cu marcajul de timp pentru ștergerea respectivă. Acest marker de ștergere se numește piatră de mormânt.

datele șterse și piatra funerară pot coexista pe disc într-o perioadă numită gc_grace_seconds, care este implicit 10 zile. În acest timp, deși datele pot exista în continuare pe unitate, nu sunt returnate clientului dacă sunt interogate. Ceea ce înseamnă că, din punct de vedere al clientului, datele sunt șterse imediat ce executați instrucțiunea delete. Cu toate acestea, din punct de vedere operațional, atât datele, cât și piatra funerară pot exista în continuare și pot ocupa spațiu pe disc. Aceste date șterse care există încă pe disc se numesc ” date umbrite.”

N. B.: În paragraful anterior spun că datele și pietrele funerare ” pot coexista în continuare pe disc „(accent pe” cutie”), deoarece dacă apare compactarea care implică datele și pietrele funerare, atunci datele sunt evacuate. Dar piatra funerară va rămâne dacă gc_grace_seconds nu a trecut.

gc_grace_seconds este un mecanism de siguranță pentru a se asigura că piatra funerară are suficient timp pentru a se reproduce la toate nodurile care au o replică a datelor umbrite. Pentru ca acest mecanism de siguranță să aibă succes, trebuie să puteți repara clusterul la fiecare gc_grace_seconds. Ceea ce înseamnă că, dacă utilizați implicit 10 zile pentru gc_grace_seconds, o reparație trebuie să fie pornit și terminat în fiecare 10 zile. Repararea servește scopului de a preveni datele zombie din cluster. Nu voi intra în detalii despre cum se poate întâmpla acest lucru, dar, practic, datele zombie apar atunci când ștergeți datele, dar se întorc ceva mai târziu.

după trecerea gc_grace_seconds, datele și piatra funerară pot fi în cele din urmă evacuate de pe disc, recuperând spațiul pe disc folosit anterior de acestea (figura 1). ETA pentru a elibera spațiul pe disc este unul dintre primele puncte pe care vreau să le clarific în acest post. Când utilizați Cassandra, mulți oameni găsesc acest mecanism surprinzător, adică, că după ștergerea datelor, Datele există încă pe disc. Această confuzie este de obicei clarificată rapid de îndată ce oamenii învață despre pietre funerare și gc_grace_seconds. Cu toate acestea, se pare că operatorii tind să creadă că datele și pietrele funerare sunt evacuate imediat după terminarea gc_grace_seconds. De fapt, este esențial să fii conștient că acest lucru s-ar putea să nu fie (și tinde să nu fie) adevărat. De obicei, durează mai mult decât gc_grace_seconds pentru ca această evacuare să se întâmple și spațiul pe disc recuperat.

Figura 1-compactarea datelor umbrite cu pietre funerare expirate și neexpirate

evacuarea menționată mai sus are loc atunci când are loc compactarea care implică SSTables care au datele umbrite și piatra funerară. Numai atunci, datele sunt eliminate în mod eficient, iar spațiul pe disc recuperat. Este important să rețineți că, chiar dacă gc_grace_seconds a trecut și SSTable-ul cu datele umbrite este compactat cu un alt SSTable care nu are piatra funerară, atunci datele umbrite nu sunt șterse. Același lucru se întâmplă și pentru markerii de piatră funerară, adică dacă SSTable-ul cu piatra funerară nu este compactat cu toate SSTables-urile care mai au date care au fost șterse, atunci piatra funerară nu este evacuată de pe disc. Motivul pentru care se întâmplă acest lucru este că, în timpul compactării, Cassandra nu știe ce este în SSTables care nu sunt implicate în compactare. Deci nu are cum să știe că poate arunca datele, deoarece nu poate vedea piatra funerară. Puteți vedea acest lucru în Figura 2 unde, deși gc_grace_seconds a trecut pentru ambele pietre funerare, nimic nu este evacuat după compactare.

Figura 2-compactarea datelor umbrite și a pietrelor lor funerare separat

datorită utilizării discului de către date și markerul pietrei funerare, acumularea de pietre funerare poate afecta latența citirii, deoarece Cassandra trebuie să citească o mulțime de pietre funerare înainte de a returna date live.

ștergerea datelor nu este de obicei o problemă dacă aceste ștergeri sunt mici și rare. Deoarece, de-a lungul ciclului de viață al compactării naturale, Cassandra recuperează în cele din urmă spațiul pe disc și pietrele funerare curățate. Cu toate acestea, dacă ștergeți o cantitate mare de date simultan, acest lucru creează multe pietre funerare și poate avea un impact rapid asupra latenței dvs. de citire.

dacă trebuie să ștergeți o cantitate mare de date ad-hoc, atunci există câțiva pași în următoarea postare pe blog pe care îi puteți lua pentru a atenua riscurile.

e-mail

autor

  • Pedro Gordo

vrei să lucrezi cu Pedro? Programează un apel tehnic.

Lasă un răspuns

Adresa ta de email nu va fi publicată.