Undersøke livssyklusen til gravsteiner i apache Cassandra

Dette Innlegget er den første delen av en serie blogginnlegg om livssyklusen og forvaltningen av gravsteiner.

Slette og utløper data I Cassandra er noe som du bør nøye planlegge. Spesielt hvis du er i ferd med å slette en massiv mengde data på en gang. Uten riktig planlegging kan dette føre til problemer for klyngen som en økning i leseforsinkelse og diskbruk. Gjennom dette innlegget vil jeg beskrive en måte å takle dette og dets advarsler på.

Først, la oss gå over det grunnleggende. I Cassandra, datafiler (SSTables) eksisterende på disken er uforanderlige filer. Når vi sletter noe I Cassandra, opprettes en ny SSTable som inneholder en markør. Denne markøren angir hvilken partisjon, rad eller celle som ble fjernet sammen med tidsstempelet for slettingen. Denne slettingen markør kalles en gravstein.

de slettede dataene og gravsteinen kan sameksistere på disken i en periode kalt gc_grace_seconds, som som standard er 10 dager. I løpet av denne tiden, selv om dataene fortsatt kan finnes på stasjonen, returneres de ikke til klienten hvis de spørres. Det betyr at fra et klientperspektiv slettes dataene så snart du utfører sletteuttalelsen. Men fra et operativt synspunkt kan både dataene og gravstenen fortsatt eksistere og oppta plass på disken. Denne slettede data som fortsatt eksisterer på disken kalles » shadowed data.»

N. B.: I forrige avsnitt sier jeg at dataene og gravsteinene «fortsatt kan sameksistere på plate» (vekt på «kan») fordi hvis komprimering oppstår som involverer dataene og gravsteinene, blir dataene kastet ut. Men gravstenen vil forbli hvis gc_grace_seconds ikke har passert.

gc_grace_seconds er en sikkerhetsmekanisme for å sikre at gravsteinen har nok tid til å replikere til alle noder som har en kopi av de skyggede dataene. For at denne sikkerhetsmekanismen skal lykkes, må du kunne reparere klyngen hver gc_grace_seconds. Det betyr at hvis du bruker standard 10 dager for gc_grace_seconds, må en reparasjon startes og fullføres innen hver 10. dag. Reparasjonen tjener formålet med å hindre zombie data i klyngen. Jeg vil ikke gå inn i detaljene om hvordan dette kan skje, men i utgangspunktet oppstår zombiedata når du sletter data, men det kommer tilbake en gang senere.

etter at gc_grace_seconds har passert, kan dataene og gravsteinen endelig bli kastet ut fra disken, og gjenopprette diskplassen som tidligere ble brukt av dem (Figur 1). ETA for å frigjøre diskplass er et av de første punktene jeg vil klargjøre i dette innlegget. Når Du bruker Cassandra, finner mange mennesker denne mekanismen overraskende, dvs. at etter å ha slettet data, eksisterer dataene fortsatt på disken. Denne forvirringen blir vanligvis raskt avklart så snart folk lærer om gravsteiner og gc_grace_seconds. Det ser imidlertid ut til at operatørene har en tendens til å tro at dataene og gravsteinene blir kastet ut rett etter at gc_grace_seconds er ferdig. Faktisk er det viktig å være klar over at dette kanskje ikke (og har en tendens til ikke) å være sant. Vanligvis tar det lengre tid enn gc_grace_seconds for denne utkastelsen å skje og diskplassen gjenopprettes.

Figur 1-komprimering skygget data med utløpt og ikke-utløpt gravsteiner

utkastelsen nevnt ovenfor skjer når komprimering oppstår som involverer SSTables som har skygget data og gravstein. Først da blir dataene effektivt fjernet, og diskplassen gjenopprettes. Det er viktig å merke seg at selv om gc_grace_seconds har passert Og SSTable med skygget data komprimeres med en Annen SSTable som ikke har gravstein, så skygget data ikke er renset. Hvis Sstabellen med gravstenen ikke komprimeres med alle Sstablene som fortsatt har data som ble slettet, blir ikke gravstenen kastet ut av disken. Grunnen til at Dette skjer er at Cassandra under komprimering ikke vet hva Som er I Sstablene som ikke er involvert i komprimeringen. Så det har ingen måte å vite at det kan forkaste dataene siden det ikke kan se gravsteinen. Du kan se Dette I Figur 2 hvor, selv om gc_grace_seconds har passert for begge gravsteinene, blir ingenting kastet ut etter komprimeringen.

Figur 2-komprimering av skyggede data og deres gravsteiner separat

på grunn av diskbruken av dataene og gravsteinsmarkøren, kan akkumulering av gravsteiner påvirke leseforsinkelsen, Fordi Cassandra må lese mange gravsteiner før de returnerer live data.

Sletting av data Er vanligvis ikke et problem hvis disse slettingene er små og sparsomme. Fordi, Over den naturlige komprimeringslivssyklusen, Gjenoppretter Cassandra til slutt diskplassen og de rensede gravsteinene. Men hvis du sletter en stor mengde data samtidig, skaper det mange gravsteiner og kan raskt påvirke leseforsinkelsen.

hvis du trenger å slette en stor mengde data på en ad hoc basis, så er det noen trinn i neste blogginnlegg som du kan ta for å redusere risikoen.

e-post

Forfatter

  • Pedro Gordo

interessert i Å jobbe Med Pedro? Planlegg en teknisk samtale.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.