Remarques relatives au stockage de données¶

Ce chapitre fournit des lignes directrices et des conseils pour contrôler les coûts de stockage des données associés à la protection continue des données (CDP), en particulier pour les tables.

CDP, qui comprend Time Travel et Fail-safe, est un ensemble standard de fonctions disponibles pour tous les comptes Snowflake, et ce sans frais supplémentaires. Cependant, étant donné que votre compte est facturé pour toutes les données stockées dans les tables, les schémas et les bases de données créés dans le compte, CDP a un impact sur les coûts de stockage, en fonction de la quantité totale de données stockées et de la durée de stockage des données.

Le stockage est calculé et facturé pour les données, qu’elles soient sous l’état Actif, Time Travel ou Fail-safe. Comme ces états du cycle de vie sont séquentiels, les données mises à jour/supprimées protégées par CDP continueront d’entraîner des coûts de stockage jusqu’à ce que les données quittent l’état Fail-safe.

Note

TIME_TRAVEL_BYTES et FAILSAFE_BYTES entraînent des frais lorsque vous chargerez des données en utilisant INSERT, COPY ou SNOWPIPE. En effet, la défragmentation des petites micropartitions supprime les petites micropartitions et crée une nouvelle micropartition contenant les mêmes données. Les micropartitions supprimées contribuent aux TIME_TRAVEL_BYTES et FAILSAFE_BYTES.

Dans ce chapitre :

Surveillance du stockage des données¶

Stockage pour votre compte (administrateurs de compte uniquement)¶

Si on vous a assigné le rôle ACCOUNTADMIN (c.-à-d. que vous êtes l’administrateur de niveau supérieur de votre compte Snowflake), vous pouvez utiliser Snowsight ou l”Classic Console pour voir le stockage des données sur l’ensemble de votre compte :

Snowsight:: Select Admin » Cost Management » Consumption.
Classic Console:: Cliquez sur Account » Billing & Usage » Average Storage Used.

Cette page affiche la moyenne totale du stockage de données sur votre compte, ainsi que le total pour l’ensemble des bases de données, les zones de préparation internes et nommées, et les données dans Fail-safe.

Pour plus d’informations, voir Exploration des coûts de stockage.

Stockage de table individuel¶

Tout utilisateur disposant des privilèges suffisants peut voir le stockage des données des tables individuelles. Snowflake fournit les méthodes suivantes pour voir le stockage des données d’une table :

Classic Console:

Cliquez sur Databases » <nom_bdd> » Tables

SQL:

Exécutez une commande SHOW TABLES.

Interrogez l’un des éléments suivants :

Vue TABLE_STORAGE_METRICS (dans le Schéma d’information de Snowflake).
la vue Vue TABLE_STORAGE_METRICS (dans Account Usage).

Des trois méthodes, TABLE_STORAGE_METRICS fournit les informations les plus détaillées, car elle inclut une vue détaillée du stockage physique (en octets) pour les données des tables dans les trois états suivants du cycle de vie CDP :

Actif (colonne ACTIVE_BYTES)
Time Travel (colonne TIME_TRAVEL_BYTES)
Fail-safe (colonne FAILSAFE_BYTES)

La vue fournit également des colonnes pour faire la distinction entre le stockage propriétaire et le stockage référencé qui se produit lors du clonage de tables (voir la section ci-dessous).

Stockage de fichier préparé (pour le chargement de données)¶

Pour faciliter le chargement en masse de données vers des tables, Snowflake utilise des zones de préparation où les fichiers contenant les données à charger sont stockés. Snowflake prend en charge les zones de préparation internes et externes.

Les fichiers de données préparés dans les zones de préparation internes de Snowflake ne sont pas soumis aux frais supplémentaires associés à Time Travel et Fail-safe, mais ils engendrent des frais de stockage de données standard. Par conséquent, pour vous aider à gérer vos coûts de stockage, Snowflake vous recommande de surveiller ces fichiers et de les retirer des zones de préparation une fois que les données ont été chargées et que les fichiers ne sont plus nécessaires. Vous pouvez choisir de supprimer ces fichiers soit pendant le chargement des données (en utilisant la commande COPY INTO <table>) soit après (en utilisant la commande REMOVE).

Pour plus d’informations, voir Considérations relatives au chargement de données.

Astuce

La purge périodique des fichiers préparés peut avoir d’autres avantages, tels que l’amélioration des performances de chargement des données.

Clonage de tables, de schémas et de bases de données¶

La fonction de clonage sans copie de Snowflake offre un moyen pratique de prendre rapidement une « image » d’une table, d’un schéma ou d’une base de données, et de créer une copie dérivée de cet objet qui partage initialement le stockage sous-jacent. Ceci peut être extrêmement utile pour créer des sauvegardes instantanées qui n’entraînent pas de coûts supplémentaires (jusqu’à ce que des modifications soient apportées à l’objet cloné).

