Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Informazioni su garbage collection

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

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

Panoramica della garbage collection

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

La garbage collection è un processo in background asincrono asincrono. Può essere necessaria fino a una settimana per l'eliminazione effettiva dei dati idonei per la garbage collection. La garbage collection si basa su una pianificazione fissa che non varia in base alla quantità di dati da eliminare. Finché i dati non vengono eliminati, vengono visualizzati nei risultati di lettura. Puoi filtrare le letture per escludere questi dati.

Di seguito sono riportati i vantaggi delle norme relative alla raccolta dei rifiuti:

  • Riduci a icona le dimensioni delle righe: vuoi sempre impedire la crescita infinita delle righe. Le righe di grandi dimensioni influiscono negativamente sul rendimento. Idealmente, non dovresti mai lasciare che una riga superi i 100 MB e il limite sia di 256 MB. Se non hai bisogno di conservare i vecchi dati o le vecchie versioni dei tuoi dati attuali, utilizzare la garbage collection può aiutarti a ridurre al minimo le dimensioni di ogni riga.
  • Costi ridotti: la garbage collection garantisce che non paghi per archiviare dati che non sono più richiesti o utilizzati. Ti viene addebitato lo spazio di archiviazione dei dati scaduti o obsoleti fino a quando non si verifica la compattazione e i dati idonei per la garbage collection vengono eliminati. In genere questa procedura richiede alcuni giorni, ma potrebbe essere necessaria anche una settimana.

Puoi impostare i criteri di garbage collection in modo programmatico o con lo strumento cbt. I criteri di garbage collection vengono 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 di quell'intersezione. Ogni cella ha un timestamp. Un timestamp è il numero di microsecondi trascorsi dall'epoca Unix, 1970-01-01 00:00:00 UTC. Puoi utilizzare i timestamp predefiniti o impostarli quando invii richieste di scrittura.

La proprietà timestamp di una cella può essere un timestamp "reale", che riflette l'ora effettiva in cui è stato scritto il valore della cella, oppure un timestamp "artificiale". I timestamp artificiali includono numeri sequenziali, zeri o valori in formato timestamp che non corrispondono all'ora effettiva in cui la cella è stata scritta. Prima di utilizzare i timestamp artificiali, esamina i casi d'uso relativi ai timestamp artificiali, compresi i rischi del loro utilizzo:

Tipi di raccolta dei rifiuti

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 basata sul timestamp di ciascuna cella. Ad esempio, potresti non voler conservare le celle con timestamp più di 30 giorni prima della data e dell'ora correnti. Con questo tipo di regola per la garbage collection, imposti la durata (TTL) dei dati. Bigtable esamina ogni famiglia di colonne durante la garbage collection e elimina eventuali celle scadute.

Numero di versioni

Puoi impostare una regola di garbage collection che specifica 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 le due colonne e impostare il numero massimo di valori su 1 per quella famiglia di colonne.

In un altro caso, potresti voler mantenere le ultime cinque versioni dell'hash della password di un utente per assicurarti che non riutilizza la password, quindi imposta 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 nella colonna della password è stata scritta una sesta cella, la cella meno recente viene eliminata per mantenere il numero di celle a cinque.

Combinazioni di regole relative alla scadenza e al numero di versione

Puoi utilizzare una combinazione di regole di scadenza e numero di versione per la garbage collection. I tipi di combinazioni sono intersezione, unione e nidificazione. Per esempi di configurazione, consulta la sezione Raccolta garage in base a più criteri.

Intersezione

Un criterio di garbage collection di intersezione contrassegna i dati per l'eliminazione quando soddisfano tutti i criteri in un determinato insieme di regole. Ad esempio, puoi eliminare i profili più vecchi di 30 giorni, ma conservarne 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 in una regola per il numero di versioni.

Union

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

Nidificati

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

Impostazioni predefinite per la garbage collection

Non esiste un TTL predefinito per la famiglia di colonne. Il numero di celle conservate per una colonna dipende dalla modalità di creazione della famiglia di colonne in cui si trova la colonna, come illustrato 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 nella famiglia di colonne, a meno che non modifichi la regola. Questa impostazione predefinita è coerente con HBase.

