Présentation de l’actualisation des tables dynamiques¶

Initialisation de la table dynamique¶

Lorsqu’une table dynamique est créée à l’aide d’une instruction CREATE DYNAMIC TABLE, elle est initialement alimentée par les données des tables sous-jacentes. Après sa création, la table dynamique fait l’objet d’une actualisation complète, y compris les tables dynamiques avec latence en aval. L’actualisation garantit l’isolation de l’instantané, en synchronisant toutes les tables dynamiques concernées, ce qui permet d’économiser des coûts grâce à l’absence d’actualisation des données pour les tables dynamiques en amont.

Cette actualisation initiale peut prendre un certain temps, en particulier si une analyse approfondie des données est nécessaire, et la durée de la création de la table dynamique dépend de la taille des données analysées. Pour suivre les progrès réalisés, interrogez l’historique des actualisations en utilisant information_schema.dynamic_table_refresh_history() et recherchez les entrées accompagnées de refresh_trigger = INITIAL.

En cas d’échec de l’initialisation, le processus de création de la table s’arrête, ce qui permet d’obtenir un retour d’information immédiat sur les définitions incorrectes. Lors de l’initialisation d’une nouvelle version d’une table dynamique existante, la version existante reste accessible jusqu’à ce que la nouvelle version soit disponible, ce qui garantit que l’échec de la création d’une nouvelle version n’affecte pas l’instance actuelle.

Types d’actualisation de table dynamique¶

Le processus d’actualisation d’une table dynamique se déroule de deux manières :

1. Actualisation incrémentielle : ce processus automatisé analyse la requête de la table dynamique et calcule les changements survenus depuis la dernière actualisation. Il fusionne ensuite ces modifications dans la table. Voir Types de requêtes prenant en charge les actualisations incrémentielles pour plus de détails sur les requêtes prises en charge.

2. Actualisation complète : Lorsque le processus automatisé ne peut pas effectuer une actualisation incrémentielle, il effectue une actualisation complète. Cela implique l’exécution de la requête pour la table dynamique et le remplacement complet des résultats matérialisés précédents.

Les constructions utilisées dans la requête déterminent si une actualisation incrémentielle peut être utilisée. Après avoir créé une table dynamique, vous pouvez surveiller la table pour déterminer si des actualisations incrémentielles ou complètes sont utilisées pour mettre à jour cette table.

Comprendre la latence cible¶

L’actualisation de table dynamique est déclenchée en fonction du degré d’obsolescence des données, ce que l’on appelle communément latence ou latence cible.

La latence cible est spécifiée de deux manières :

