Cassandra genera lapidi quando si eliminano i dati. In alcune circostanze, le lapidi in eccesso possono causare lunghe pause GC, latenza, errori di lettura o errori di heap. Questo articolo fornisce consigli per la gestione di lapidi.

Sommario

Che cos’è una lapide?

In Cassandra, i dati eliminati non vengono eliminati immediatamente dal disco. Invece, Cassandra scrive un valore speciale, noto come una lapide, per indicare che i dati sono stati cancellati. Le lapidi impediscono la restituzione dei dati eliminati durante le letture e alla fine consentono di eliminare i dati tramite la compattazione.

Le lapidi sono scritture: attraversano il normale percorso di scrittura, occupano spazio sul disco e fanno uso dei meccanismi di coerenza di Cassandra. Le lapidi possono essere propagate attraverso il cluster tramite suggerimenti e riparazioni. Se un cluster viene gestito correttamente, ciò garantisce che i dati rimangano eliminati anche se un nodo è inattivo quando viene emessa l’eliminazione.

Le lapidi sono generate da:

• DELETE statements
• Setting TTLs
• Inserimento di valori null
• Inserimento di dati in parti di una raccolta.

Qual è il normale ciclo di vita delle lapidi?

Le lapidi sono scritte con un timestamp. In circostanze ideali, le lapidi (e i loro dati associati) verranno eliminate durante le compazioni dopo un certo periodo di tempo.

I seguenti tre criteri devono essere soddisfatti per la rimozione delle lapidi:

• Le lapidi sono state create più di gc_grace_seconds fa.
• La tabella contenente la lapide è coinvolta in una compattazione.
• Tutti gli sstables che potrebbero contenere i dati rilevanti sono coinvolti nella compattazione.

Ogni tabella ha un’impostazione gc_grace_seconds. Per impostazione predefinita, questo è impostato su 864000, che equivale a 10 giorni. L’intenzione è quella di fornire tempo per il cluster per raggiungere la coerenza tramite riparazioni (e quindi, prevenire la resurrezione dei dati cancellati).

Le lapidi verranno eliminate tramite una compattazione solo se tutti gli sstable che potrebbero contenere i dati rilevanti sono coinvolti nella compattazione. Se è trascorso molto tempo tra la scrittura dei dati originali e l’emissione dell’ELIMINAZIONE, questo diventa meno probabile:

• La strategia di compattazione a più livelli comprimerà insieme sstables di dimensioni simili. I dati tendono a spostarsi in sstable più grandi man mano che invecchiano, quindi è improbabile che la lapide (in un nuovo, piccolo sstable) venga compattata con i dati (in un vecchio, grande sstable).
• La strategia di compattazione livellata è suddivisa in molti livelli che vengono compattati separatamente. La lapide sarà scritto nel livello 0 e sarà effettivamente ‘inseguire’ i dati attraverso i livelli – dovrebbe alla fine recuperare il ritardo.
• La strategia di compattazione della finestra temporale (o la strategia di compattazione a livelli di data) non compatterà mai la lapide con i dati se sono scritti in finestre temporali diverse.

Quando le lapidi causano problemi?

Utilizzo del disco

Quando i dati vengono eliminati, lo spazio non verrà effettivamente liberato per almeno il periodo gc_grace impostato nelle impostazioni della tabella. Ciò può causare problemi se un cluster si sta rapidamente riempiendo.

In alcune circostanze, lo spazio non verrà mai liberato senza un intervento manuale.

Leggi prestazioni

Gravi problemi di prestazioni possono verificarsi se le letture incontrano un gran numero di lapidi.

È più probabile che si verifichino problemi di prestazioni con i seguenti tipi di query:

