Cassandra genererer gravsten, når du sletter data. Under nogle omstændigheder kan overskydende gravsten forårsage lange GC-pauser, latenstid, læsefejl eller ud af bunkefejl. Denne artikel giver råd til styring af gravsten.

Indholdsfortegnelse

Hvad er en gravsten?

i Cassandra slettes slettede data ikke straks fra disken. I stedet skriver Cassandra en særlig værdi, kendt som en gravsten, for at indikere, at data er blevet slettet. Gravsten forhindrer, at slettede data returneres under læsninger, og vil til sidst tillade, at dataene tabes via komprimering.

gravsten er skriver – de går gennem den normale skrivevej, optager plads på disken og gør brug af Cassandras konsistensmekanismer. Gravsten kan formeres over klyngen via tip og reparationer. Hvis en klynge administreres korrekt, sikrer dette, at data forbliver slettet, selvom en node er nede, når sletningen udstedes.

gravsten er genereret af:

• slet udsagn
• Indstilling af TTLS
• indsættelse af null-værdier
• indsættelse af data i dele af en samling.

hvad er den normale livscyklus for gravsten?

gravsten er skrevet med et tidsstempel. Under ideelle omstændigheder vil gravsten (og deres tilknyttede data) blive droppet under compactions efter en vis tid er gået.

følgende tre kriterier skal være opfyldt for at gravsten skal fjernes:

• gravstenene blev oprettet for mere end gc_grace_seconds siden.
• tabellen, der indeholder gravstenen, er involveret i en komprimering.
• alle sstables, der kan indeholde de relevante data, er involveret i komprimeringen.

hver tabel har en gc_grace_seconds indstilling. Som standard er dette indstillet til 864000, hvilket svarer til 10 dage. Hensigten er at give tid til klyngen til at opnå konsistens via reparationer (og dermed forhindre opstandelse af slettede data).

gravsten vil kun blive droppet via en komprimering, hvis alle sstables, der kan indeholde de relevante data, er involveret i komprimeringen. Hvis der er gået meget tid mellem at skrive de originale data og udstede sletningen, bliver dette mindre sandsynligt:

• størrelse-differentieret Komprimeringsstrategi vil komprimere sstables af samme størrelse sammen. Data har tendens til at bevæge sig ind i større sstables, når de bliver ældre, så gravstenen (i en ny, lille sstable) er usandsynligt at blive komprimeret med dataene (i en gammel, stor sstable).
• nivelleret Komprimeringsstrategi er opdelt i mange niveauer, der komprimeres separat. Gravstenen vil blive skrevet i niveau 0 og vil effektivt ‘jage’ dataene gennem niveauerne – det skal i sidste ende indhente.
• Tidsvinduekomprimeringsstrategi (eller dato-differentieret Komprimeringsstrategi) komprimerer aldrig gravstenen med dataene, hvis de er skrevet i forskellige tidsvinduer.

hvornår forårsager gravsten problemer?

Diskbrug

Når data slettes, frigøres pladsen faktisk ikke i mindst den gc_grace-periode, der er angivet i tabelindstillingerne. Dette kan forårsage problemer, hvis en klynge hurtigt fyldes op.

under nogle omstændigheder frigøres rummet aldrig uden manuel indgriben.

Læs ydeevne

alvorlige ydelsesproblemer kan opstå, hvis læsninger støder på et stort antal gravsten.

ydelsesproblemer vil sandsynligvis forekomme med følgende typer forespørgsler:

• forespørgsler, der kører over alle partitioner i en tabel (“vælg * fra keyspace.tabel”)
• Range forespørgsler (“vælg * fra keyspace.tabel, hvor værdi > H “eller “hvor værdi i (værdi1, værdi2,…)”
• enhver forespørgsel, der kun kan køres med en “Tillad filtrering” – klausul.

disse præstationsproblemer opstår på grund af gravstenens opførsel under læsning. I en rækkeforespørgsel bruger din Cassandra-driver normalt Personsøgning, hvilket gør det muligt for noder at returnere et begrænset antal svar ad gangen. Når cassandra gravsten er involveret, skal noden opbevare de gravsten, den er stødt på i hukommelsen, og returnere dem til koordinatoren, hvis en af de andre replikaer ikke er klar over, at de relevante data er blevet slettet. Gravstenene kan ikke søges, fordi det er vigtigt at returnere dem alle, så latenstid og hukommelsesbrug øges proportionalt med antallet af gravsten, der opstår.

hvorvidt gravstenene vil blive stødt afhænger af, hvordan dataene gemmes og hentes. Bruges til at gemme data i en kø (hvilket ikke anbefales), kan forespørgsler støde på titusinder af gravsten for at returnere et par rækker data.

Hvordan kan jeg diagnosticere tombstone-relaterede problemer?

forespørgsler, der støder på et stort antal gravsten, vises i logfilerne. Som standard vil en læsning, der støder på mere end tusind gravsten, generere en advarsel:

advar org.apache.cassandra.dB.ReadCommand Læs 0 levende rækker og 87051 gravsten celler for forespørgsel vælg * fra eksempel.tabel

som standard vil det at støde på mere end 100.000 gravsten få forespørgslen til at mislykkes med en Gravstenovervældende undtagelse.

for at kontrollere, om tombstone-læsninger forårsager ydelsesproblemer, skal du kontrollere, om læsningerne korrelerer med en stigning i Læsetid og GC-pausevarighed.

hvis det er klart, at gravsten er problemerne, kan følgende teknikker hjælpe med at indsnævre problemets omfang:

• antallet af gravsten, der returneres i en bestemt forespørgsel, kan findes ved at køre forespørgslen i cklsh med sporing aktiveret.
• statistik for antallet af gravsten, der er fundet for nylig i hver tabel, er tilgængelige i output franodetool cfstats.
• for klynger i vores administrerede tjeneste er statistikker for nyligt stødte gravsten tilgængelige på klyngesiden i Metriklister> Tabelinfo. Dette omfatter levende celler pr læse og gennemsnit og maks gravsten pr læse, opdelt efter node eller tabel for en given periode.
• mere detaljerede oplysninger om lagrede gravsten kan findes ved hjælp af IC-tools.

Hvordan kan jeg undgå problemer med gravsten?

følgende indstillinger kan hjælpe:

• undgå forespørgsler, der kører på alle partitioner i tabellen (f.eks. forespørgsler uden hvor-klausul eller enhver forespørgsel, der kræver Tillad filtrering).
• ændre range forespørgsler for at undgå at forespørge slettede data, eller operere på en snævrere vifte af data. Ydelsesproblemer opstår kun, hvis gravstenene læses, og skaleres med antallet af læste gravsten.
• Design datamodellen for at undgå at slette store mængder data.
• hvis du planlægger at slette alle data i en tabel, skal du afkorte eller slippe tabellen for at fjerne alle data uden at generere gravsten.
• brug en standard time-to-live-værdi. Dette fungerer kun effektivt, hvis den primære nøgle til dine data er tidsbaseret, dine data er skrevet i kronologisk rækkefølge, og dataene slettes på en kendt dato. For at gøre dette skal du indstille en standard TTL i indstillingerne på tabelniveau og indstille en tidsbaseret komprimeringsstrategi (Tidsvindueskompaktionsstrategi hvis tilgængelig, DateTieredCompactionStrategy ellers). Dette vil stadig skabe gravsten, men hele sstables vil blive effektivt droppet, når TTL på alt deres indhold er gået.

Hvordan kan jeg slippe af med eksisterende gravsten?

under de fleste omstændigheder er den bedste tilgang at vente på, at gravstenen komprimeres normalt. Hvis presserende problemer med ydeevne eller diskbrug kræver mere øjeblikkelig handling, er der to nodetool-kommandoer, der kan bruges til at tvinge compactions, som kan hjælpe med at droppe gravsten. Disse bør betragtes som en sidste udvej – i en sund klynge med en veldesignet datamodel er det ikke nødvendigt at køre manuelle kompaktioner.

Runningnodetool compact tvinger en komprimering af alle sstables. Dette kræver en stor mængde ledig diskplads. Argumenter for Keyspace og tabel skal bruges til at begrænse komprimeringen til de tabeller, hvor gravsten er et problem. På tabeller, hvor der anvendes Komprimeringsstrategi i størrelse, kan denne kommando føre til oprettelsen af en enorm sstabel, der aldrig vil have jævnaldrende at komprimere med; hvis–split-output flag er tilgængeligt, skal det bruges.

nodetool garbagecollect kommandoen er tilgængelig fra Cassandra 3.10 og fremefter. Denne kommando kører en række mindre compactions, der også kontrollerer overlappende sstables. Det er mere CPU-intensivt og tidskrævende end nodetool compact, men kræver mindre ledig diskplads.

gravsten fjernes kun, hvis gc_grace_seconds er gået siden gravstenene blev oprettet. Det tilsigtede formål med gc_grace_seconds er at give tid til reparationer for at gendanne konsistensen i klyngen, så vær forsigtig, når du ændrer den – for tidligt at fjerne gravsten kan resultere i opstandelse af slettede data. Indstillingen gc_grace_seconds påvirker også udløbet af tip, der genereres til antydet handoff, så det er farligt at reducere gc_grace_seconds under varigheden af det antydede handoff-vindue (som standard 3 timer).

reparationer

reparationer kan forsinke eller forhindre tab af gravsten. Når en fuld eller trinvis reparation køres, markeres de sstables, den har påvirket, som repareret; i efterfølgende kompakteringer komprimeres disse tabeller separat fra sstables, der ikke er blevet repareret. Hvis gravsten er i ikke-reparerede sstables, og de skyggefulde data er i reparerede sstables (eller omvendt), kan dataene ikke tabes, fordi sstables ikke kan komprimeres sammen.
Hvis du jævnligt kører fuld eller trinvise reparationer på klyngen, bør dette ikke være for meget af et problem, da gravsten og data i sidste ende vil ende med at blive repareret. Men hvis du har en blanding af reparerede og ikke-reparerede data, og du ikke regelmæssigt kører reparationer, kan dette blive et problem. sstablemetadata kan hjælpe dig med at inspicere den reparerede status for dine sstables for at finde ud af, om dette sker. Hvis det er, kan det være tilrådeligt at indstille alle sstables som urepareret med sstablerepairedset, så de kan komprimeres sammen.
bemærk, at reparationer under rækkevidde ikke markerer data som repareret.