1. Mesure de niveau d’actualisation : spécifie le délai maximum pendant lequel le contenu de la table dynamique doit être décalé par rapport aux mises à jour des tables de base.

   Spécifiée à l’aide du paramètre TARGET_LAG = { num { seconds | ... | days } lors de la modification ou de la définition initiale d’une table dynamique.

2. DOWNSTREAM : spécifie que la table dynamique doit être actualisée à la demande lorsque d’autres tables dynamiques qui en dépendent doivent être actualisées. Les mises à jour sont déduites des objets de la base de données en amont. Les tables dynamiques en aval ne sont mises à jour qu’à la demande des consommateurs en amont.

Prenons l’exemple suivant, dans lequel la table dynamique 2 (DT2) est définie sur la base de la table dynamique 1 (DT1). DT2 doit lire dans DT1 pour matérialiser son contenu. En outre, un rapport consomme des données DT2 par le biais d’une requête.

Les résultats suivants sont possibles, en fonction de la manière dont chaque table dynamique spécifie sa latence :

Table dynamique 1 (DT1)	Table dynamique 2 (DT2)	Actualiser les résultats
TARGET_LAG = DOWNSTREAM	TARGET_LAG = 10minutes	DT2 est mis à jour au maximum toutes les 10 minutes. DT1 obtient, ou déduit, sa latence à partir de DT2 et est mis à jour chaque fois que DT2 demande des mises à jour.
TARGET_LAG = 10minutes	TARGET_LAG = DOWNSTREAM	Ce scénario doit être évité. La requête de rapport ne recevra aucune donnée. DT2 n’est pas actualisée, car aucune DT n’est construite au-dessus de DT2. En outre, DT1 sera fréquemment mise à jour.
TARGET_LAG = 5minutes	TARGET_LAG = 10minutes	DT2 est mis à jour environ toutes les 10 minutes avec des données provenant de DT1 et datant d’au plus 5 minutes.
TARGET_LAG = DOWNSTREAM	TARGET_LAG = DOWNSTREAM	DT2 n’est pas actualisée périodiquement, car DT1 n’a pas d’enfants en aval avec une latence définie.

Types de requêtes prenant en charge les actualisations incrémentielles¶

La table suivante décrit les expressions, les mots-clés et les clauses qui prennent actuellement en charge l’actualisation incrémentielle.

Mot-clé/Clause	Prise en charge des actualisations incrémentielles
WITH	Expressions de table communes (CTE) qui utilisent des fonctions d’actualisation incrémentielle prises en charge dans la sous-requête.
Expressions dans SELECT	Expressions, y compris celles qui utilisent des fonctions intégrées déterministes et des fonctions définies par l’utilisateur immuables.
FROM	Tables sources, vues et autres tables dynamiques.
OVER	Toutes les fonctions de fenêtre.
WHERE	Filtres avec les mêmes expressions que celles valables dans SELECT.
JOIN (et d’autres expressions pour joindre des tables)	Les tables dynamiques ne prennent actuellement en charge que les jointures internes, les jointures externes et les jointures croisées pour les actualisations incrémentielles. Note Pour utiliser les actualisations incrémentielles, vous devez recréer des tables dynamiques qui utilisent d’autres types de jointures Pour déterminer si vous devez recréer la table dynamique, utilisez l’une des procédures suivantes pour vérifier si la table dynamique utilise une actualisation complète : Exécutez la commande SHOW DYNAMIC TABLES et vérifiez si la colonne REFRESH_MODE de la table est FULL. Dans Snowsight, sur la page de détails de la table dynamique, vérifiez si Full Refresh est affiché en haut de la page. Vous pouvez spécifier un nombre quelconque de tables dans la jointure. Les mises à jour de toutes les tables de la jointure sont répercutées dans les résultats de la requête.
UNION ALL	Les tables dynamiques prennent en charge UNION ALL.
GROUP BY	Les tables dynamiques prennent en charge GROUP BY.

Actuellement, les constructions et les types de requêtes suivants ne sont pas pris en charge par les actualisations incrémentielles. Si vous les spécifiez dans la requête, le processus d’actualisation automatisé utilise une actualisation complète (ce qui peut entraîner un coût plus élevé) pour mettre à jour la table.

• jointures LATERAL

• Sous-requêtes en dehors des clauses FROM (par exemple, WHERE EXISTS)

• Fonctions définies par l’utilisateur VOLATILE

Comment les données sont-elles actualisées lorsque des tables dynamiques dépendent d’autres tables dynamiques ?¶

Lorsqu’une latence de table dynamique est spécifiée en tant que mesure de temps, le processus d’actualisation automatisé détermine le calendrier des actualisations, sur la base des temps de latence cibles des tables dynamiques. Le processus choisit un calendrier qui respecte au mieux les temps de latence cibles des tables.

Afin de préserver la cohérence des données dans les cas où une table dynamique dépend d’une autre, le processus actualise toutes les tables dynamiques d’un compte à des moments compatibles. Le délai des actualisations moins fréquentes coïncide avec celui des actualisations plus fréquentes.

Par exemple, supposons qu’une table dynamique A ait un temps de latence cible de 2 minutes et qu’elle interroge une table dynamique B dont le temps de latence cible est d’une minute. Le processus peut déterminer que A doit être actualisée toutes les 96 secondes et B toutes les 48 secondes. En conséquence, le processus peut se dérouler selon le calendrier suivant :

Point précis dans le temps	Tables dynamiques actualisées
2022-12-01 00:00:00	A, B
2022-12-01 00:00:48	B
2022-12-01 00:01:36	A, B
2022-12-01 00:02:24	B

Cela signifie qu’à tout moment, lorsque vous interrogez un ensemble de tables dynamiques qui dépendent les unes des autres, vous interrogez le même « instantané » des données de ces tables.

Notez que la latence cible d’une table dynamique ne peut être plus courte que la latence cible des tables dynamiques dont elle dépend. Par exemple, supposons ceci :

• Une table dynamique A interroge les tables dynamiques B et C.

• La table dynamique B a une latence cible de cinq minutes.

• La table dynamique C a une latence cible d’une minute.

Cela signifie que le temps de latence cible pour A ne doit pas être inférieur à cinq minutes (c’est-à-dire qu’il ne doit pas être inférieur au plus long des temps de latence pour B et C).

Si vous définissez la latence pour A à cinq minutes, le processus établit un calendrier d’actualisation avec ces objectifs :

• Actualisez C suffisamment souvent pour que sa latence soit inférieure à une minute.

• Actualisez A et B en même temps et suffisamment souvent pour que leur latence soit inférieure à cinq minutes.

• Assurez-vous que l’actualisation de A et B coïncide avec l’actualisation de C pour garantir l’isolation des instantanés.

Remarque : si les actualisations prennent trop de temps, le programmateur peut ignorer des actualisations pour essayer de rester à jour. Toutefois, l’isolation des instantanés est préservée.