Panoramica della garbage collection

Questa pagina descrive il funzionamento della garbage collection in Bigtable e tratta i seguenti argomenti:

  • Tipi di garbage collection
  • Impostazioni di garbage collection predefinite
  • Quando i dati vengono eliminati
  • Modifiche ai criteri di garbage collection per le tabelle replicate

Panoramica della garbage collection

La raccolta di rifiuti è il processo automatico continuo di rimozione dei dati scaduti e obsoleti dalle tabelle Bigtable. Un criterio di garbage collection è un insieme di regole che crei in questo stato quando i dati in una famiglia di colonne specifica non sono più necessari.

La garbage collection è un processo in background asincrono integrato. Potrebbe essere necessaria fino a una settimana prima che i dati idonei per la garbage collection vengano effettivamente eliminati. La garbage collection avviene in base a una pianificazione fissa che non varia in base alla quantità di dati da eliminare. Finché non vengono eliminati, i dati vengono visualizzati nei risultati di lettura. Puoi filtrare le letture per escludere questi dati.

I vantaggi delle norme sulla garbage collection includono i seguenti:

  • Riduci al minimo la dimensione delle righe: vuoi sempre impedire che le righe aumentino in modo indefinito. Le righe di grandi dimensioni influiscono negativamente sulle prestazioni. Idealmente, non dovresti mai lasciare che una riga superi i 100 MB di dimensione e il limite è di 256 MB. Se non hai bisogno di conservare vecchi dati o versioni precedenti dei dati attuali, la garbage collection può aiutarti a ridurre al minimo la dimensione di ogni riga.
  • Mantieni bassi i costi: la garbage collection ti assicura che tu non paghi per archiviare dati che non sono più richiesti o utilizzati. Ti viene addebitato il costo per l'archiviazione di dati scaduti o obsoleti fino a quando non viene effettuata la compattazione e i dati idonei per la garbage collection non vengono eliminati. Di solito, questa procedura richiede alcuni giorni, ma potrebbe essere necessaria fino a una settimana.

Puoi impostare i criteri di garbage collection in modo programmatico o con l' interfaccia a riga di comando cbt . I criteri di garbage collection sono impostati a livello di famiglia di colonne.

Ogni famiglia di colonne in una tabella ha il proprio criterio di garbage collection. Il processo di garbage collection cerca il criterio di garbage collection attuale per ogni famiglia di colonne, quindi elimina i dati in base alle regole del criterio.

Timestamp

In Bigtable, l'intersezione di una riga e di una colonna può avere più celle, che contengono versioni con timestamp del valore per quell'intersezione. Ogni cella ha un timestamp. Un timestamp è il numero di microsecondi dall'epoca di Unix, 1970-01-01 00:00:00 UTC. Puoi utilizzare timestamp predefiniti o impostarli quando invii richieste di scrittura.

Un timestamp inviato a Bigtable deve essere un valore in microsecondi con una precisione massima di un millisecondo. Un timestamp con precisione in microsecondi, ad esempio 3023483279876543, viene rifiutato. In questo esempio, il valore accettabile per il timestamp è 3023483279876000.

La proprietà timestamp di una cella può essere un timestamp "reale", che riflette l'ora effettiva di scrittura del valore della cella, oppure può essere un timestamp "artificiale". I timestamp artificiali includono numeri sequenziali, zeri o valori formattati per timestamp che non corrispondono al momento effettivo in cui la cella è stata scritta. Prima di utilizzare i timestamp artificiali, esamina i casi d'uso dei timestamp artificiali, inclusi i rischi del loro utilizzo:

Assicurati di impostare un timestamp predefinito quando invii richieste di scrittura, a meno che tu non abbia bisogno di supportare un caso d'uso con timestamp artificiali.

Tipi di garbage collection

Questa sezione descrive i tipi di garbage collection disponibili in Bigtable. Gli esempi di codice per ogni tipo di garbage collection sono disponibili in Configurazione della garbage collection.