Tutte le altre librerie o tutti gli strumenti client

Se crei la famiglia di colonne con qualsiasi altra libreria o strumento client, Bigtable conserva un numero infinito di celle in ogni colonna nella famiglia di colonne. Sono incluse le famiglie di colonne create con gcloud e cbt tool. Se vuoi limitare il numero di versioni, devi modificare il criterio 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 di conseguenza i dati scaduti e obsoleti. In genere, può essere necessario attendere fino a una settimana dal momento in cui i dati corrispondono ai criteri specificati nelle regole per l'eliminazione effettiva dei dati. Non puoi modificare la tempistica della garbage collection.

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

Ad esempio, supponiamo che la regola della garbage collection di una famiglia di colonne sia impostata per conservare solo le cinque versioni più recenti di un profilo e che siano già archiviate cinque versioni. Una volta scritta una nuova versione del profilo, potrebbe essere necessaria fino a una settimana per l'eliminazione della cella meno recente. Pertanto, per evitare di leggere il sesto valore, dovresti sempre escludere tutto, tranne le cinque versioni più recenti.

Ti viene addebitato lo spazio di archiviazione dei dati scaduti fino alla compattazione e all'eliminazione dei dati.

La garbage collection è retroattiva: quando viene impostata una nuova norma per la garbage collection, nei prossimi giorni viene applicata a tutti i dati nella tabella. Se la nuova norma è più restrittiva di quella precedente, i dati precedenti vengono eliminati man mano che vengono eseguiti i lavori in background, inclusi quelli scritti prima della modifica del criterio.

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 Google Cloud. Una tabella che non diventa mai più piccola potrebbe riflettere un criterio di garbage collection che non funziona come previsto, ma ricorda che la garbage collection viene eseguita in ritardo.

Replica e raccolta dei rifiuti

La replica può influire in alcuni modi sulla raccolta dei rifiuti.

garbage collection e utilizzo della CPU basati su versione

In un'istanza che utilizza la replica, le eliminazioni dalla garbage collection basata su 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 comportano l'eliminazione delle celle meno recenti, potresti notare un aumento dell'utilizzo della CPU quando Bigtable elimina le celle inattive e replica queste 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.

Modifiche ai criteri di garbage collection per le tabelle replicate

Se una tabella si trova in un'istanza a cluster singolo, Bigtable ti consente di modificare o eliminare un criterio per una famiglia di colonne in qualsiasi momento. Nei casi che utilizzano la replica, vengono applicate alcune limitazioni. Queste limitazioni proteggono i tuoi dati.

Modificare i criteri della garbage collection basati su versione

Puoi modificare il numero massimo di versioni di una famiglia di colonne in una tabella replicata. Tuttavia, se riduci il numero di versioni di una famiglia di colonne, può essere necessaria fino a una settimana affinché tutti i cluster replicati riflettano il nuovo numero inferiore. Per questo motivo, devi sempre utilizzare i filtri durante la lettura dei dati.

Limitazioni relative alla modifica dei criteri di raccolta dei rifiuti in base all'età

Bigtable non ti consente di aumentare il TTL di una famiglia di colonne in una tabella replicata.

Per capire perché, considera un caso ipotetico in cui è presente una tabella in un'istanza a due cluster e modifichi il TTL di una famiglia di colonne da 30 a 50 giorni:

  1. Una richiesta di scrittura per la chiave di riga ip#685 viene inviata 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, la garbage collection si verifica nel cluster A e il valore nella colonna click-through viene riconosciuto come scaduto ed eliminato.
  3. Puoi modificare il criterio di garbage collection per la famiglia di colonne profile, aumentando il TTL da 30 giorni a 50 giorni.
  4. Il giorno dopo, la garbage collection viene eseguita sul cluster B. Poiché la durata (TTL) è di 50 giorni, il valore 2023-01-02 viene conservato.
  5. I cluster ora non sono sincronizzati e rimangono tali per quasi 20 giorni finché il valore che esiste nel cluster B ma non nel cluster A viene finalmente eliminato.

Per lo stesso motivo, Bigtable non consente di eliminare un criterio di garbage collection basato sull'età per una famiglia di colonne in una tabella replicata.

Passaggi successivi