Compréhension du coût 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ût 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 exigent que les entrepôts virtuels soient actualisés, c’est-à-dire qu’ils exécutent des requêtes sur les objets de base lorsqu’ils sont initialisés et actualisés, y compris les actualisations planifiées et manuelles. Ces opérations utilisent des ressources de calcul, qui consomment des crédits.
Les tables dynamiques nécessitent également le calcul de Cloud Services pour identifier les changements dans les objets de base sous-jacents et déterminer si l’entrepôt virtuel doit être invoqué. Si aucun changement n’est identifié, les crédits de l’entrepôt virtuel ne sont pas consommés puisqu’il n’y a pas de nouvelles données à actualiser. Notez qu’il peut arriver que les modifications apportées aux objets de base soient filtrées dans la requête de table dynamique. Dans de tels scénarios, les crédits de l’entrepôt virtuel sont consommés, car la table dynamique subit une actualisation pour déterminer si les modifications sont applicables.
Si l’entrepôt virtuel associé est suspendu et qu’aucun changement dans les objets de base n’est identifié, l’entrepôt virtuel suspendu n’est pas invoqué et aucun crédit n’est consommé. Inversement, si des changements sont identifiés, l’entrepôt virtuel est repris automatiquement pour traiter les mises à jour.
Les actualisations des tables dynamiques sont pilotées par la latence cible configurée. Les pipelines de tables dynamiques avec une latence cible plus faible sont actualisés plus souvent et entraînent donc des coûts de calcul plus élevés.
Vous pouvez utiliser l’onglet Refresh History dans Snowsight pour vérifier si les crédits de l’entrepôt virtuel ont été consommés :
Dans le menu de navigation, sélectionnez Monitoring » Dynamic Tables.
Sélectionnez votre table dynamique et allez dans l’onglet Refresh History. Cochez la case Warehouse used only pour voir les actualisations qui ont utilisé l’entrepôt pour se mettre à jour.
Astuce
Pour bien comprendre les coûts liés à vos pipelines de tables dynamiques, Snowflake recommande de tester les tables dynamiques à l’aide d’entrepôts dédiés afin de pouvoir isoler la consommation de l’entrepôt virtuel 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.
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 fonctions Time Travel, Fail-safe et clonage.
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¶
Snowflake Time Travel vous permet d’accéder à des versions historiques de tables dynamiques et de les interroger à des moments précis, ce qui peut vous aider à comprendre les tendances historiques, les changements et les anomalies dans vos données. Notez que 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 des tâches de maintenance en cours ou des travaux planifiés interagissent avec la table suspendue, des ressources de calcul peuvent être consommées.
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, ce qui permet de réduire les frais de stockage 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 à prendre en compte pour décider 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ût de calcul (dans ce chapitre).
Planification d’actualisation complète¶
Le coût d’une actualisation complète dépend généralement des données analysées et de la fréquence d’actualisation. Pour réduire les coûts, vous pouvez actualiser vos tables dynamiques uniquement lorsque c’est nécessaire. Par exemple, suspendez 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 des planifications personnalisées.
Planification d’actualisation incrémentielle¶
Le coût de l’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 simple table dynamique SELECT ... FROM ... WHERE ne traite que les lignes modifiées entre les actualisations, ce qui entraîne des frais généraux minimes et cela peut être exécuté 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 jointure, les modifications d’une table doivent être jointes à l’autre table. Quelle que soit la taille de l’ensemble des changements, 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.