Examining the Lifecycle of Tombstones in Apache Cassandra

dit artikel is het eerste deel van een serie blogberichten over de levenscyclus en het beheer van grafstenen.

het verwijderen en verlopen van gegevens in Cassandra is iets dat u zorgvuldig moet plannen. Vooral als je op het punt staat om een enorme hoeveelheid gegevens tegelijk te verwijderen. Zonder de juiste planning kan dit problemen voor het cluster opleveren, zoals een toename van de leeslatentie en de voetafdruk voor schijfgebruik. In deze post Zal ik een manier beschrijven om dit en zijn kanttekeningen aan te pakken.

laten we eerst de basis doornemen. In Cassandra zijn de gegevensbestanden (SSTables) die op schijf bestaan onveranderlijke bestanden. Wanneer we iets in Cassandra verwijderen, wordt een nieuwe SSTable gemaakt die een marker bevat. Deze markering geeft aan welke partitie, rij of cel is verwijderd samen met de tijdstempel voor die verwijdering. Deze schrapping marker wordt een grafsteen genoemd.

de verwijderde gegevens en de grafsteen kunnen naast elkaar bestaan op de schijf gedurende een periode genaamd gc_grace_seconden, die standaard 10 dagen is. Gedurende deze tijd, hoewel de gegevens nog steeds kunnen bestaan op de schijf, Het is niet terug naar de client als gevraagd. Wat betekent dat vanuit een client perspectief, de gegevens worden verwijderd zodra u de Delete statement uit te voeren. Nochtans, vanuit een operationeel standpunt, kunnen zowel de gegevens als de grafsteen nog bestaan en ruimte op de schijf bezetten. Deze verwijderde gegevens die nog steeds bestaat op de schijf wordt genoemd ” shadowed data.”

N. B.: In de vorige paragraaf zeg ik dat de gegevens en de grafstenen “kan nog steeds naast elkaar bestaan op schijf” (nadruk op de “kan”), want als verdichting optreedt dat de gegevens en de grafstenen omvat, dan is de gegevens worden uitgezet. Maar de grafsteen blijft als gc_grace_seconden niet voorbij is.

de gc_grace_seconden is een veiligheidsmechanisme om ervoor te zorgen dat de grafsteen voldoende tijd heeft om te repliceren naar alle knooppunten die een replica van de schaduwgegevens hebben. Om dit veiligheidsmechanisme te laten slagen, moet u in staat zijn om het cluster elke gc_grace_seconden te repareren. Dit betekent dat als u de standaard 10 dagen voor gc_grace_seconden gebruikt, een reparatie moet worden gestart en voltooid binnen elke 10 dagen. De reparatie dient om zombie-gegevens in het cluster te voorkomen. Ik zal niet ingaan op de details van hoe dit kan gebeuren, maar in principe, zombie data treedt op wanneer u gegevens te verwijderen, maar het komt later terug.

nadat gc_grace_seconds is gepasseerd, kunnen de gegevens en de grafsteen eindelijk van de schijf worden verwijderd, waardoor de eerder door hen gebruikte schijfruimte wordt hersteld (figuur 1). De ETA om de schijfruimte vrij te geven is een van de eerste punten die ik in dit bericht wil verduidelijken. Bij het gebruik van Cassandra, veel mensen vinden dit mechanisme verrassend, dat wil zeggen, dat na het verwijderen van gegevens, de gegevens nog steeds bestaat op de schijf. Deze verwarring wordt meestal snel opgehelderd zodra mensen leren over grafstenen en gc_grace_seconden. Echter, het lijkt erop dat exploitanten de neiging om te denken dat de gegevens en de grafstenen worden uitgezet direct nadat gc_grace_seconds is voltooid. In feite is het essentieel om je ervan bewust te zijn dat dit misschien niet (en heeft de neiging niet) waar is. Meestal duurt het langer dan gc_grace_seconden voordat deze uitzetting plaatsvindt en de schijfruimte is hersteld.

figuur 1 – verdichten van schaduwgegevens met verlopen en niet-verlopen grafstenen

de hierboven genoemde uitzetting vindt plaats wanneer verdichting plaatsvindt waarbij de SSTables met de schaduwgegevens en de grafsteen betrokken zijn. Alleen dan worden de gegevens effectief verwijderd en wordt de schijfruimte hersteld. Het is belangrijk op te merken dat zelfs als gc_grace_seconds is verstreken en de sstable met de schaduw gegevens wordt gecomprimeerd met een andere SSTable die niet de grafsteen, dan is de schaduw gegevens niet gezuiverd. Hetzelfde gebeurt voor de grafsteen markers, dat wil zeggen, als de SSTable met de grafsteen niet wordt gecomprimeerd met alle SSTables die nog steeds gegevens die werd verwijderd, dan is de grafsteen niet verwijderd uit de schijf. De reden dat dit gebeurt is dat Cassandra tijdens het verdichten niet weet wat er in de SSTables zit die niet betrokken zijn bij de verdichting. Dus het kan niet weten dat het de gegevens kan negeren omdat het de grafsteen niet kan zien. U kunt dit zien in Figuur 2 waar, hoewel gc_grace_seconden is verstreken voor beide grafstenen, niets wordt uitgezet na de verdichting.

Figuur 2-het afzonderlijk comprimeren van schaduwgegevens en hun grafstenen

door het schijfgebruik door de gegevens en de grafsteenmarker kan de accumulatie van grafstenen een impact hebben op de leeslatentie, omdat Cassandra veel grafstenen moet lezen voordat ze levende gegevens retourneren.

het verwijderen van gegevens is meestal geen probleem als deze verwijderingen klein en schaars zijn. Omdat, over de natuurlijke verdichting levenscyclus, Cassandra uiteindelijk herstelt de schijfruimte en de gezuiverd grafstenen. Echter, als je het verwijderen van een grote hoeveelheid gegevens in een keer, dat creëert veel grafstenen en kan snel invloed hebben op uw lees-latency.

als u een grote hoeveelheid gegevens op ad-hoc basis moet verwijderen, dan zijn er enkele stappen in de volgende blogpost die u kunt nemen om risico ‘ s te beperken.

e-mail

Auteur

  • Pedro Gordo

Geïnteresseerd in het werken met Pedro? Plan een technisch gesprek.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.