SNOWFLAKE
Storage Management
Optimiser Time Travel, Fail-safe et utiliser les tables transientes.
Time Travel
Erreur fréquente
Laisser 90 jours de Time Travel sur toutes les tables "par défaut" peut doubler votre facture storage sur les tables avec beaucoup de modifications.
Time Travel conserve les versions historiques. Ça coûte du storage !
-- Vérifier la rétention actuelle
SHOW TABLES LIKE 'events'; -- Voir DATA_RETENTION_TIME_IN_DAYS
-- Réduire pour les tables non critiques
ALTER TABLE staging_events
SET DATA_RETENTION_TIME_IN_DAYS = 1;
-- Minimum absolu (pas de Time Travel)
ALTER TABLE temp_table
SET DATA_RETENTION_TIME_IN_DAYS = 0;| Édition | Time Travel max |
|---|---|
| Standard | 1 jour |
| Enterprise+ | 90 jours |
Décision concrète
Tables de staging/ETL = 0-1 jour de Time Travel. Tables analytiques = 7 jours. Tables critiques (finance, compliance) = 30-90 jours.
Fail-safe
7 jours de protection supplémentaire après Time Travel. Non modifiable. Coûte du storage.
À retenir
Le Fail-safe coûte du storage mais n'est pas accessible par l'utilisateur. Seul le support Snowflake peut récupérer ces données. Utilisez des tables transientes si vous n'avez pas besoin de cette protection.
Tables transientes et temporaires
-- Transient : pas de Fail-safe (économie ~25% storage)
CREATE TRANSIENT TABLE staging_data (
id STRING,
data VARIANT
);
-- Temporary : supprimée à la fin de la session
CREATE TEMPORARY TABLE temp_analysis AS
SELECT * FROM events WHERE date = CURRENT_DATE();| Type | Time Travel | Fail-safe | Use case |
|---|---|---|---|
| Permanent | Oui | Oui | Données critiques |
| Transient | Oui | Non | Staging, dev |
| Temporary | Oui | Non | Analyses ponctuelles |
Erreur fréquente
Créer des tables permanentes pour des données de staging = payer 7 jours de Fail-safe inutilement. Utilisez CREATE TRANSIENT TABLE pour vos pipelines ETL.
