Présentation de la récupération de mémoire

Cette page décrit le fonctionnement de la récupération de mémoire dans Bigtable et aborde les sujets suivants:

  • Types de récupération de mémoire
  • Paramètres par défaut de la récupération de mémoire
  • Quand les données sont supprimées
  • Modifications apportées aux stratégies de récupération de mémoire pour les tables répliquées

Présentation de la récupération de mémoire

La récupération de mémoire correspond au processus automatique et continu de suppression des données expirées et obsolètes des tables Bigtable. Une stratégie de récupération de mémoire est un ensemble de règles, créées par vos soins, qui indiquent quand les données d'une famille de colonnes spécifique ne sont plus nécessaires.

La récupération de mémoire est un processus en arrière-plan, asynchrone et intégré. La suppression réelle des données concernées par la récupération de mémoire peut prendre jusqu'à une semaine. La récupération de mémoire s'effectue selon un calendrier fixe qui ne varie pas en fonction de la quantité de données à supprimer. Les données apparaissent dans les résultats de lecture jusqu'à leur suppression. que vous pouvez filtrer de manière à exclure ces données.

Les avantages des stratégies de récupération de mémoire sont les suivants :

  • Réduction de la taille des lignes : il est toujours préférable d'empêcher les lignes de s'accroître indéfiniment. Les lignes volumineuses affectent négativement les performances. Idéalement, il ne faut jamais laisser une ligne dépasser 100 Mo. La taille limite est de 256 Mo. Si vous n'avez pas besoin de conserver des données anciennes ou d'anciennes versions de vos données actuelles, la récupération de mémoire peut vous permettre de réduire la taille de chaque ligne.
  • Limitation des coûts : la récupération de mémoire vous garantit d'éviter de payer pour stocker des données qui ne sont plus requises ou utilisées. Vous êtes facturé pour le stockage des données expirées ou obsolètes jusqu'au moment du compactage et de la suppression des données concernées par la récupération de mémoire. Ce processus dure en général quelques jours, mais il est possible qu'il s'étende jusqu'à une semaine.

Vous pouvez définir des stratégies de récupération de mémoire par programmation ou à l'aide de la CLI cbt . Les règles de récupération de mémoire sont définies au niveau de la famille de colonnes.

Chaque famille de colonnes d'une table dispose de sa propre stratégie de récupération de mémoire. Le processus de récupération de mémoire recherche la stratégie de récupération de mémoire actuelle pour chaque famille de colonnes, puis supprime les données conformément aux règles de la stratégie.

Horodatages

Dans Bigtable, l'intersection d'une ligne et d'une colonne peut comprendre plusieurs cellules, qui contiennent des versions horodatées de la valeur pour cette intersection. Chaque cellule dispose d'un horodatage. Un horodatage correspond au nombre de microsecondes écoulées depuis l'époque Unix, 1970-01-01 00:00:00 UTC. Vous pouvez utiliser les horodatages par défaut ou les définir lorsque vous envoyez des requêtes d'écriture.

Le code temporel que vous envoyez à Bigtable doit être exprimé en microsecondes avec une précision maximale de l'ordre de la milliseconde. Un code temporel avec une précision de l'ordre de la microseconde, comme 3023483279876543, est refusé. Dans cet exemple, la valeur de code temporel acceptable est 3023483279876000.

La propriété d'horodatage d'une cellule peut correspondre à un horodatage "réel", reflétant l'heure à laquelle la valeur de la cellule est écrite, ou à un horodatage "artificiel". Les horodatages artificiels comprennent des nombres séquentiels, des zéros ou des valeurs au format d'horodatage qui ne représentent pas l'heure à laquelle la cellule a été écrite. Avant d'utiliser des horodatages artificiels, examinez les cas d'utilisation de ce type d'horodatages, y compris les risques liés à leur utilisation :

Assurez-vous de définir un code temporel par défaut lorsque vous envoyez des requêtes d'écriture, sauf si vous devez prendre en charge un cas d'utilisation avec des codes temporels artificiels.

Types de récupération de mémoire

Cette section décrit les types de récupération de mémoire disponibles dans Bigtable. Des exemples de code pour chaque type de récupération de mémoire sont disponibles dans la section Configurer la récupération de mémoire.

