Résumé

  • Pour une table permanente Snowflake, la fin de Time Travel ouvre une période de Fail-safe de sept jours, non configurable. Les données historiques continuent d’occuper du stockage facturé.
  • Une baisse de rétention, un choix de table transient et la suppression de clones agissent sur des obligations différentes. La disparition du nom de la table ne solde pas à elle seule le stockage conservé.

Le mot « permanente » a un sens tarifaire très concret chez Snowflake. Même supprimée, une table de ce type laisse une possibilité de récupération qui se paie en stockage. Après la période de Time Travel choisie pour l’objet, sept jours de Fail-safe restent au compteur.

Une équipe peut donc avoir terminé son nettoyage et laissé une partie de son coût derrière elle. Le catalogue s’est allégé ; les données suivent encore le calendrier de protection. Pour un acheteur de services cloud, la date utile devient celle où les octets facturables quittent le système.

La documentation des coûts de stockage englobe les données actives, l’historique Time Travel, Fail-safe et les données que des clones continuent de référencer. Les tables sont compressées et la taille compressée sert au calcul. Compter les objets supprimés mesure une opération ; suivre les octets conservés permet d’en chiffrer l’effet.

Sept jours entre les mains du fournisseur

Le service Fail-safe commence après Time Travel. Sa durée de sept jours est fixe. La récupération relève alors de Snowflake, par l’intermédiaire du support, après épuisement des autres possibilités. Elle se fait dans la mesure du possible et peut prendre de quelques heures à plusieurs jours.

Le client a donc perdu l’accès ordinaire à son historique alors que le fournisseur peut encore tenter de le récupérer. Cette réserve de secours reste un poste de stockage. Une intervention de récupération consomme aussi des ressources de calcul sans serveur facturables. Conserver une chance de sauvetage et la mobiliser constituent deux dépenses distinctes.

Le choix initial de table organise ce partage. Le barème des durées historiques indique les possibilités suivantes :

Type de table Time Travel Fail-safe ensuite
Permanente, Standard Edition Zéro ou un jour Sept jours
Permanente, Enterprise Edition et versions supérieures De zéro à 90 jours Sept jours
transient Zéro ou un jour Aucun
temporary Zéro ou un jour, jusqu’à la suppression ou à la fin de session Aucun

Mettre Time Travel à zéro sur une table permanente laisse donc subsister la seconde période. Une longue requête Time Travel peut retarder l’entrée dans Fail-safe jusqu’à son achèvement. Des traitements en arrière-plan effectuent les transitions. Le calendrier de conservation et la libération effective des octets ont chacun leur rôle.

Réduire la durée ne vide pas immédiatement l’armoire

La notice Time Travel décrit un passage de dix jours de rétention à un seul. Les données du dernier jour restent dans Time Travel ; celles des jours deux à dix passent en Fail-safe. Le client raccourcit la période pendant laquelle il peut utiliser lui-même l’historique. Une partie des données poursuit son séjour dans le service de secours.

L’ordre des opérations est encore plus décisif pour une table déjà supprimée. Dans l’exemple officiel, une table hérite de 90 jours de son schéma, puis est supprimée. Si le schéma passe ensuite à un jour, cette ancienne table garde ses 90 jours. Pour modifier sa durée propre, il faut d’abord restaurer l’objet, puis changer son paramètre.

Les nouveaux choix appliqués au parc actif ne réécrivent donc pas automatiquement les conditions d’une suppression antérieure. Un minimum imposé au niveau du compte peut également relever la durée effective. La valeur zéro inscrite sur un objet doit être lue avec la politique qui s’applique au-dessus de lui.

Le sujet déborde ainsi le travail d’entretien. Une décision prise lors de la création du jeu de données peut déterminer le coût d’un nettoyage bien plus tard, au moment où une autre équipe en aura la charge.

Le clone conserve une adresse dans l’ancien stock

La description du stockage des clones explique qu’ils partagent d’abord les micro-partitions existantes. Les modifications créent ensuite des partitions propres, et chaque objet suit son cycle de vie. Un instantané de développement peut donc continuer d’utiliser des données dont la table d’origine a disparu.

La référence TABLE_STORAGE_METRICS rend cet effet visible. La vue distingue les octets actifs, ceux de Time Travel, ceux de Fail-safe et ceux conservés pour des références de clones. Cette dernière catégorie couvre aussi les données retenues par des sauvegardes WORM.

Les tables supprimées restent présentes dans la vue tant que du stockage leur est facturé. Recréer le même nom peut y laisser plusieurs versions, chacune avec son historique. Le nom connu de l’équipe métier devient alors un raccourci insuffisant pour expliquer le montant : il faut retrouver l’objet et ses octets.

La vue Account Usage peut avoir jusqu’à 90 minutes de retard. Elle peut aussi conserver une ligne dont les quatre principaux compteurs sont tous à zéro ; cette ligne ne produit plus de frais de stockage. Le chiffrage propre à un compte exige ses octets compressés conservés, sa rétention effective et son prix applicable.

Le prix d’une protection plus courte

Une table transient permet zéro ou un jour de Time Travel et supprime Fail-safe. Son stockage actif reste payant aussi longtemps qu’elle existe. Le plafond d’un jour concerne la protection historique supplémentaire : laisser vivre une table pendant plusieurs semaines laisse plusieurs semaines de stockage actif.

Ce choix peut convenir à des données de travail reproductibles. Quand leur historique expire, Snowflake ne dispose plus de Fail-safe pour les récupérer. Le temps de reconstruction, les ressources nécessaires et l’interruption de travail deviennent les autres termes de l’économie réalisée.

Une table temporary dépend en outre de la session. Sa conservation historique cesse à la suppression ou à la fin de celle-ci. Se déconnecter ne termine pas la session ; fermer un client peut laisser plus de choses en place que prévu.

La protection supplémentaire a une valeur réelle pour une donnée difficile à reconstruire. Encore faut-il que quelqu’un choisisse sa durée, puis assume le retrait des copies devenues inutiles. Chez Snowflake, le bouton de suppression termine une tâche. Le stockage conservé attend que toutes les conditions de son départ soient réunies.