Panoramica della garbage collection

La garbage collection in Bigtable ti consente di rimuovere automaticamente i dati scaduti e obsoleti dalle tabelle. La configurazione di queste policy ti aiuta a gestire i costi di archiviazione e a mantenere le prestazioni di lettura.

La garbage collection è il processo automatico e continuo di rimozione dei dati scaduti e obsoleti dalle tabelle Bigtable. Una policy di garbage collection è un insieme di regole che crei per indicare quando i dati di una famiglia di colonne specifica non sono più necessari.

La garbage collection è un processo in background asincrono integrato che avviene durante la compattazione. La garbage collection avviene in base a una pianificazione fissa che non varia in base alla quantità di dati da eliminare. Fino a quando i dati non vengono eliminati, vengono visualizzati nei risultati di lettura. Puoi filtrare le letture per escludere questi dati.

Per saperne di più, consulta la sezione Quando vengono eliminati i dati di questo documento.

I vantaggi delle policy di garbage collection includono:

  • Riduci al minimo le dimensioni delle righe: evita sempre che le righe crescano indefinitamente. Le righe di grandi dimensioni influiscono negativamente sulle prestazioni. Idealmente, non dovresti mai consentire a una riga di superare i 100 MB di dimensione e il limite è di 256 MB. Se non hai bisogno di conservare i dati storici o le versioni precedenti dei dati attuali, l'utilizzo della garbage collection può aiutarti a ridurre al minimo le dimensioni di ogni riga.
  • Riduzione dei costi: la garbage collection garantisce che non paghi per l'archiviazione di dati che non sono più necessari o utilizzati. Ti viene addebitato il costo dell'archiviazione dei dati scaduti o obsoleti fino a quando non avviene la compattazione e i dati idonei per la garbage collection non vengono eliminati. Questa procedura in genere richiede alcuni giorni, ma potrebbe richiedere fino a una settimana.

Puoi impostare le policy di garbage collection in modo programmatico o con l' interfaccia a riga di comando di cbt . Le policy di garbage collection sono impostate a livello di famiglia di colonne.

Ogni famiglia di colonne di una tabella ha una propria policy di garbage collection. Il processo di garbage collection cerca la policy di garbage collection corrente per ogni famiglia di colonne, quindi elimina i dati in base alle regole della policy.

Timestamp

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

Un timestamp che invii 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 in cui viene scritto il valore della cella, o un timestamp "artificiale". I timestamp artificiali includono numeri sequenziali, zeri o valori formattati come timestamp che non corrispondono all'ora effettiva in cui è stata scritta la cella. 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 debba 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 risalenti 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 le celle scadute.

Numero di versioni

Puoi impostare una regola di garbage collection che indichi esplicitamente 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 riutilizzi la password, quindi imposteresti il numero massimo di versioni per la famiglia di colonne contenente la colonna della password su 5. Quando Bigtable esamina la famiglia di colonne durante la garbage collection, se una sesta cella è stata scritta nella colonna della password, la cella meno recente viene eliminata per mantenere il numero di celle a cinque.

Combinazioni di regole di 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 Garbage collection basata su più criteri.

Incrocio

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

Union

Una policy di garbage collection union contrassegna i dati per l'eliminazione quando soddisfano qualsiasi elemento di un determinato insieme di regole. Ad esempio, potresti voler assicurarti di conservare un massimo di due record di visualizzazioni di pagina per utente, ma solo se hanno meno di 30 giorni. In questo caso, la policy di unione è impostata per un valore in scadenza o un numero di versioni.

Nidificati

Una policy di garbage collection nidificata 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 crei la famiglia di colonne in cui si trova la colonna, come spiegato nelle sezioni seguenti.

Policy 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 un'altra libreria client o un altro 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. Se vuoi limitare il numero di versioni, devi modificare la policy di garbage collection per la famiglia di colonne.

Quando i dati vengono eliminati

