Compréhension des coûts des tables dynamiques¶
Cette rubrique donne un aperçu des coûts de calcul et de stockage associés aux tables dynamiques. Pour obtenir des informations générales sur les coûts de calcul de Snowflake, consultez Comprendre le coût général.
Coûts de calcul¶
Deux coûts de calcul sont associés aux tables dynamiques : les entrepôts virtuels et le calcul des services cloud.
Les tables dynamiques nécessitent au moins un entrepôt virtuel pour effectuer les actualisations. Vous pouvez éventuellement attribuer un deuxième entrepôt si vous souhaitez séparer les coûts de calcul pour différentes opérations. Pour plus d’informations, voir Comprendre l’utilisation de l’entrepôt pour les tables dynamiques.
Les actualisations de tables dynamiques consomment des crédits de calcul, et leur fréquence est déterminée par la latence cible configurée : les valeurs de latence cible plus faibles déclenchent des actualisations plus fréquentes, et donc des coûts de calcul plus élevés.
Les tables dynamiques requièrent également le calcul des services Cloud pour identifier les modifications apportées aux objets de base sous-jacents et déterminer si un entrepôt virtuel doit être exécuté. Si le calcul des services Cloud ne trouve aucune modification, aucun crédit de calcul d’entrepôt n’est consommé, car il n’y a pas de nouvelles données à actualiser. S’il existe des modifications, même si la requête de la table dynamique les filtre, l’entrepôt virtuel consomme des crédits, car la table dynamique s’actualise pour évaluer si ces modifications s’appliquent.
Si les entrepôts virtuels associés sont suspendus et que le calcul des services Cloud ne détecte aucune modification dans les tables de base, les entrepôts restent suspendus et les tables dynamiques ne consomment aucun crédit. Lorsque le calcul des services Cloud identifie des modifications dans les tables de base, l’entrepôt approprié reprend automatiquement. Si les modifications prennent en charge l’actualisation incrémentielle, la table dynamique s’actualise à l’aide du paramètre WAREHOUSE. Si une réinitialisation est nécessaire (par exemple, en raison d’une modification du schéma de la table de base), la table dynamique utilise la fonction INITIALIZATION_WAREHOUSE pour effectuer une réinitialisation complète. Pour plus d’informations sur la suspension automatique des tables dynamiques, consultez Suspension automatique de tables dynamiques.
Vérifier votre consommation de crédits d’entrepôts virtuels¶
Pour vérifier si les actualisations de vos tables dynamiques ont consommé des crédits d’entrepôts virtuels, utilisez l’onglet Refresh History dans l’Snowsight :
Dans le menu de navigation, sélectionnez Transformation » Dynamic tables.
Sélectionnez votre table dynamique, puis sélectionnez l’onglet Refresh History.
Pour voir les actualisations qui ont utilisé l’entrepôt pour se mettre à jour, cochez la case Warehouse used only.
Astuce
Pour mieux comprendre les coûts liés à vos pipelines de tables dynamiques, Snowflake vous recommande de tester les tables dynamiques en utilisant des entrepôts dédiés. Ainsi, vous pouvez isoler la consommation de l’entrepôt virtuel qui est attribuée aux tables dynamiques. Vous pouvez déplacer vos tables dynamiques vers un entrepôt partagé après avoir établi une base de coûts.
Pour plus d’informations, voir Comprendre l’utilisation de l’entrepôt pour les tables dynamiques.
Coût de calcul des contraintes d’immuabilité¶
Si vous utilisez la contrainte IMMUTABLE WHERE, Snowflake recalcule uniquement les lignes qui ne répondent pas à la condition d’immuabilité, ce qui permet de réduire les coûts de réinitialisation. Cela est utile dans des situations où une réinitialisation peut se produire, comme dans les scénarios suivants :
Recréation de tableaux ou de vues en amont.
Modifications des politiques de gouvernance des données en amont.
Basculement vers une région secondaire dans un groupe de basculement.
L’utilisation de la contrainte IMMUTABLE WHERE peut vous aider à réduire le coût de l’actualisation incrémentielle et complète, car la contrainte ignore les modifications et les données qui correspondent à son prédicat.
L’ajout de contraintes d’immuabilité à une table dynamique ne déclenche pas de calculs supplémentaires, mais leur suppression en déclenche, car elle provoque une réinitialisation lors de la prochaine actualisation. La modification du prédicat dans une contrainte IMMUTABLE WHERE peut déclencher une réinitialisation, selon que Snowflake est en mesure de déterminer si les lignes renvoyées avec la condition initiale sont toujours renvoyées avec la nouvelle condition.
Par exemple, les modifications suivantes ne déclenchent pas de réinitialisation :
De
(ts < CURRENT_TIMESTAMP() - INTERVAL '2 jours')dans(ts < CURRENT_TIMESTAMP() - INTERVAL '1 jours')De
(année < = 2023)dans(année < = 2024)
Les modifications suivantes déclenchent la réinitialisation :
De
(ts < '2025-01-02')dans(ts < '2025-01-01')De
(année < 2024)dans(mois < 10)
Coût de stockage¶
Les tables dynamiques nécessitent du stockage pour conserver les résultats matérialisés. Comme pour les tables ordinaires, vous pouvez être amené à prendre en charge des coûts de stockage supplémentaires pour les fonctionnalités de clonage, Time Travel et Fail-safe.
Les tables dynamiques Apache Iceberg™ n’entraînent pas de coûts de stockage Snowflake. Pour plus d’informations, voir Facturation.
Cette section aborde les considérations suivantes en matière de stockage pour les tables dynamiques :
Pour des informations détaillées sur la manière dont ce stockage engendre des coûts, voir Comprendre le coût de stockage et Remarques relatives au stockage de données.
Stockage de Time Travel et de Fail-safe¶
Avec Snowflake Time Travel, vous pouvez accéder à des versions historiques de tables dynamiques et les interroger à des moments précis, ce qui peut vous aider à comprendre les tendances historiques, les changements et les anomalies dans vos données.
Des actualisations fréquentes peuvent augmenter l’accumulation des données Time Travel, ce qui accroît l’utilisation de votre stockage global. Pour plus d’informations, voir Compréhension et utilisation de la fonction Time Travel.
Les fonctions Fail-safe protègent vos tables dynamiques contre la perte ou la corruption de données. En fonction de la période Fail-safe configurée, des frais de stockage supplémentaires peuvent être appliqués.
Réplication des tables dynamiques¶
Les tables dynamiques prennent en charge la réplication entre comptes et entre régions, ce qui vous permet de copier les données d’une base de données principale vers une base de données secondaire pour la reprise après sinistre ou le partage de données. Cela peut servir de stratégie de préparation au basculement pour la reprise après sinistre ou de moyen de partage des données entre les déploiements à des fins de lecture seule. L’utilisation de la réplication avec des tables dynamiques est soumise à des coûts de réplication. Pour plus d’informations, voir Réplication et tables dynamiques.
Suspension de tables dynamiques¶
Les tables dynamiques suspendues n’entraînent pas de coûts supplémentaires au-delà des frais de stockage standard et ne consomment pas de ressources de calcul. Si vous avez des tâches de maintenance en cours ou des travaux planifiés qui interagissent avec la table suspendue, vos tables dynamiques peuvent consommer des ressources de calcul.
Tables dynamiques transitoires¶
Snowflake prend en charge la création de tables dynamiques transitoires , similaires aux tables classiques, qui existent jusqu’à ce qu’elles soient explicitement supprimées, et qui sont disponibles pour tous les utilisateurs possédant les privilèges adéquats sans période Fail-safe. Les tables dynamiques transitoires sont utilisées de préférence pour les données temporaires qui ne nécessitent pas le même niveau de protection et de récupération des données que les tables permanentes. Utiliser ces tables vous permet de réduire les frais de stockage pour Fail-safe.
Stockage supplémentaire pour les opérations d’actualisation incrémentielle¶
Pour les opérations d’actualisation incrémentielle, les tables dynamiques conservent une colonne de métadonnées interne supplémentaire pour identifier chaque ligne de la table. Les identificateurs de ligne internes consomment une quantité constante de stockage par ligne et augmentent le coût du stockage de manière linéaire en fonction du nombre de lignes de la table, indépendamment du nombre de colonnes.
Pour les tables comportant très peu de colonnes, l’augmentation du stockage par rapport à une table CTAS équivalente peut être significative, voire dominante. Dans les tables dynamiques plus volumineuses, cet effet est moins prononcé.
Coût de l’actualisation de la planification¶
La planification des actualisations des tables dynamiques, qu’il s’agisse d’actualisations complètes ou incrémentielles, a une incidence sur son coût global. Cette section examine les facteurs que vous devez prendre en compte lorsque vous décidez d’une planification d’actualisation, en supposant que chaque actualisation est non vide :
Note
Les actualisations sont relativement peu coûteuses si les sources n’ont pas changé. Pour plus d’informations, voir Coûts de calcul (dans ce chapitre).
Planification d’actualisation complète¶
Le coût d’une actualisation complète dépend généralement de la quantité de données analysées par votre table dynamique et de la fréquence de son actualisation. Pour réduire les coûts, vous pouvez actualiser vos tables dynamiques uniquement lorsque vous en avez besoin. Par exemple, vous pouvez suspendre vos tables dynamiques en dehors des heures de bureau. Pour un contrôle précis des délais, définissez la latence cible en aval pour vos tables dynamiques, et utilisez l’actualisation manuelle depuis une tâche pour automatiser vos planifications personnalisées.
Planification d’actualisation incrémentielle¶
Le coût d’une actualisation incrémentielle est généralement proportionnel au volume des modifications apportées aux objets sources, auquel s’ajoutent des frais généraux fixes.
Si les frais généraux sont faibles, vous pouvez fixer une fréquence d’actualisation élevée sans trop d’inconvénients. Cela signifie que vous pouvez actualiser souvent pour obtenir les meilleurs résultats. Par exemple, une table dynamique SELECT ... FROM ... WHERE simple ne traite que les lignes modifiées entre les actualisations, ce qui entraîne des frais généraux minimes, et la table dynamique peut être exécutée fréquemment à un coût supplémentaire faible.
Si les frais généraux sont élevés, vous devez trouver un équilibre entre la consommation de crédit liée à une fréquence d’actualisation élevée et les avantages commerciaux liés au niveau d’actualisation. Par exemple, dans une table dynamique avec une jointure, vous devez joindre les modifications d’une table à l’autre table. Quel que soit le volume de l’ensemble des modifications, cette jonction implique généralement un coût d’exécution minimal. Si ces frais généraux sont importants, ils peuvent s’accumuler au fur et à mesure que la fréquence d’actualisation augmente.