• Query che girano su tutte le partizioni in una tabella (“select * from keyspace.tabella”)
• Query di intervallo (“seleziona * dallo spazio delle chiavi.tabella WHERE value> x”, o “WHERE value IN (value1, value2,…) “
• Qualsiasi query che può essere eseguita solo con una clausola “ALLOW FILTERING”.

Questi problemi di prestazioni si verificano a causa del comportamento delle lapidi durante le letture. In una query di intervallo, il driver Cassandra utilizzerà normalmente il paging, che consente ai nodi di restituire un numero limitato di risposte alla volta. Quando sono coinvolte le lapidi di cassandra, il nodo deve mantenere in memoria le lapidi che ha incontrato e restituirle al coordinatore, nel caso in cui una delle altre repliche non sia a conoscenza che i dati rilevanti sono stati cancellati. Le lapidi non possono essere paginate perché è essenziale restituirle tutte, quindi la latenza e l’uso della memoria aumentano proporzionalmente al numero di lapidi incontrate.

Se le lapidi verranno incontrate dipende dal modo in cui i dati vengono memorizzati e recuperati. Ad esempio, se Cassandra viene utilizzato per memorizzare i dati in una coda (che non è raccomandato), le query possono incontrare decine di migliaia di lapidi per restituire alcune righe di dati.

Come posso diagnosticare i problemi relativi alla lapide?

Le query che incontrano un gran numero di lapidi verranno visualizzate nei registri. Per impostazione predefinita, una lettura che incontra più di mille lapidi genererà un avviso:

WARN org.Apache.Cassandra.DB.ReadCommand Leggere 0 righe live e 87051 celle tombstone per query SELECT * DALL’esempio.tabella

Per impostazione predefinita, incontrando più di 100.000 lapidi causerà il fallimento della query con un’eccezione TombstoneOverwhelmingException.

Per verificare se le letture di tombstone causano problemi di prestazioni, verificare se le letture sono correlate con un aumento della latenza di lettura e della durata della pausa GC.

Se è chiaro che le lapidi sono i problemi, le seguenti tecniche possono aiutare a restringere l’ambito del problema:

• Il numero di lapidi restituite in una particolare query può essere trovato eseguendo la query in cqlsh con tracciamento abilitato.
• Le statistiche per il numero di lapidi incontrate di recente in ogni tabella sono disponibili nell’output di nodetool cfstats.
• Per i cluster nel nostro servizio gestito, le statistiche per le lapidi riscontrate di recente sono disponibili nella pagina cluster in Metrics Lists > Informazioni sulla tabella. Ciò include celle vive per lettura e lapidi medie e massime per lettura, suddivise per nodo o tabella per un determinato periodo di tempo.
• Informazioni più dettagliate sulle lapidi memorizzate possono essere trovate utilizzando ic-tools.

Come posso evitare problemi di lapide?

Le seguenti opzioni possono aiutare:

• Evitare query che verranno eseguite su tutte le partizioni della tabella (ad esempio query senza clausola WHERE o qualsiasi query che richiede il FILTRAGGIO CONSENTI).
• Modificare le query di intervallo per evitare di interrogare i dati cancellati o operare su un intervallo più ristretto di dati. I problemi di prestazioni si verificano solo se le lapidi vengono lette e ridimensionate con il numero di lapidi lette.
• Progettare il modello di dati per evitare l’eliminazione di grandi quantità di dati.
• Se si prevede di eliminare tutti i dati in una tabella, troncare o rilasciare la tabella per rimuovere tutti i dati senza generare lapidi.
• Utilizzare un valore predefinito time-to-live. Questo funziona in modo efficiente solo se la chiave primaria dei tuoi dati è basata sul tempo, i tuoi dati sono scritti in ordine cronologico e i dati verranno cancellati a una data nota. A tale scopo, impostare un TTL predefinito nelle opzioni a livello di tabella e impostare una strategia di compattazione basata sul tempo (TimeWindowCompactionStrategy se disponibile, DateTieredCompactionStrategy altrimenti). Questo creerà ancora lapidi, ma interi sstables verranno eliminati in modo efficiente una volta passato il TTL su tutti i loro contenuti.

Come posso sbarazzarmi delle lapidi esistenti?

Nella maggior parte delle circostanze, l’approccio migliore è aspettare che la lapide si compatta normalmente. Se problemi urgenti di prestazioni o utilizzo del disco richiedono un’azione più immediata, ci sono due comandi nodetool che possono essere utilizzati per forzare le compazioni, che possono aiutare a far cadere le lapidi. Questi dovrebbero essere considerati l’ultima risorsa: in un cluster sano con un modello di dati ben progettato, non è necessario eseguire compazioni manuali.

L’esecuzione dinodetool compact forza una compattazione di tutti gli sstables. Ciò richiede una grande quantità di spazio libero su disco. Gli argomenti Keyspace e table dovrebbero essere usati per limitare la compattazione alle tabelle in cui le lapidi sono un problema. Nelle tabelle in cui viene utilizzata la strategia di compattazione a più livelli, questo comando può portare alla creazione di un enorme sstable che non avrà mai peer con cui compattare; se il flag–split-output è disponibile, dovrebbe essere usato.

Il comando nodetool garbagecollect è disponibile da Cassandra 3.10 in poi. Questo comando esegue una serie di compazioni più piccole che controllano anche sstables sovrapposti. È più intensivo della CPU e richiede molto tempo rispetto anodetool compact, ma richiede meno spazio libero su disco.

Le lapidi verranno rimosse solo se gc_grace_seconds è trascorso dalla creazione delle lapidi. Lo scopo previsto di gc_grace_seconds è quello di fornire tempo per le riparazioni per ripristinare la coerenza al cluster, quindi fai attenzione quando lo modifichi: la rimozione prematura delle lapidi può comportare la resurrezione dei dati cancellati. Inoltre, l’impostazione gc_grace_seconds influisce sulla scadenza dei suggerimenti generati per hinted handoff, quindi è pericoloso ridurre gc_grace_seconds al di sotto della durata della finestra hinted handoff (per impostazione predefinita, 3 ore).

Riparazioni

Le riparazioni possono ritardare o impedire la caduta di lapidi. Quando viene eseguita una riparazione completa o incrementale, gli sstables interessati vengono contrassegnati come riparati; nelle compazioni successive, queste tabelle verranno compattate separatamente dagli sstables che non sono stati riparati. Se le lapidi sono in sstables non riparati e i dati in ombra sono in sstables riparati (o viceversa), i dati non possono essere eliminati perché gli sstables non possono essere compattati insieme.
Se si eseguono regolarmente riparazioni complete o incrementali sul cluster, questo non dovrebbe essere un problema eccessivo poiché lapidi e dati finiranno per essere riparati. Tuttavia, se si dispone di un mix di dati riparati e non riparati e non si eseguono regolarmente riparazioni, questo può diventare un problema. sstablemetadata può aiutare a controllare lo stato riparato dei vostri sstables per capire se questo sta accadendo. Se lo è, potrebbe essere consigliabile impostare tutti gli sstables come non riparati con sstablerepairedset in modo che possano essere compattati insieme.
Si prega di notare, subrange riparazioni non contrassegnare i dati come riparato.