Cassandra genereert grafstenen wanneer u gegevens verwijdert. Onder sommige omstandigheden, overtollige grafstenen kan leiden tot lange GC pauzes, latentie, lees storingen, of uit heap fouten. Dit artikel geeft advies voor het beheer van grafstenen.

inhoudsopgave

Wat is een grafsteen?

in Cassandra worden verwijderde gegevens niet onmiddellijk van de schijf verwijderd. In plaats daarvan schrijft Cassandra een speciale waarde, bekend als een grafsteen, om aan te geven dat gegevens zijn verwijderd. Tombstones voorkomen dat verwijderde gegevens worden geretourneerd tijdens leest, en zal uiteindelijk toestaan dat de gegevens worden gedropt via verdichting.

grafstenen zijn schrijven – ze gaan door het normale schrijfpad, nemen ruimte in op de schijf en maken gebruik van Cassandra ‘ s consistentiemechanismen. Grafstenen kunnen worden verspreid over de cluster via hints en reparaties. Als een cluster goed wordt beheerd, zorgt dit ervoor dat gegevens worden verwijderd, zelfs als een knooppunt is uitgeschakeld wanneer de verwijdering wordt verleend.

grafstenen worden gegenereerd door:

• wis statements
• TTLS instellen
• invoegen van null-waarden
• invoegen van gegevens in delen van een verzameling.

Wat is de normale levenscyclus van grafstenen?

grafstenen worden geschreven met een tijdstempel. Onder ideale omstandigheden, grafstenen (en de bijbehorende gegevens) zal worden gedropt tijdens compacties na een bepaalde tijd is verstreken.

aan de volgende drie criteria moet worden voldaan om grafstenen te verwijderen:

• de grafstenen zijn meer dan gc_grace_seconden geleden gemaakt.
• de tabel met de grafsteen is betrokken bij een verdichting.
• alle sstables die de relevante gegevens kunnen bevatten, zijn betrokken bij de verdichting.

elke tabel heeft een gc_grace_seconden instelling. Standaard is dit ingesteld op 864000, wat gelijk is aan 10 dagen. Het is de bedoeling om de cluster tijd te geven om consistentie te bereiken via reparaties (en daarmee de wederopstanding van verwijderde gegevens te voorkomen).

grafstenen zullen alleen worden verwijderd via een verdichting als alle sstables die de relevante gegevens kunnen bevatten betrokken zijn bij de verdichting. Als er veel tijd is verstreken tussen het schrijven van de oorspronkelijke gegevens en het uitgeven van de DELETE, wordt dit minder waarschijnlijk:

• Size-Tiered Compaction Strategy compact sstables van vergelijkbare grootte samen. Gegevens hebben de neiging om naar grotere sstables als het veroudert, zodat de grafsteen (in een nieuwe, kleine sstable) waarschijnlijk niet worden gecomprimeerd met de gegevens (in een oude, grote sstable).
• Niveaured Verdichtingsstrategie wordt opgesplitst in vele niveaus die afzonderlijk worden verdicht. De grafsteen zal worden geschreven in niveau 0 en zal effectief ‘jagen’ de gegevens door de niveaus – het moet uiteindelijk inhalen.
• Time-Window Compaction Strategy (of Date-Tiered Compaction Strategy) zal de grafsteen nooit comprimeren met de gegevens als ze in verschillende tijdvensters zijn geschreven.

wanneer veroorzaken grafstenen problemen?

schijfgebruik

wanneer gegevens worden verwijderd, zal de ruimte niet daadwerkelijk worden vrijgemaakt gedurende ten minste de gc_grace-periode die is ingesteld in de tabel-instellingen. Dit kan problemen veroorzaken als een cluster snel vol raakt.

onder sommige omstandigheden zal de ruimte nooit worden vrijgemaakt zonder handmatige interventie.

Leesprestatie

ernstige prestatieproblemen kunnen optreden als het lezen grote aantallen grafstenen tegenkomt.