La garbage collection è un processo continuo in cui Bigtable controlla le regole per ogni famiglia di colonne ed elimina i dati scaduti e obsoleti di conseguenza. In genere, può essere necessaria fino a una settimana dal momento in cui i dati corrispondono ai criteri delle regole affinché vengano effettivamente eliminati. Non puoi modificare la tempistica della garbage collection.

Poiché l'eliminazione dei dati scaduti può richiedere fino a una settimana, non devi mai fare affidamento esclusivamente sulle policy di garbage collection per assicurarti che le richieste di lettura restituiscano i dati selezionati. Applica sempre alle richieste di lettura un filtro che escluda 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 conservare solo le cinque versioni più recenti di un profilo e che siano già memorizzate cinque versioni. Dopo la scrittura di una nuova versione del profilo, potrebbe essere necessaria fino a una settimana prima che la cella meno recente venga eliminata. Pertanto, per evitare di leggere il sesto valore, devi sempre filtrare tutto tranne le cinque versioni più recenti.

Ti viene addebitato il costo per l'archiviazione dei dati scaduti fino alla compattazione e all'eliminazione dei dati. Anche se Bigtable archivia i dati scaduti e le eliminazioni in formato compresso, l'utilizzo dello spazio di archiviazione e la fattura non vengono ridotti finché la compattazione non riscrive definitivamente i file di archiviazione ed elimina i dati obsoleti.

La garbage collection è retroattiva: quando viene impostata una nuova policy di garbage collection, nei giorni successivi viene applicata a tutti i dati della tabella. Se la nuova policy è più restrittiva della precedente, i dati precedenti vengono eliminati durante l'esecuzione del lavoro in background, inclusi i dati scritti prima della modifica della policy.

Se vuoi assicurarti che i dati contrassegnati per la garbage collection vengano eliminati, puoi eseguire una query sulla tabella e confrontare i dati con i risultati previsti. Puoi anche monitorare le dimensioni della tabella nella console Cloud de Confiance . Una tabella che non si riduce mai potrebbe riflettere una policy 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 causano il contrassegno per l'eliminazione di quelle precedenti, potresti notare un aumento dell'utilizzo della CPU quando Bigtable elimina le celle obsolete e replica le eliminazioni in altri cluster dell'istanza. Preparati a questo aumento dell'utilizzo della CPU se aggiungi un cluster a un'istanza contenente tabelle che utilizzano la garbage collection basata sulla versione.

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

Modifica delle policy di garbage collection basate sulla versione

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, devi sempre utilizzare i filtri durante la lettura dei dati.

Modifica delle policy di garbage collection basate sull'età

Puoi aumentare o diminuire il tempo di conservazione specificato nelle policy di garbage collection, indipendentemente dal fatto che l'istanza utilizzi o meno la replica. Se l'istanza non utilizza la replica, puoi anche eliminare una policy di garbage collection basata sull'età.

Riduzione del tempo di conservazione

Se riduci il tempo di conservazione in una policy basata sull'età, potrebbe essere necessaria fino a una settimana per sincronizzare tutti i cluster e utilizzare la nuova policy.

Aumento del tempo di conservazione

In una tabella replicata, puoi aumentare il periodo di conservazione di una policy di garbage collection di un massimo di 90 giorni.

Se aumenti il periodo di conservazione per una famiglia di colonne, tieni presente che i 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 con due cluster e modifichi il periodo di conservazione di una famiglia di colonne da 30 a 50 giorni:

  1. Viene inviata una richiesta di scrittura per la chiave di riga ip#685 al cluster A con un valore 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 eseguita la garbage collection sul cluster A e il valore nella colonna click-through viene riconosciuto come scaduto ed eliminato.
  3. Modifichi la policy 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, il valore 2023-01-02 viene conservato.
  5. I cluster non sono più sincronizzati e rimangono tali per quasi 20 giorni, finché il valore presente nel cluster B, ma non nel cluster A, non viene eliminato.

Passaggi successivi