Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Simuler la valeur TTL au niveau de la cellule
Dans Bigtable, les stratégies de récupération de mémoire sont définies au niveau de la famille de colonnes, et vous ne pouvez pas spécifier de stratégie de récupération de mémoire au niveau de la cellule. Toutefois, vous pouvez simuler une stratégie de valeur TTL (Time To Live) au niveau de la cellule en modifiant vos paramètres de récupération de mémoire. Cette page décrit les différentes approches que vous pouvez utiliser.
Avant de lire cette page, consultez la page de présentation intitulée Récupération de mémoire. Pour savoir comment envoyer des requêtes d'écriture, qui incluent des horodatages, consultez la section Écritures Bigtable.
Expiration au bout d'une seconde
Cette approche vous permet de définir une règle de récupération de mémoire de façon à ce que les données expirent au bout d'une seconde. Lors de l'écriture de données, définissez l'horodatage de la cellule concernée sur l'heure à laquelle vous souhaitez que la valeur expire. Lors du compactage, Bigtable supprime toutes les cellules dont l'horodatage date d'au moins une seconde. Par exemple, si vous définissez l'horodatage d'une cellule sur le 30 avril à 9:00:00, la cellule est supprimée après 9:00:01 le 30 avril. Cette approche vous permet de définir différentes valeurs d'expiration pour différentes cellules de la même famille de colonnes.
Avantages de l'expiration au bout d'une seconde
L'horodatage présente une signification réelle : la date d'expiration.
Inconvénients de l'expiration au bout d'une seconde
Chaque application qui écrit des données dans cette famille de colonnes Bigtable doit être configurée afin de suivre cette règle. Si vous oubliez de le faire et que vous utilisez un horodatage de serveur par défaut lors d'une écriture, ces données expirent immédiatement et sont supprimées lors du compactage suivant.
Étant donné que vos horodatages ne sont pas "réels", vous ne pouvez utiliser les horodatages pour aucun autre cas d'utilisation, tel que la détermination du moment où une valeur a été écrite. Pour contourner ce problème, vous pouvez écrire l'horodatage réel dans une colonne distincte, mais cela augmente la quantité de données stockées.
Vous ne pouvez pas mettre en œuvre cette stratégie dans le cas d'une famille de colonnes contenant déjà des données qui comprennent des horodatages réels. Si les données existantes présentent des horodatages réels ou si vous écrivez accidentellement de nouvelles données présentant des horodatages réels, ces données sont supprimées lors du compactage suivant.
Vous ne pouvez pas spécifier le fait que plusieurs cellules pour une ligne et une colonne données doivent expirer en même temps. Toutes nouvelles données présentant le même horodatage que d'anciennes données écraseront ces dernières.
Étant donné que la récupération de mémoire peut prendre jusqu'à une semaine, vous devez toujours utiliser des filtres lors de la lecture des données.
Expiration par défaut
Supposons que vous souhaitiez que la plupart de vos données aient une valeur TTL par défaut, mais que vous souhaitiez définir des valeurs d'expiration par cellule différentes pour certaines de vos données.
Par exemple, vous pouvez stocker les événements de clic de dix clients dans une seule table. La plupart des événements de clic doivent expirer au bout de deux jours, mais vous avez un client dont les événements de clic doivent expirer au bout d'une heure, et un autre client dont les événements de clic doivent expirer au bout de trois jours.
Dans cette approche, créez une famille de colonnes présentant une limite d'âge pour la récupération de mémoire définie sur la valeur TTL par défaut. Pour les données qui doivent expirer avant la valeur par défaut, définissez l'horodatage sur une valeur antérieure à l'heure à laquelle les données sont réellement écrites. Pour les données qui doivent expirer ultérieurement, définissez l'horodatage sur une valeur ultérieure à l'heure à laquelle les données sont réellement écrites.
Avantages de l'expiration par défaut
Une valeur TTL par défaut est en place pour les écritures qui ne présentent pas de valeur TTL personnalisée.
Cette approche peut être appliquée à une table existante en toute sécurité.
Inconvénients de l'expiration par défaut
Le terme horodatage ne présente pas de signification sémantique, car l'horodatage d'une cellule peut être réel ou artificiel. Cela implique que vous ne pouvez utiliser les horodatages des cellules pour aucun autre cas d'utilisation, tel que la détermination du moment où une valeur a été écrite.
Pour contourner ce problème, vous pouvez écrire l'horodatage réel dans une colonne distincte, mais cela augmente la quantité de données stockées.
Par inadvertance, vous pouvez écrire un horodatage personnalisé qui entre en conflit avec un horodatage réel dans une colonne donnée.
La récupération de mémoire étant asynchrone, vous devez toujours utiliser des filtres lors de la lecture des données lorsque vous utilisez cette stratégie.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]