Valori in scadenza (in base all'età)

Puoi impostare una regola di garbage collection in base al timestamp di ogni cella. Ad esempio, potresti non voler conservare le celle con timestamp che risalgono a più di 30 giorni prima della data e dell'ora correnti. Con questo tipo di regola di garbage collection, imposti la durata (TTL) dei dati. Bigtable esamina ogni famiglia di colonne durante la garbage collection ed elimina tutte le celle scadute.

Numero di versioni

Puoi impostare una regola di garbage collection che indichi in modo esplicito il numero massimo di celle da conservare per tutte le colonne di una famiglia di colonne.

Ad esempio, se vuoi conservare solo il nome utente e l'indirizzo email più recenti di un cliente, puoi creare una famiglia di colonne contenente queste due colonne e impostare il numero massimo di valori su 1 per quella famiglia di colonne.

In un altro caso, potresti voler conservare le ultime cinque versioni dell'hash della password di un utente per assicurarti che non riutilizzano la password, quindi imposta il numero massimo di versioni per la famiglia di colonne che contiene la colonna della password su 5. Quando Bigtable esamina la famiglia di colonne durante la garbage collection, se è stata scritta una sesta cella nella colonna della password, la cella meno recente viene eliminata per mantenere il numero di celle a cinque.

Combinazioni di regole relative a scadenza e numero di versione

Per la garbage collection puoi utilizzare una combinazione di regole di scadenza e numero di versione. I tipi di combinazioni sono intersezione, unione e nidificata. Per esempi di configurazione, consulta Raccolta dei rifiuti basata su più criteri.

Intersezione

Un criterio di garbage collection di intersezione contrassegna i dati per l'eliminazione quando soddisfa tutti i criteri di un determinato insieme di regole. Ad esempio, puoi eliminare profili più vecchi di 30 giorni ma conservarne sempre almeno uno per ogni utente. In questo caso, il criterio di intersezione per la famiglia di colonne contenente la colonna del profilo consiste in una regola per un valore in scadenza e una regola per il numero di versioni.

Union

Un criterio di garbage collection unione contrassegna i dati per l'eliminazione quando soddisfano qualsiasi elemento in un determinato insieme di regole. Ad esempio, potresti voler conservare un massimo di due record di visualizzazioni di pagina per utente, ma solo se risalgono a meno di 30 giorni prima. In questo caso, il criterio di unione è impostato per un valore in scadenza o per un numero di versioni.

Nidificati

Un criterio di garbage collection nidificato ha una combinazione di regole di unione e intersezione.

Impostazioni predefinite per la garbage collection

Non esiste un TTL predefinito per una famiglia di colonne. Il numero di celle conservate per una colonna dipende da come viene creata la famiglia di colonne in cui si trova la colonna, come spiegato nelle sezioni seguenti.

Criterio HBase

Se crei la famiglia di colonne con il client HBase per Java, la shell HBase o un altro strumento che utilizza il client HBase per Java, Bigtable conserva solo la cella più recente in ogni colonna della famiglia di colonne, a meno che non modifichi la regola. Questa impostazione predefinita è coerente con HBase.

Tutte le altre librerie client o strumenti

Se crei la famiglia di colonne con qualsiasi altra libreria client o strumento, Bigtable conserva un numero infinito di celle in ogni colonna della famiglia di colonne. Sono incluse le famiglie di colonne create con gcloud e l'interfaccia a riga di comando cbt. Devi modificare il criterio di garbage collection per la famiglia di colonne se vuoi limitare il numero di versioni.

Quando i dati vengono eliminati

La garbage collection è un processo continuo in cui Bigtable controlla le regole per ogni famiglia di colonne ed elimina di conseguenza i dati scaduti e obsoleti. In generale, l'eliminazione effettiva dei dati potrebbe richiedere fino a una settimana dal momento in cui corrispondono ai criteri delle regole. Non puoi modificare la tempistica della garbage collection.

Poiché l'eliminazione dei dati scaduti può richiedere fino a una settimana, non dovresti mai affidarti esclusivamente alle norme di garbage collection per garantire che le richieste di lettura restituiscano i dati desiderati. Applica sempre un filtro alle tue richieste di lettura che esclude gli stessi valori delle regole di garbage collection. Puoi filtrare limitando il numero di celle per colonna o specificando un intervallo di timestamp.

Ad esempio, supponiamo che la regola di garbage collection di una famiglia di colonne sia impostata per mantenere solo le cinque versioni più recenti di un profilo e che cinque versioni siano già archiviate. Dopo aver scritto una nuova versione del profilo, potrebbe essere necessaria fino a una settimana per eliminare la cella meno recente. Pertanto, per evitare di leggere il sesto valore, devi sempre escludere tutto tranne le cinque versioni più recenti.

Ti viene addebitato il costo di archiviazione dei dati scaduti fino a quando non avviene la compattazione e i dati non vengono eliminati.

La garbage collection è retroattiva: quando viene configurato un nuovo criterio di garbage collection, nei giorni successivi viene applicato a tutti i dati della tabella. Se il nuovo criterio è più restrittivo rispetto al criterio precedente, i dati precedenti vengono eliminati durante le operazioni in background, compresi quelli scritti prima della modifica del criterio.

Se vuoi assicurarti che i dati contrassegnati per la garbage collection vengano eliminati, puoi eseguire una query nella tabella e confrontare i dati con i risultati previsti. Puoi anche monitorare le dimensioni della tabella nella console Google Cloud. Una tabella che non diventa mai più ridotta potrebbe rispecchiare un criterio di garbage collection che non funziona come previsto, ma ricorda che la garbage collection viene eseguita con un ritardo.

Replica e garbage collection

La replica può influire sulla garbage collection in diversi modi.

Garbage collection basata sulla versione e utilizzo della CPU

In un'istanza che utilizza la replica, le eliminazioni dalla garbage collection basata sulla versione vengono replicate in tutti i cluster dell'istanza, nello stesso modo in cui vengono replicate le richieste dell'applicazione. Se scrivi rapidamente nuove celle che fanno sì che le celle meno recenti siano contrassegnate per l'eliminazione, potresti notare un aumento dell'utilizzo della CPU quando Bigtable elimina le celle obsolete e replica queste operazioni in altri cluster nell'istanza. Preparati a questo aumento dell'utilizzo della CPU se aggiungi un cluster a un'istanza contenente tabelle che utilizzano la garbage collection basata sulle versioni.

La garbage collection basata sull'età, d'altra parte, non aumenta l'utilizzo della CPU nelle istanze replicate.

Modifica dei criteri di garbage collection basati sulle versioni

Puoi modificare il numero massimo di versioni di una famiglia di colonne in una tabella replicata. Tuttavia, se riduci il numero di versioni per una famiglia di colonne, potrebbe essere necessaria fino a una settimana prima che tutti i cluster replicati riflettano il nuovo numero inferiore. Pertanto, dovresti sempre utilizzare i filtri durante la lettura dei dati.

Modifica dei criteri di garbage collection in base all'età

Puoi aumentare o diminuire il tempo di conservazione specificato nei criteri di garbage collection, indipendentemente dal fatto che l'istanza utilizzi la replica. Puoi anche eliminare un criterio di garbage collection basato sull'età.

Ridurre il tempo di conservazione

Se diminuisci il tempo di conservazione in un criterio basato sull'età, potrebbe essere necessaria fino a una settimana prima che tutti i cluster vengano sincronizzati e utilizzato il nuovo criterio.

Aumento del tempo di conservazione

In una tabella replicata puoi aumentare il tempo di conservazione di un criterio di garbage collection di un massimo di 90 giorni.

Se prolunghi il periodo di conservazione per una famiglia di colonne, tieni presente che i tuoi cluster potrebbero non essere sincronizzati per più di una settimana. Per capire il motivo, considera un caso ipotetico in cui hai una tabella in un'istanza a due cluster e modifichi il periodo di conservazione di una famiglia di colonne da 30 giorni a 50 giorni:

  1. Una richiesta di scrittura per la chiave di riga ip#685 viene inviata al cluster A con un valore pari a 2023-01-02 per la colonna click-through nella famiglia di colonne profile. I dati vengono replicati nel cluster B.
  2. Trentuno giorni dopo, viene effettuata la garbage collection sul cluster A e il valore nella colonna click-through viene riconosciuto come scaduto ed eliminato.
  3. Modifica il criterio di garbage collection per la famiglia di colonne profile, aumentando il TTL da 30 a 50 giorni.
  4. Un giorno dopo, la garbage collection viene eseguita sul cluster B. Poiché il TTL è di 50 giorni, viene conservato il valore 2023-01-02.
  5. I cluster ora non sono sincronizzati e lo rimangono per quasi 20 giorni fino a quando il valore esistente nel cluster B, ma non nel cluster A, non viene finalmente eliminato.

Passaggi successivi