Valeurs arrivant à expiration (en fonction de l'âge)

Vous pouvez définir une règle de récupération de mémoire basée sur l'horodatage de chaque cellule. Par exemple, vous ne souhaitez peut-être pas conserver de cellule dont l'horodatage date de plus de 30 jours. Ce type de règle de récupération de mémoire consiste à définir la valeur TTL (Time To Live) des données. Bigtable examine chaque famille de colonnes lors de la récupération de mémoire et supprime les cellules qui ont expiré.

Nombre de versions

Vous pouvez définir une règle de récupération de mémoire qui indique explicitement le nombre maximal de cellules à conserver pour toutes les colonnes d'une famille de colonnes.

Par exemple, si vous ne souhaitez conserver que le nom d'utilisateur et l'adresse e-mail les plus récents d'un client, vous pouvez créer une famille de colonnes contenant ces deux colonnes, et définir le nombre maximal de valeurs sur 1 pour cette famille de colonnes.

Autre exemple, vous pouvez conserver les 5 dernières versions du hachage de mot de passe d'un utilisateur pour vous assurer qu'il ne le réutilise pas. Vous devez donc définir le nombre maximal de versions sur 5 pour la famille de colonnes contenant la colonne de mot de passe. Lorsque Bigtable examine la famille de colonnes lors de la récupération de mémoire, si une sixième cellule a été écrite dans la colonne de mot de passe, la cellule la plus ancienne est supprimée afin que le nombre de versions ne dépasse pas cinq.

Combiner des règles d'expiration et de numéro de version

Vous pouvez utiliser une combinaison de règles d'expiration et de numéros de version pour la récupération de mémoire. Les types de combinaisons sont intersection, union et imbriquée. Pour obtenir des exemples de configuration, consultez la section Récupération de mémoire basée sur plusieurs critères.

Intersection

Une stratégie de récupération de mémoire d'intersection marque les données à supprimer lorsqu'elles répondent à tous les critères d'un ensemble de règles donné. Par exemple, vous souhaitez peut-être supprimer les profils datant de plus de 30 jours, mais en conserver au moins un par utilisateur. Dans ce cas, votre stratégie d'intersection pour la famille de colonnes contenant la colonne de profil se compose d'une règle correspondant à une valeur d'expiration et d'une règle correspondant au nombre de versions.

Union

Une stratégie de récupération de mémoire de type union marque les données à supprimer lorsqu'elles répondent à n'importe quel élément dans un ensemble de règles donné. Par exemple, vous souhaitez peut-être conserver un maximum de 2 enregistrements de pages vues par utilisateur, mais seulement s'ils datent de moins de 30 jours. Dans ce cas, votre stratégie de type union est définie sur une valeur d'expiration ou un certain nombre de versions.

Nested

Une stratégie de récupération de mémoire imbriquée associe des règles de type union et intersection.

Paramètres par défaut de la récupération de mémoire

Il n'existe pas de valeur TTL par défaut pour une famille de colonnes. Le nombre de cellules conservées pour une colonne dépend de la manière dont est créée la famille de colonnes dans laquelle se trouve cette colonne, comme l'expliquent les sections suivantes.

Stratégie HBase

Si vous créez la famille de colonnes à l'aide du client HBase pour Java, de l'interface système HBase ou d'un autre outil utilisant le client HBase pour Java, Bigtable ne conserve que la cellule la plus récente de chaque colonne de la famille de colonnes, sauf si vous modifiez la règle correspondante. Ce paramètre par défaut est conforme à HBase.

Tous les autres outils ou bibliothèques clientes

Si vous créez la famille de colonnes à l'aide de tout autre outil ou de toute autre bibliothèque cliente, Bigtable conserve un nombre infini de cellules dans chaque colonne de la famille de colonnes. Cela inclut les familles de colonnes créées avec gcloud et la CLI cbt. Vous devez modifier la stratégie de récupération de mémoire correspondant à la famille de colonnes en question si vous souhaitez limiter le nombre de versions.

Quand les données sont supprimées

La récupération de mémoire est un processus continu au cours duquel Bigtable vérifie les règles correspondant à chaque famille de colonnes et supprime les données expirées et obsolètes en conséquence. En général, la suppression réelle des données peut prendre jusqu'à une semaine à partir du moment où les données correspondent aux critères établis par les règles. Aucune modification du moment de la récupération de mémoire n'est possible.

Dans la mesure où la suppression des données expirées peut prendre jusqu'à une semaine, vous ne devez jamais ne vous fier qu'aux stratégies de récupération de mémoire pour vous assurer que les requêtes de lecture renvoient les données souhaitées. Appliquez toujours à vos requêtes de lecture un filtre correspondant aux valeurs exclues par vos règles de récupération de mémoire. Vous pouvez utiliser un filtre limitant le nombre de cellules par colonne ou spécifiant une plage d'horodatage.

Par exemple, supposons que la règle de récupération de mémoire d'une famille de colonnes soit configurée pour ne conserver que les 5 versions les plus récentes d'un profil, et que 5 versions sont déjà stockées. Suite à l'écriture d'une nouvelle version du profil, la récupération de mémoire concernant la cellule la plus ancienne peut prendre jusqu'à une semaine. Par conséquent, pour éviter de lire la 6e valeur, vous devez toujours exclure à l'aide d'un filtre toutes les valeurs à l'exception des 5 versions les plus récentes.

Vous êtes facturé pour le stockage des données expirées jusqu'au compactage et à la suppression des données concernées par la récupération de mémoire.

La récupération de mémoire est rétroactive : lorsqu'une nouvelle stratégie de récupération de mémoire est définie, elle est appliquée à toutes les données de la table au cours des jours suivants. Si la nouvelle stratégie est plus restrictive que la stratégie précédente, les anciennes données sont supprimées à mesure du déroulement des opérations en arrière-plan, y compris les données écrites avant la modification de la stratégie.

Si vous voulez vous assurer que les données marquées pour la récupération de mémoire sont en cours de suppression, vous pouvez interroger votre table et comparer les données aux résultats attendus. Vous pouvez également surveiller la taille du tableau dans Google Cloud Console. Une table qui ne diminue jamais peut refléter une stratégie de récupération de mémoire qui ne fonctionne pas comme prévu. Cependant, gardez à l'esprit que la récupération de mémoire s'exécute avec un certain décalage.

Réplication et récupération de mémoire

La réplication peut affecter la récupération de mémoire de plusieurs manières.

Récupération de mémoire basée sur la version et l'utilisation du processeur

Dans une instance qui utilise la réplication, les suppressions de la récupération de mémoire basée sur la version sont répliquées sur tous les clusters de l'instance de la même manière que pour les requêtes d'application. Si vous écrivez rapidement des nouvelles cellules qui provoquent le marquage pour suppression de cellules plus anciennes, vous risquez d'augmenter l'utilisation du processeur lorsque Bigtable supprime les cellules obsolètes et les réplique sur d'autres clusters de l'instance. Préparez-vous à cette augmentation de l'utilisation du processeur si vous ajoutez un cluster à une instance contenant des tables qui utilisent la récupération de mémoire basée sur la version.

La récupération de mémoire en fonction de l'âge, en revanche, n'augmente pas l'utilisation du processeur dans les instances dupliquées.

Modifier les stratégies de récupération de mémoire basées sur la version

Vous pouvez modifier le nombre maximal de versions d'une famille de colonnes située dans une table répliquée. Toutefois, si vous réduisez le nombre de versions d'une famille de colonnes, il peut s'écouler jusqu'à une semaine avant que les clusters répliqués ne reflètent le nouveau nombre de versions. Par conséquent, vous devez toujours utiliser des filtres lors de la lecture des données.

Modifier les stratégies de récupération de mémoire basées sur l'âge

Vous pouvez augmenter ou réduire la durée de conservation spécifiée dans les règles de récupération des déchets, que l'instance utilise ou non la réplication. Vous pouvez également supprimer une stratégie de récupération de mémoire en fonction de l'âge.

Réduire la durée de conservation

Si vous diminuez la durée de conservation d'une règle basée sur l'âge, il peut s'écouler jusqu'à une semaine avant que tous les clusters ne se synchronisent et n'utilisent la nouvelle règle.

Augmenter la durée de conservation

Dans une table répliquée, vous pouvez augmenter la durée de conservation d'une règle de récupération des déchets d'un maximum de 90 jours.

Si vous augmentez la période de conservation d'une famille de colonnes, sachez que vos clusters peuvent être désynchronisés pendant plus d'une semaine. Pour en comprendre la raison, considérons un cas hypothétique dans lequel une table se trouve dans une instance à deux clusters, et vous modifiez la période de conservation d'une famille de colonnes de 30 à 50 jours:

  1. Une requête d'écriture pour la clé de ligne ip#685 est envoyée au cluster A avec la valeur 2023-01-02 pour la colonne click-through de la famille de colonnes profile. Les données sont répliquées vers le cluster B.
  2. Trente-un jours plus tard, la récupération de mémoire se produit sur le cluster A, et la valeur de la colonne click-through est reconnue comme expirée et supprimée.
  3. Vous modifiez la stratégie de récupération de mémoire pour la famille de colonnes profile, faisant passer la valeur TTL de 30 jours à 50 jours.
  4. Le lendemain, la récupération de mémoire s'exécute sur le cluster B. Comme la valeur TTL est de 50 jours, la valeur 2023-01-02 est conservée.
  5. Les clusters sont maintenant désynchronisés et le restent pendant près de 20 jours jusqu'à ce que la valeur qui existe dans le cluster B, mais pas dans le cluster A, soit supprimée.

Étape suivante