Cependant, le clonage rend le calcul de l’utilisation stockage totale plus complexe car chaque clone a son propre cycle de vie. Cela signifie que des modifications peuvent être apportées à l’objet original ou au clone indépendamment les uns des autres, et que ces modifications sont protégées par CDP.

Par exemple, lorsqu’un clone est créé à partir d’une table, le clone n’utilise pas de stockage de données, car il partage toutes les micro-partitions existantes de la table originale au moment où le clonage a été effectué. Cependant, des lignes peuvent être ajoutées, supprimées ou mises à jour dans le clone indépendamment de la table d’origine. Chaque modification apportée au clone résulte en de nouvelles micro-partitions qui sont la propriété exclusive du clone et qui sont protégées par CDP.

En outre, les clones peuvent être clonés, sans limitation quant au nombre ou aux itérations de clones qui peuvent être créés (par exemple, vous pouvez créer un clone d’un clone d’un clone, et ainsi de suite), ce qui donne une hiérarchie des objets clonés à N niveaux, chacun avec leur propre portion de stockage de données partagé et indépendant.

IDs de table¶

Chaque table Snowflake possède un ID qui l’identifie de façon unique. De plus, chaque table est également associée à un fichier CLONE_GROUP_ID. Si une table n’a pas de clones, alors l’ID et CLONE_GROUP_ID sont identiques. Ces IDs sont affichés dans la vue TABLE_STORAGE_METRICS.

Stockage propriétaire ou stockage référencé¶

Lorsqu’une table est clonée, on lui attribue un nouvel ID et le CLONE_GROUP_ID pour la table d’origine. Dès que le clone est créé, toutes les micro-partitions des deux tables sont entièrement partagées. Le stockage associé à ces micro-partitions est détenu par la table la plus ancienne du groupe clone, et le clone référence ces micro-partitions.

Après la création d’un clone, les deux tables au sein du groupe de clones ont des cycles de vie séparés, de sorte que toute opération DML sur l’une des tables crée de nouvelles micro-partitions qui sont la propriété de leurs tables respectives. Le stockage associé à ces micro-partitions peut être interrogé à l’aide de la colonne RETAINED_FOR_CLONE_BYTES de la vue TABLE_STORAGE_METRICS.

Étant donné que chaque table d’un groupe de clones a un cycle de vie indépendant, la propriété du stockage dans ces tables doit parfois être transférée à une autre table du groupe de clones. Par exemple, considérons un groupe de clones qui se compose des éléments suivants :

Table d’origine :

Cloné vers :

Cloné vers :

T1

»

T2

»

T3

Si T2 et T3 partagent certaines micro-partitions et que T2 est détruit, la propriété de ce stockage doit être transférée avant que T2 passe en Fail-safe. Dans Snowflake, ce transfert a lieu au moment où les micro-partitions quittent l’état Time Travel. Sinon, elles passent à l’état Fail-safe. Dans le cas ci-dessus, les micro-partitions qui appartenaient auparavant à T2 sont transférées à T3 à l’expiration de la période de conservation de Time Travel.

Gestion des coûts pour les tables à courte durée de vie¶

CDP est conçu pour assurer la protection à long terme de vos données. Ces données sont généralement stockées dans des tables permanentes. Sauf indication contraire au moment de leur création, les tables dans Snowflake sont créées comme étant permanentes.

Au cours d’un ETL ou d’un processus de modélisation des données, des tables à courte de durée de vie peuvent être créées. Pour ces tables, il n’est pas logique d’être soumis aux coûts de stockage de CDP. Snowflake offre deux mécanismes distincts pour prendre en charge les tables à courte durée de vie :

Tables temporaires
Tables transitoires

Tables temporaires¶

Comme pour les autres bases de données SQL, une table temporaire n’existe qu’au sein d’une seule session utilisateur et uniquement pendant la durée de la session. Les tables temporaires de Snowflake n’ont aucun Fail-safe et ont une période de conservation Time Travel de 0 ou 1 jour. Cependant, la période de Time Travel se termine lorsque la table est détruite.

Ainsi, le total maximum des frais CDP encourus pour une table temporaire est de 1 jour (ou moins si la table est explicitement détruite ou détruite suite à l’arrêt de la session). Pendant cette période, Time Travel peut être effectué sur la table.

Important

Une connexion et une session sont des concepts différents dans Snowflake. Une fois connecté à Snowflake, une ou plusieurs sessions peuvent être créées. Une session Snowflake n’est terminée que si l’utilisateur met explicitement fin à la session ou après 4 h d’inactivité. Se déconnecter de Snowflake ne met pas fin aux sessions actives. Ainsi, une session Snowflake peut avoir une très longue durée de vie, et toutes les tables temporaires créées dans cette session continueront d’exister jusqu’à ce qu’elles soient détruites ou que la session soit terminée.

