Comprendre le coût du stockage¶
Le coût du stockage représente le coût des éléments suivants :
Les fichiers mis en zone de préparation pour le chargement/déchargement de données en lots (peuvent être stockées de façon compressée ou non).
Les tables de base de données, y compris les données historiques pour Time Travel.
Fail-safe pour les tables de base de données.
Les clones de tables de base de données faisant référence à des données supprimées dans la table à laquelle appartiennent les clones.
Les coûts mensuels de stockage des données dans Snowflake sont basés sur un taux forfaitaire par téraoctet (TB). Le montant facturé dépend de votre type de compte (Capacité ou Sur demande) et de votre région (US ou EU).
Pour connaître le prix du stockage, consultez le guide des tarifs de Snowflake.
Dans ce chapitre :
Coûts des fichiers en zone de préparation¶
Les fichiers mis en zone de préparation pour le chargement/déchargement de données en masse entraînent des coûts de stockage basés sur la taille des fichiers. Pour plus d’informations sur le chargement des données, voir Chargement de données dans Snowflake.
Coûts de la base de données¶
Les coûts de la base de données comprennent les données stockées dans les tables de base de données. Les coûts de la base de données comprennent également les données historiques conservées pour Time Travel. Snowflake compresse automatiquement toutes les données stockées dans les tables et utilise la taille du fichier compressé pour calculer le stockage total utilisé pour un compte.
Voir aussi Remarques relatives au stockage de données.
Coûts de Time Travel et Fail-safe¶
Les frais de Time Travel et Fail-safe sont calculés pour chaque période de 24 heures (c.-à-d. 1 journée) à partir du moment où les données ont changé. Le nombre de jours de données historiques est géré en fonction du type de table et de la période de conservation de Time Travel pour la table.
Snowflake réduit la quantité de stockage requise pour les données historiques en ne conservant que l’information requise pour restaurer les lignes de tables individuelles qui ont été mises à jour ou supprimées. Par conséquent, l’utilisation de l’espace de stockage est calculée en pourcentage de la table qui a changé. Les copies complètes des tables ne sont conservées que lorsque les tables sont détruites ou tronquées.
Voir aussi Coûts de stockage pour Time Travel et Fail-safe.
Coûts des tables temporaires et transitoires¶
Pour aider à gérer les coûts de stockage associés à Time Travel et à Fail-safe, Snowflake offre deux types de tables, temporaires et transitoires. Les tables temporaires et transitoires ne sont pas soumises aux mêmes frais que les tables permanentes :
Les tables transitoires et temporaires contribuent aux frais de stockage que Snowflake facture à votre compte jusqu’à ce qu’elles soient explicitement supprimées. Les données stockées dans ces types de tables contribuent aux frais de stockage globaux que Snowflake facture à votre compte tant qu’elles existent.
Les tables temporaires sont généralement utilisées pour les données transitoires non permanentes et spécifiques à la session, telles que ETL ou d’autres données spécifiques à la session. Les tables temporaires n’existent que pendant la durée de vie de la session à laquelle elles sont associées. En fin de session, les données de la table temporaire sont purgées et irrécupérables. Les tables temporaires ne sont pas accessibles en dehors de la session spécifique qui les a créées.
Les tables transitoires existent jusqu’à ce qu’elles soient explicitement supprimées et sont disponibles pour tous les utilisateurs ayant les privilèges appropriés.
Les tables transitoires et temporaires peuvent avoir une période de conservation Time Travel de 0 ou 1 jour.
Les tables transitoires et temporaires n’ont pas de période Fail-safe.
Les tables transitoires et temporaires peuvent, au maximum, entraîner un coût de stockage d’une journée.
Le tableau suivant illustre les différents scénarios en fonction du type de table :
Type de table |
Période de conservation de Time Travel (jours) |
Période Fail-safe (jours) |
Données historiques minimales et maximales conservées (jours) |
|---|---|---|---|
Permanent |
0 ou 1 (pour Snowflake Standard Edition) |
7 |
7 , 8 |
0 à 90 (pour Snowflake Enterprise Edition) |
7 |
7 , 97 |
|
Transitoire |
0 ou 1 |
0 |
0 , 1 |
Temporaire |
0 ou 1 |
0 |
0 , 1 |
Utilisation de tables temporaires et transitoires pour gérer les coûts de stockage¶
Lorsque vous choisissez de stocker des données dans des tables permanentes, temporaires ou transitoires, tenez compte de ce qui suit :
Les tables temporaires sont détruites lorsque la session dans laquelle elles ont été créées se termine. Les données stockées dans les tables temporaires ne sont pas récupérables après la destruction de la table.
Les données historiques dans les tables transitoires ne peuvent pas être récupérées par Snowflake après la fin de la période de conservation Time Travel. Utilisez des tables transitoires seulement pour les données que vous pouvez dupliquer ou reproduire indépendamment de Snowflake.
Les tables à longue durée de vie, telles que les tables de faits, devraient toujours être définies comme permanentes pour s’assurer qu’elles sont entièrement protégées par Fail-safe.
Les tables à courte durée de vie (c.-à-d. <1 jour), telles que les tables de travail ETL, peuvent être définies comme transitoires pour éliminer les coûts associés à Fail-safe.
Si le temps d’arrêt et le temps nécessaire pour recharger les données perdues sont des facteurs, les tables permanentes, même avec leurs coûts de sécurité Fail-safe supplémentaires, peuvent offrir une meilleure solution globale que les tables transitoires.
Note
Le type par défaut pour les tables est permanent. Pour définir une table comme temporaire ou transitoire, vous devez spécifier explicitement le type lors de la création de la table.
Coûts du 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, 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.
Coûts de l’exécution automatique inter-Cloud¶
L’exécution automatique inter-Cloud vous permet de fournir un produit de données à des consommateurs situés dans d’autres régions Cloud sans réplication manuelle des données. Lorsque votre produit de données est exécuté automatiquement dans une autre région, vous devez supporter des coûts de stockage, entre autres. Pour plus de détails, voir Gestion des coûts de l’exécution automatique inter-Cloud.
Chapitre suivant