undersøgelse af livscyklussen for gravsten i Apache Cassandra

dette indlæg er den første del af en række blogindlæg vedrørende livscyklus og styring af gravsten.

sletning og udløb af data i Cassandra er noget, du bør omhyggeligt planlægge. Især hvis du er ved at slette en massiv mængde data på en gang. Uden ordentlig planlægning kan dette medføre problemer for klyngen som en stigning i læse-latenstid og diskbrugsfodaftryk. I hele dette indlæg, Jeg vil beskrive en måde at tackle dette og dets forbehold på.

lad os først gennemgå det grundlæggende. I Cassandra er datafilerne (SSTables), der findes på disken, uforanderlige filer. Når vi sletter noget i Cassandra, oprettes en ny SSTable, der indeholder en markør. Denne markør angiver, hvilken partition, række eller celle der blev fjernet sammen med tidsstemplet for den pågældende sletning. Denne sletningsmarkør kaldes en gravsten.

de slettede data og gravstenen kan eksistere sammen på disken i en periode kaldet gc_grace_seconds, som som standard er 10 dage. I løbet af denne tid, selvom dataene stadig kan eksistere på drevet, returneres de ikke til klienten, hvis de bliver spurgt. Hvilket betyder, at fra et klientperspektiv slettes dataene, så snart du udfører sletningserklæringen. Fra et operationelt synspunkt kan både data og gravsten dog stadig eksistere og optage plads på disken. Disse slettede data, der stadig findes på disken, kaldes “skyggede data.”

N. B.: I det foregående afsnit siger jeg, at dataene og gravstenene “stadig kan eksistere sammen på disken” (vægt på “dåsen”), fordi hvis der opstår komprimering, der involverer dataene og gravstenene, udsættes dataene. Men gravstenen forbliver, hvis gc_grace_seconds ikke er gået.

gc_grace_seconds er en sikkerhedsmekanisme, der sikrer, at gravstenen har tid nok til at replikere til alle noder, der har en kopi af de skyggede data. For at denne sikkerhedsmekanisme skal lykkes, skal du være i stand til at reparere klyngen hver gc_grace_seconds. Det betyder, at hvis du bruger standard 10 dage for gc_grace_seconds, skal en reparation startes og afsluttes inden for hver 10 dage. Reparationen har til formål at forhindre data i klyngen. Jeg vil ikke gå ind i detaljerne om, hvordan dette kan ske, men dybest set opstår der data, når du sletter data, men det vender tilbage engang senere.

efter at gc_grace_seconds er gået, kan dataene og gravstenen endelig udvises fra disken og gendanne den diskplads, de tidligere har brugt (Figur 1). ETA for at frigive diskpladsen er et af de første punkter, som jeg vil afklare i dette indlæg. Når man bruger Cassandra, finder mange mennesker denne mekanisme overraskende, dvs.at dataene efter sletning af data stadig findes på disken. Denne forvirring afklares normalt hurtigt, så snart folk lærer om gravsten og gc_grace_seconds. Det ser imidlertid ud til, at operatører har en tendens til at tro, at dataene og gravstenene udsættes lige efter, at gc_grace_seconds er afsluttet. Faktisk er det vigtigt at være opmærksom på, at dette måske ikke (og har tendens til ikke) at være sandt. Normalt tager det længere tid end gc_grace_seconds for denne udsættelse at ske, og diskpladsen genoprettes.

Figur 1-komprimering af skyggede data med udløbne og ikke-udløbne gravsten

udsættelsen nævnt ovenfor sker, når komprimering forekommer, der involverer SSTables, der har de skyggede data og gravstenen. Først da fjernes dataene effektivt, og diskpladsen genoprettes. Det er vigtigt at bemærke, at selvom gc_grace_seconds er gået, og SSTable med de skyggede data komprimeres med en anden sstable, der ikke har gravstenen, bliver de skyggede data ikke renset. Det samme sker for gravstenmarkørerne, dvs.hvis Sstabellen med gravstenen ikke komprimeres med alle Sstabellerne, der stadig har data, der blev slettet, bliver gravstenen ikke udsat fra disken. Årsagen til, at dette sker, er, at Cassandra under komprimering ikke ved, hvad der er i SSTables, der ikke er involveret i komprimeringen. Så det har ingen måde at vide, at det kan kassere dataene, da det ikke kan se gravstenen. Du kan se dette i figur 2, Hvor, selvom gc_grace_seconds er gået for begge gravsten, intet er smidt ud efter komprimering.

figur 2-komprimering af skyggefulde data og deres gravsten separat

på grund af diskforbruget af dataene og gravstenmarkøren kan akkumuleringen af gravsten påvirke Læsetid, fordi Cassandra har brug for at læse masser af gravsten, før han returnerer live data.

sletning af data er normalt ikke et problem, hvis disse sletninger er små og sparsomme. Fordi Cassandra i løbet af den naturlige komprimeringslivscyklus til sidst genvinder diskpladsen og de rensede gravsten. Men hvis du sletter en stor mængde data på en gang, skaber det mange gravsten og kan hurtigt påvirke din læsetid.

hvis du har brug for at slette en stor mængde data på ad hoc-basis, er der nogle trin i det næste blogindlæg, som du kan tage for at mindske risici.

e-mail

forfatter

  • Pedro Gordo

interesseret i at arbejde med Pedro? Planlæg et teknisk opkald.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.