Récupération de mémoire

Cette page décrit le fonctionnement de la récupération de mémoire dans Cloud 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
  • Suppression réelle des donné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 Cloud 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. Jusqu'à leur suppression, les données apparaissent dans les résultats de lecture, 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 de 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 l'outil 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 Cloud Bigtable, l'intersection d'une ligne et d'une colonne peut comprendre plusieurs cellules, qui correspondent à différentes versions de la valeur située à 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.

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 :

Types de récupération de mémoire

Cette section décrit les types de récupération de mémoire disponibles dans Cloud 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. Cloud 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 Cloud Bigtable examine cette 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 récupérée afin que le nombre de versions ne dépasse pas 5.

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

Deux types de stratégies de récupération de mémoire permettent de combiner ces types de règles : l'intersection et l'union.

Intersection

Une stratégie de récupération de mémoire d'intersection supprime toutes les données correspondant à toutes les règles d'un ensemble 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 d'union supprime toutes les données correspondant au moins à l'une des règles d'un ensemble 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 d'union se compose d'une règle correspondant à une valeur d'expiration ou d'une règle correspondant au nombre de versions.

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 versions par défaut d'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, Cloud Bigtable ne conserve que la version la plus récente de chaque valeur 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, Cloud Bigtable conserve un nombre infini de versions de chaque valeur. Cela inclut les familles de colonnes créées avec gcloud et l'outil 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.

Suppression réelle des données

La récupération de mémoire est un processus continu au cours duquel Cloud 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 récupération de mémoire 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, ce qui affecte les données écrites avant la modification de la stratégie.

Si vous voulez vous assurer que les données font l'objet d'une récupération de mémoire, 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.

Modifications apportées aux stratégies de récupération de mémoire pour les tables répliquées

Cloud Bigtable vous permet de modifier ou de supprimer une stratégie concernant une famille de colonnes à tout moment si la table se trouve dans une instance à cluster unique. Par ailleurs, certaines restrictions s'appliquent aux tables des instances répliquées. Ces restrictions protègent vos données.

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.

Cloud Bigtable ne vous permet pas d'augmenter la valeur TTL d'une famille de colonnes dans une table répliquée. Pour en comprendre la raison, considérons le cas suivant : vous souhaitez faire passer la valeur TTL d'une famille de colonnes de 30 à 60 jours. La récupération de mémoire en fonction de l'âge peut s'exécuter séparément dans chaque cluster. Par conséquent, au moment où vous modifiez la stratégie, la récupération de mémoire peut avoir supprimé une valeur datant de 31 jours contenue dans l'une des copies d'une table, mais pas dans une autre. Si vous modifiez la stratégie de récupération de mémoire dans cette situation, les copies risquent de ne pas être synchronisées pendant près d'un mois.

Pour la même raison, Cloud Bigtable ne vous permet pas de supprimer une stratégie de récupération de mémoire en fonction de l'âge pour une famille de colonnes dans une table répliquée.

Étapes suivantes