Esaminare il ciclo di vita delle lapidi in Apache Cassandra

Questo post è la prima parte di una serie di post sul blog riguardanti il ciclo di vita e la gestione delle lapidi.

L’eliminazione e la scadenza dei dati in Cassandra è qualcosa che dovresti pianificare attentamente. Soprattutto se si sta per eliminare una massiccia quantità di dati in una sola volta. Senza una pianificazione adeguata, ciò può causare problemi al cluster come un aumento della latenza di lettura e dell’impronta di utilizzo del disco. In questo post, descriverò un modo per affrontare questo e le sue avvertenze.

In primo luogo, andiamo oltre le basi. In Cassandra, i file di dati (SSTables) esistenti sul disco sono file immutabili. Quando stiamo eliminando qualcosa in Cassandra, viene creato un nuovo SSTable che contiene un marker. Questo indicatore indica quale partizione, riga o cella è stata rimossa insieme al timestamp per l’eliminazione. Questo marcatore di eliminazione è chiamato una lapide.

I dati eliminati e la lapide possono coesistere sul disco durante un periodo chiamato gc_grace_seconds, che è di default 10 giorni. Durante questo periodo, sebbene i dati possano ancora esistere sull’unità, non vengono restituiti al client se interrogati. Ciò significa che dal punto di vista del client, i dati vengono eliminati non appena si esegue l’istruzione delete. Tuttavia, da un punto di vista operativo, sia i dati che la lapide possono ancora esistere e occupare spazio sul disco. Questi dati cancellati che esistono ancora sul disco sono chiamati ” dati in ombra.”

N.B.: Nel paragrafo precedente dico che i dati e le lapidi ” possono ancora coesistere su disco “(enfasi sulla” lattina”) perché se si verifica una compattazione che coinvolge i dati e le lapidi, allora i dati vengono sfrattati. Ma la lapide rimarrà se gc_grace_seconds non è passato.

Il gc_grace_seconds è un meccanismo di sicurezza per garantire che la pietra tombale ha abbastanza tempo per replicare a tutti i nodi che hanno una replica dei dati in ombra. Affinché questo meccanismo di sicurezza abbia successo, è necessario essere in grado di riparare il cluster ogni gc_grace_seconds. Significa che se si utilizzano i 10 giorni predefiniti per gc_grace_seconds, una riparazione deve essere avviata e terminata entro ogni 10 giorni. La riparazione ha lo scopo di prevenire i dati zombie nel cluster. Non entrerò nei dettagli di come ciò possa accadere, ma fondamentalmente, i dati zombie si verificano quando si eliminano i dati, ma ritornano qualche tempo dopo.

Dopo che gc_grace_seconds è passato, i dati e la lapide possono finalmente essere sfrattati dal disco, recuperando lo spazio su disco precedentemente utilizzato da loro (Figura 1). L’ETA per rilasciare lo spazio su disco è uno dei primi punti che voglio chiarire in questo post. Quando si utilizza Cassandra, molte persone trovano questo meccanismo sorprendente, cioè che dopo aver eliminato i dati, i dati esistono ancora sul disco. Questa confusione viene solitamente chiarita rapidamente non appena le persone imparano a conoscere lapidi e gc_grace_seconds. Tuttavia, sembra che gli operatori tendano a pensare che i dati e le lapidi vengano sfrattati subito dopo che gc_grace_seconds è finito. In effetti, è essenziale essere consapevoli che questo potrebbe non essere (e non tende) vero. Di solito, ci vuole più tempo di gc_grace_seconds perché questo sfratto avvenga e lo spazio su disco recuperato.

Figura 1-compattazione dei dati shadowed con lapidi scadute e non scadute

Lo sfratto di cui sopra si verifica quando si verifica la compattazione che coinvolge gli SSTables che hanno i dati shadowed e la lapide. Solo allora, i dati vengono effettivamente rimossi e lo spazio su disco recuperato. È importante notare che anche se gc_grace_seconds è passato e SSTable con i dati shadowed viene compattato con un altro SSTable che non ha la lapide, i dati shadowed non vengono eliminati. La stessa cosa accade per i marcatori di lapide, cioè se l’SSTable con la lapide non viene compattato con tutti gli SSTABLE che hanno ancora dati che sono stati eliminati, la lapide non viene sfrattata dal disco. Il motivo per cui ciò accade è che durante la compattazione, Cassandra non sa cosa c’è negli SSTables che non sono coinvolti nella compattazione. Quindi non ha modo di sapere che può scartare i dati poiché non può vedere la lapide. Puoi vederlo in Figura 2 dove, sebbene gc_grace_seconds sia passato per entrambe le lapidi, nulla viene sfrattato dopo la compattazione.

Figura 2-compattazione dei dati in ombra e delle relative lapidi separatamente

A causa dell’utilizzo del disco da parte dei dati e del marcatore lapide, l’accumulo di lapidi può influire sulla latenza di lettura, poiché Cassandra deve leggere molte lapidi prima di restituire i dati in tempo reale.

L’eliminazione dei dati di solito non è un problema se queste eliminazioni sono piccole e sparse. Perché, durante il ciclo di vita naturale della compattazione, Cassandra alla fine recupera lo spazio su disco e le lapidi eliminate. Tuttavia, se stai eliminando una grande quantità di dati contemporaneamente, ciò crea molte lapidi e può influire rapidamente sulla latenza di lettura.

Se è necessario eliminare una grande quantità di dati su una base ad hoc, poi ci sono alcuni passi nel prossimo post del blog che si può prendere per mitigare i rischi.

email

Autore

  • Pedro Gordo

Interessato a lavorare con Pedro? Pianifica una chiamata tecnica.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.