Compréhension des contraintes d’immuabilité

Les contraintes d’immuabilité vous permettent de marquer des parties d’une table dynamique comme statiques. Lorsque vous définissez une contrainte d’immuabilité, Snowflake ignore ces lignes lors de l’actualisation, ce qui améliore les performances, en particulier pour les tables contenant de grandes quantités de données historiques.

Vous définissez des contraintes d’immuabilité avec la clause IMMUTABLE WHERE lorsque vous créez ou modifiez une table dynamique. La clause spécifie une condition, ou un prédicat, qui identifie les lignes immuables.

Principaux comportements :

  • Actualisation initiale : Snowflake ignore le prédicat IMMUTABLE WHERE lors de l’actualisation initiale, mais il l’applique à toutes les actualisations suivantes.

  • Mode d’actualisation complet : le prédicat limite le nouveau calcul aux seules lignes qui ne répondent pas à la condition.

  • Actualisation incrémentielle : les flux et les tables dynamiques à actualisation incrémentielle peuvent être lus à partir de tables dynamiques à actualisation complète auxquelles des contraintes d’immuabilité sont appliquées.

  • Clonage et réplication : Snowflake copies les contraintes IMMUTABLE WHERE sans limites.

Pour plus d’informations sur les coûts de calcul, voir Coût de calcul des contraintes d’immuabilité.

Quand utiliser les contraintes d’immuabilité

Les contraintes d’immuabilité sont utiles dans les scénarios suivants :

Éviter de retraiter les données historiques

Lorsque votre table dynamique contient des données historiques que vous ne souhaitez pas retraiter, marquez les anciennes lignes comme immuables.

Optimiser le mode d’actualisation complet

Tables dynamiques qui utilisent le mode d’actualisation complet recalculent normalement toutes les lignes à chaque actualisation. Les contraintes d’immuabilité limitent le recalcul aux seules lignes modifiables, ce qui réduit considérablement le travail lorsque la plupart des données sont historiques.

Faciliter les actualisations incrémentielles en aval

Certaines constructions de requêtes, telles que les fonctions de table définies par l’utilisateur en Python nécessitent qu’une table dynamique fonctionne en mode d’actualisation complet. En principe, cela empêche les tables en aval de bénéficier d’une actualisation incrémentielle. Lorsque la table en amont présente des contraintes d’immuabilité, les tables en aval peuvent toujours bénéficier d’un traitement incrémentiel.

Utiliser le remplissage avec immuabilité

Le remplissage étend les contraintes d’immuabilité. Le remplissage est une opération à zéro copie qui vous permet de copier instantanément des données existantes dans une table dynamique sans les recalculer. Utilisez-le pour migrer les pipelines existants, modifier les définitions des tables dynamiques ou éviter une initialisation coûteuse lors de la création de tables contenant des années de données historiques.

Les données remplies ne peuvent pas changer lors des actualisations futures.

Lorsque vous créez une table dynamique avec IMMUTABLE WHERE et BACKFILL FROM :

  • Le remplissage copie la région immuable à partir de la table source. La région immuable est composée de lignes qui correspondent à la condition IMMUTABLE WHERE.

  • La définition de la requête calcule la région modifiable. La région modifiable est composée de lignes qui ne répondent pas à la condition.

Interaction avec la clé primaire et les contraintes uniques (RELY )

Les tables dynamiques peuvent avoir une clé primaire et des contraintes uniques avec la propriété RELY. Lorsque les deux conditions suivantes sont remplies sur une table dynamique :

  • Un prédicat IMMUTABLE WHERE est défini, et

  • Au moins une clé primaire ou une contrainte unique possède l’ensemble de propriétés RELY,

par conséquent, les colonnes référencées dans le prédicat IMMUTABLE WHERE doivent être un sous-ensemble des colonnes référencées dans l’ensemble de toutes les clés primaires RELY et des contraintes uniques RELY sur cette table. Seules les contraintes avec la propriété RELY est incluse dans l’ensemble des colonnes autorisées, le cas échéant. Prenons les exemples suivants :

  • Si la table contient une clé primaire RELY sur la colonne A et une contrainte unique NORELY sur la colonne``B``, le prédicat IMMUTABLE WHERE peut uniquement référencer la colonne A (ou un sous-ensemble de colonnes de contraintes RELY).

  • Si la table contient une clé primaire RELY sur la colonne``A``, une contrainte unique RELY sur la colonne B et une contrainte unique NORELY sur la colonne``C``, le prédicat IMMUTABLE WHERE peut uniquement faire référence à``A`` et B ou tout sous-ensemble de ces colonnes.

La validité est vérifiée lorsqu’une contrainte RELY ou le prédicat IMMUTABLE WHERE est ajouté ou modifié. Si l’état résultant viole la règle (par exemple, le prédicat fait référence à une colonne ne se trouvant dans aucune contrainte RELY), l’instruction échoue avec une erreur.

Prochaines étapes

Pour des conseils et des exemples, voir Exemples de remplissage rétroactif et Contraintes d’immuabilité.