Pour éviter des coûts de stockage imprévus pour les tables temporaires, Snowflake recommande de les créer au besoin au cours d’une session et de les détruire lorsqu’elles ne sont plus nécessaires.

Tables transitoires¶

Les tables transitoires sont uniques à Snowflake. Elles ont les caractéristiques des tables permanentes et temporaires :

Contrairement aux tables temporaires, les tables transitoires ne sont pas associées à une session. Elles sont visibles pour tous les utilisateurs qui ont les droits d’accès à cette table. De plus, à l’instar des tables permanentes, elles persistent au-delà de la session au cours de laquelle elles ont été créées.
Conformément aux tables temporaires, les tables transitoires n’ont pas de Fail-safe et n’ont qu’une période de conservation de Time Travel de 0 ou 1 jour.

Ainsi, le total maximum des frais CDP encourus pour une table transitoire est de 1 jour. Pendant cette période, Time Travel peut être effectué sur la table.

Gestion des coûts pour les tables de grande taille et à roulement élevé¶

Dans les plates-formes de données, les tables sont généralement des tables de faits ou de dimensions qui ont des modèles d’utilisation différents et, par conséquent, des considérations de stockage différentes :

Les tables de faits sont généralement de très grande taille et subissent peu de roulements (mises à jour ou suppressions de lignes). La plupart des modifications apportées aux tables de faits sont des insertions de nouvelles données ou, dans certains cas, des suppressions d’anciennes données. CDP est idéal pour les tables de faits car il offre une protection complète des données à un coût de stockage très bas.
Les tables de dimensions ont un modèle de mise à jour différent. Les mises à jour et suppressions de lignes sont beaucoup plus fréquentes dans les tables de dimensions. Lorsqu’une ou plusieurs lignes d’une table sont mises à jour ou supprimées, les micro-partitions sous-jacentes qui stockent ces données commencent les transitions de cycle de vie associées à CDP. Pour les tables de dimensions à haut taux de roulement, le stockage associé aux données Time Travel et Fail-safe peut être beaucoup plus important que le stockage de table actif.

Pour la grande majorité des tables de dimensions, le coût de stockage CDP associé à ces mises à jour est raisonnable. Les tables de dimensions sont généralement de petite taille, et même si elles sont fréquemment mises à jour, le coût de stockage dans Snowflake est peu coûteux et les avantages de CDP l’emportent largement sur les coûts.

Pour certaines tables de dimensions plus grandes et à haut taux de roulement, les coûts de stockage associés à CDP peuvent être importants. Lorsque plusieurs mises à jour sont effectuées sur une table, toutes les micro-partitions touchées sont recréées, puis elles passent par le cycle de vie de stockage CDP.

Les tables de dimensions à roulement élevé peuvent être identifiées en calculant le ratio FAILSAFE_BYTES divisé par ACTIVE_BYTES dans la vue TABLE_STORAGE_METRICS. Toute table avec un ratio élevé est considérée comme une table à roulement élevé. Étant donné que le stockage dans Snowflake est peu coûteux et que la plupart des tables à haut roulement consomment une quantité de stockage modeste, même si le ratio est élevé, il est conseillé de créer ces tables comme étant permanentes, et d’utiliser CDP pour protéger les données.

Dans certains cas, le coût de stockage des tables de dimensions à roulement élevé est excessif et il se peut que vous préfériez une autre option que CDP. Comme exemple extrême, imaginons une table avec des lignes associées à chaque micro-partition de la table (composée de 200 GB de stockage physique). Si chaque ligne est mise à jour 20 fois par jour, la table consommerait le stockage suivant :

Actif:

200 GB

Time Travel:

4 TB

Fail-safe:

28 TB

Stockage total:

32,2 TB

Pour les grandes tables de dimensions à roulement élevé créant des coûts CDP excessifs, la solution est de créer ces tables comme étant transitoires avec une période de conservation de Time Travel égale à zéro (c-à-d. DATA_RETENTION_TIME_IN_DAYS = 0), et ensuite de copier périodiquement ces tables dans une table permanente. Cela crée un sauvegarde complète de ces tables. Étant donné que chaque sauvegarde est protégée par CDP, lorsqu’une nouvelle sauvegarde est créée, l’ancienne peut être supprimée.

En utilisant l’exemple ci-dessus, les coûts de stockage associés à la même table de dimensions de 200 GB à haut roulement qui était sauvegardée une fois par jour seraient les suivants :

Actif:

200 GB

Time Travel:

200 GB

Fail-safe:

1,4 TB

Sauvegarde:

200 GB

Stockage total:

2 TB

Astuce

Les sauvegardes doivent être effectuées aussi souvent que nécessaire pour garantir une restauration complète en cas de perte de données. Pour ces tables, Snowflake recommande d’effectuer des sauvegardes au moins une fois par jour.