Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Simulazione di TTL a livello di cella
In Bigtable, i criteri di garbage collection vengono impostati a livello di famiglia di colonne e non puoi specificare un criterio di garbage collection a livello di cella. Tuttavia, puoi simulare un criterio TTL a livello di cella modificando le impostazioni di raccolta dei rifiuti. Questa pagina illustra alcuni approcci diversi che puoi utilizzare.
In questo approccio, imposta la regola di raccolta dei rifiuti in modo che i dati scadano dopo un
secondo. Ogni volta che scrivi dati, imposta il timestamp della cella sull'ora in cui vuoi che il valore scada. Durante la compattazione, Bigtable elimina tutte le celle con un timestamp che risale a almeno un secondo prima. Ad esempio, se impostate il timestamp di una cella su 30 aprile alle 09:00:00, la cella viene eliminata qualche volta dopo le 09:00:01 del 30 aprile. Questo approccio consente di impostare valori di scadenza diversi per celle diverse nella stessa famiglia di colonne.
Vantaggi della scadenza di un secondo
Il timestamp ha un significato reale: l'ora di scadenza.
Svantaggi della scadenza di un secondo
Ogni applicazione che scrive dati in questa famiglia di colonne Bigtable deve essere configurata per seguire questa regola. Se dimentichi e utilizzi un
timestamp del server predefinito durante una scrittura, i dati scadono immediatamente
e vengono eliminati durante la successiva compattazione.
Poiché i timestamp non sono "reali", non puoi utilizzarli per altri scenari di utilizzo, ad esempio per determinare quando è stato scritto un valore. Come soluzione alternativa, puoi scrivere il timestamp reale in una colonna separata, ma questo aumenterà la quantità di dati archiviati.
Non puoi implementare questa strategia in una famiglia di colonne che contiene già dati con timestamp reali. Se i dati esistenti hanno timestamp reali o se scrivi accidentalmente nuovi dati con timestamp reali, questi dati vengono eliminati durante la successiva compattazione.
Non puoi specificare che più celle per una determinata riga e colonna debbano scadere contemporaneamente. I nuovi dati sovrascriveranno i dati precedenti con lo stesso timestamp.
Poiché la raccolta dei rifiuti può richiedere fino a una settimana, devi sempre utilizzare i filtri quando leggi i dati.
Scadenza predefinita
Supponiamo che tu voglia che la maggior parte dei dati abbia un TTL predefinito, ma che tu voglia impostare valori di scadenza diversi per cella per alcuni dati.
Ad esempio, potresti memorizzare gli eventi di clic per dieci clienti in una tabella. La maggior parte
degli eventi di clic dovrebbe scadere dopo 2 giorni, ma un cliente
ha eventi di clic che dovrebbero scadere dopo un'ora e un altro cliente
ha eventi di clic che dovrebbero scadere dopo 3 giorni.
In questo approccio, crea la famiglia di colonne con un limite di età per la raccolta del garbage impostato sul TTL predefinito. Per i dati che vuoi che scadano prima del valore predefinito, imposta il timestamp su un valore precedente all'ora in cui i dati vengono effettivamente scritti. Per i dati di cui vuoi che la scadenza sia successiva, imposta il timestamp in modo che sia successivo all'ora in cui i dati vengono effettivamente scritti.
Vantaggi della scadenza predefinita
Per le scritture che non hanno un TTL personalizzato è impostato un TTL predefinito.
Questo approccio può essere applicato in sicurezza a una tabella preesistente.
Svantaggi della scadenza predefinita
Il timestamp non è semanticamente significativo perché il timestamp di una cella potrebbe essere reale o artificiale. Ciò significa che non puoi utilizzare i timestamp delle celle per altri casi d'uso, ad esempio per determinare quando è stato scritto un valore.
Come soluzione alternativa, puoi scrivere il timestamp reale in una colonna separata, ma questo aumenterà la quantità di dati archiviati.
Puoi scrivere inavvertitamente un timestamp personalizzato in conflitto con un timestamp reale in una determinata colonna.
Poiché la raccolta dei rifiuti è asincrona, devi comunque utilizzare sempre i filtri quando leggi i dati quando utilizzi questa strategia.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[[["\u003cp\u003eThis page details methods to simulate cell-level time-to-live (TTL) policies in Bigtable, which natively only supports garbage collection at the column family level.\u003c/p\u003e\n"],["\u003cp\u003eThe "one-second expiration" approach involves setting a column family's garbage collection rule to expire data after one second, with the cell's timestamp set to the desired expiration time.\u003c/p\u003e\n"],["\u003cp\u003eThe "default expiration" strategy involves setting a default TTL at the column family level, while allowing for per-cell adjustments by manipulating the cell's timestamp.\u003c/p\u003e\n"],["\u003cp\u003eBoth expiration approaches use timestamps that may not be semantically meaningful for data creation time and require filters when reading data due to asynchronous garbage collection.\u003c/p\u003e\n"],["\u003cp\u003eBoth approaches have some advantages, such as how default expiration can be safely applied to pre-existing table, but also disadvantages such as the data write process needing to be configured correctly in the one-second approach.\u003c/p\u003e\n"]]],[],null,["Simulate cell-level TTL\n\nIn Bigtable, garbage collection policies are set at the\ncolumn family level, and you cannot specify a cell-level garbage collection\npolicy. However, you can simulate a time to live (TTL) policy at the cell level\nby changing your garbage collection settings. This page explains a few different\napproaches that you can use.\n\nBefore you read this page, you should read the [garbage collection overview](/bigtable/docs/garbage-collection). To learn how to send write requests, which\ninclude timestamps, see [Bigtable writes](/bigtable/docs/writes).\n\nOne-second expiration\n\nIn this approach, set your garbage collection rule to let data expire after one\nsecond. Whenever you write data, set the cell's timestamp to the time you want\nthe value to expire. During compaction, Bigtable deletes any cells\nthat have a timestamp that is at least one second in the past. For example, if\nyou set a cell's timestamp to April 30 at 9:00:00 AM, the cell is deleted\nsometime after April 30 at 9:00:01 AM. This approach enables you to set\ndifferent expiration values for different cells in the same column family.\n\nAdvantages of one-second expiration\n\n- The timestamp has a real meaning: the expiration time.\n\nDisadvantages of one-second expiration\n\n- Every application that writes data to this Bigtable column\n family needs to be configured to follow this rule. If you forget and use a\n default server timestamp on a write, that data expires right away\n and is deleted during the next compaction.\n\n- Because your timestamps aren't \"real\" you cannot use timestamps for any other\n use case, such as determining when a value was written. As a workaround, you can\n write the real timestamp to a separate column, but this will increase the amount\n of data you store.\n\n- **You cannot implement this strategy on a column family that already has data\n with real timestamps.** If existing data has real timestamps, or if you\n accidentally write new data with real timestamps, that data is deleted\n during the next compaction.\n\n- You cannot specify that multiple cells for a given row and column should\n expire at the same time as each other. New data will overwrite old data with the\n same timestamp.\n\n- Because garbage collection can take up to a week, you always need to use\n filters when you read the data.\n\nDefault expiration\n\nLet's say you want most of your data to have a default TTL, but you want to set\ndifferent per-cell expiration values for some of your data.\n\nFor example, you might store click events for ten customers in one table. Most\nof the click events should expire after 2 days, but you have one customer whose\nclick events should expire after an hour, and you have another customer whose\nclick events should expire after 3 days.\n\nIn this approach, create your column family with an age limit for garbage\ncollection set to the default TTL. For data you want to expire sooner than the\ndefault, set the timestamp to be earlier than the time the data is actually\nwritten. For data you want to expire later, set the timestamp to be later than\nthe time the data is actually written.\n\nAdvantages of default expiration\n\n- A default TTL is in place for writes that do not have a custom TTL.\n\n- This approach can safely be applied to a pre-existing table.\n\nDisadvantages of default expiration\n\n- The timestamp is not semantically meaningful because a cell's timestamp\n might be real or artificial. This means you cannot use the cells'\n timestamps for any other use case, such as determining when a value was written.\n As a workaround, you can write the real timestamp to a separate column, but\n this will increase the amount of data you store.\n\n- You can inadvertently write a custom timestamp that clashes with a real\n timestamp in a given column.\n\n- Because garbage collection is asynchronous, you still need to always use\n filters when you read the data when you use this strategy.\n\nWhat's next\n\n- Read about garbage collection with [timestamps that are sequential numbers](/bigtable/docs/gc-sequence-numbers).\n- Learn a strategy to [always read the most recent value of a column](/bigtable/docs/keep-only-latest-value).\n- Review code samples showing how to [configure garbage collection](/bigtable/docs/configuring-garbage-collection).\n- Learn more about [storage pricing](/bigtable/pricing#storage)."]]