prestatieproblemen zijn het meest waarschijnlijk bij de volgende typen query’s:

• Queries die over alle partities in een tabel lopen (“select * from keyspace.table”)
• Range queries (“select * from keyspace.tabel waar waarde > x”, of “waar waarde IN (value1, value2,…) “
• elke query die alleen kan worden uitgevoerd met een” ALLOW FILTERING ” clausule.

deze prestatieproblemen treden op door het gedrag van grafstenen tijdens het lezen. In een range-query gebruikt uw Cassandra-stuurprogramma normaal gesproken paging, waardoor nodes een beperkt aantal reacties tegelijk kunnen retourneren. Wanneer cassandra grafstenen zijn betrokken, moet de knoop de grafstenen die het heeft ontmoet in het geheugen te houden en terug te geven aan de coördinator, in het geval een van de andere replica ‘ s niet op de hoogte is dat de relevante gegevens is verwijderd. De grafstenen kunnen niet worden opgepiept omdat het essentieel is om ze allemaal terug te geven, zodat latentie en geheugengebruik evenredig toenemen met het aantal grafstenen aangetroffen.

of de grafstenen zullen worden aangetroffen hangt af van de manier waarop de gegevens worden opgeslagen en opgehaald. Als Cassandra bijvoorbeeld wordt gebruikt om gegevens in een wachtrij op te slaan (wat niet wordt aanbevolen), kunnen query ‘ s tienduizenden grafstenen tegenkomen om een paar rijen gegevens terug te geven.

Hoe kan ik grafsteengerelateerde problemen diagnosticeren?

Queries die grote aantallen grafstenen tegenkomen zullen in de logs verschijnen. Standaard zal een lees die meer dan duizend grafstenen tegenkomt een waarschuwing genereren:

WARN org.Apache.cassandra.dB.ReadCommand lees 0 live rijen en 87051 tombstone cellen voor query SELECT * uit voorbeeld.tabel

standaard zal het tegenkomen van meer dan 100.000 grafstenen ervoor zorgen dat de query mislukt met een Tombstone Overhelmingexception.

om te controleren of Tombstone-reads prestatieproblemen veroorzaken, moet u controleren of de reads correleren met een toename van de leeslatentie en de duur van de GC-pauze.

als het duidelijk is dat grafstenen de problemen zijn, kunnen de volgende technieken helpen de omvang van het probleem te beperken:

• het aantal grafstenen dat in een bepaalde query wordt geretourneerd, kan worden gevonden door de query in cqlsh uit te voeren met tracing ingeschakeld.
• statistieken voor het aantal grafstenen dat onlangs in elke tabel is aangetroffen, zijn beschikbaar in de output van nodetool cfstats.
• voor clusters in onze managed service zijn statistieken voor recent aangetroffen grafstenen beschikbaar op de clusterpagina in Metrics Lists > Table Info. Dit omvat levende cellen per gelezen en gemiddelde en max grafstenen per gelezen, opgesplitst door knoop of tabel voor een bepaalde periode.
• meer gedetailleerde informatie over opgeslagen grafstenen kan worden gevonden met behulp van ic-tools.

Hoe kan ik tombstone-problemen vermijden?

de volgende opties kunnen helpen:

• vermijd query ’s die draaien op alle partities in de tabel (bijvoorbeeld query’ s zonder WHERE-clausule, of elke query die FILTERING vereist).
• Wijzig range queries om te voorkomen dat verwijderde gegevens worden opgevraagd, of werk op een smaller gegevensbereik. Prestatieproblemen treden alleen op als de grafstenen worden gelezen, en schaal met het aantal grafstenen gelezen.
• ontwerp het gegevensmodel om te voorkomen dat grote hoeveelheden gegevens worden verwijderd.
• Als u van plan bent om alle gegevens in een tabel te verwijderen, moet u de tabel afkappen of laten vallen om alle gegevens te verwijderen zonder grafstenen te genereren.
• gebruik een standaard time-to-live-waarde. Dit werkt alleen efficiënt als de primaire sleutel van uw gegevens op tijd gebaseerd is, uw gegevens in chronologische volgorde worden geschreven en de gegevens op een bekende datum worden verwijderd. Om dit te doen, stelt u een standaard TTL in de opties op tabelniveau in en stelt u een op tijd gebaseerde verdichtingsstrategie in (TimeWindowCompactionStrategy indien beschikbaar, Datetieredcompaction Strategy anders). Dit zal nog steeds grafstenen te creëren, maar hele sstables zal efficiënt worden gedropt zodra de TTL op al hun inhoud zijn gepasseerd.

Hoe kan ik van bestaande grafstenen afkomen?

in de meeste gevallen is de beste aanpak om te wachten tot de grafsteen normaal dicht is. Als dringende prestaties of schijfgebruik problemen meer onmiddellijke actie vereisen, zijn er twee nodetool commando ‘ s die kunnen worden gebruikt om compacties te dwingen, die kunnen helpen bij het laten vallen van grafstenen. Deze moeten als een laatste redmiddel worden beschouwd-in een gezonde cluster met een goed ontworpen datamodel is het niet nodig om handmatige verdikkingen uit te voeren.

draaien nodetool compact dwingt een verdichting van alle sstables af. Dit vereist een grote hoeveelheid vrije schijfruimte. Keyspace en tabelargumenten moeten worden gebruikt om de verdichting te beperken tot de tabellen waar grafstenen een probleem zijn. Op tabellen waar Size-Tiered verdichting strategie wordt gebruikt, kan dit commando leiden tot de creatie van een enorme sstable die nooit zal hebben peers te compact met; als de vlag –split-output beschikbaar is, moet deze worden gebruikt.

het nodetool garbagecollect commando is beschikbaar vanaf Cassandra 3.10. Dit commando voert een reeks kleinere compacties uit die ook overlappende sstables controleren. Het is CPU-intensief en tijdrovend dan nodetool compact, maar vereist minder vrije schijfruimte.

grafstenen worden alleen verwijderd als gc_grace_seconden zijn verstreken sinds de grafstenen zijn gemaakt. Het beoogde doel van gc_grace_seconds is om tijd te bieden voor reparaties om de consistentie van de cluster te herstellen, dus wees voorzichtig bij het wijzigen ervan – voortijdig verwijderen van grafstenen kan resulteren in de wederopstanding van verwijderde gegevens. Ook heeft de instelling gc_grace_seconden invloed op het verlopen van hints gegenereerd voor hints handoff, dus het is gevaarlijk om gc_grace_seconden te verminderen onder de duur van het hints handoff venster (standaard 3 uur).

reparaties

reparaties kunnen het laten vallen van grafstenen vertragen of voorkomen. Wanneer een volledige of incrementele reparatie wordt uitgevoerd, worden de sstables die het heeft beïnvloed gemarkeerd als gerepareerd; in daaropvolgende compacties worden deze tabellen afzonderlijk gecomprimeerd van sstables die niet zijn gerepareerd. Als grafstenen zich in niet-gerepareerde sstables bevinden en de schaduwgegevens zich in gerepareerde sstables bevinden (of vice versa), kunnen de gegevens niet worden verwijderd omdat de sstables niet samen kunnen worden gecomprimeerd.
Als u regelmatig volledige of incrementele reparaties uitvoert op het cluster, zou dit niet te veel van een probleem moeten zijn omdat tombstones en data uiteindelijk zullen worden gerepareerd. Echter, als u een mix van gerepareerde en niet-gerepareerde gegevens, en u niet regelmatig uitvoeren van reparaties, dit kan een probleem worden. sstablemetadata kan u helpen de gerepareerde status van uw sstables te inspecteren om uit te zoeken of dit gebeurt. Als dat zo is, kan het raadzaam zijn om alle sstables in te stellen als niet-repaired met sstablerepairedset, zodat ze samen kunnen worden verdicht.
houd er rekening mee dat subrange reparaties geen gegevens markeren als gerepareerd.