Comment le mode d’actualisation affecte-t-il les performances des tables dynamiques ?¶

Comprendre les performances de l’actualisation incrémentielle¶

Lors d’une actualisation incrémentielle, la plupart des efforts sont généralement consacrés au calcul des modifications apportées à la table dynamique. Cela dépend de la requête et peut être assez complexe. Un malentendu courant est qu’une actualisation incrémentielle n’analyse que les modifications apportées aux tables sources, et non les tables sources elles-mêmes. Cela peut conduire à l’idée fausse qu’une actualisation incrémentielle ne doit effectuer qu’un travail proportionnel à la quantité de données source qui ont changé, ce qui n’est pas vrai. En réalité, les actualisations incrémentielles doivent souvent analyser directement les tables sources.

Par exemple, imaginez une requête qui effectue une jointure interne entre les tables A et B. Si une ligne est insérée dans la table A, elle doit être jointe à la table B pour calculer les changements dans la requête. Cette simple ligne dans A peut être jointe à de nombreuses lignes dans B, ce qui peut entraîner une charge de travail importante même si les sources ne subissent que quelques modifications.

Ce travail supplémentaire peut être effectué par différents opérateurs. L’actualisation incrémentielle traite les nouvelles données et ignore ce qui a déjà été effectué. Décider de ce qui doit être ignoré peut demander du travail supplémentaire, en particulier pour les requêtes complexes, et différents opérateurs peuvent ignorer du travail de différentes manières.

En règle générale, la taille des modifications et la localité ont une incidence sur la quantité de travail qui peut être ignorée.

Comment la taille affecte-t-elle les performances de l’actualisation incrémentielle ?¶

Le facteur le plus important qui affecte les performances de l’actualisation incrémentielle est la taille des modifications apportées aux données sources. Lorsque vous déterminez la taille des modifications pour les actualisations de vos tables dynamiques, veillez à inclure les lignes copiées dans le décompte. Une DML qui modifie certaines lignes d’une micropartition copie également les lignes inchangées de cette micropartition dans une nouvelle micropartition.

Pour analyser le nombre de lignes modifiées, dans une table de base, créez un flux dans la table de base au moment de la dernière actualisation et utilisez SYSTEM$STREAM_BACKLOG. Par exemple :

CREATE STREAM mystream ON TABLE mybasetable BEFORE(STATEMENT => 'last refresh UUID');

SELECT * FROM SYSTEM$STREAM_BACKLOG('mystream');

À titre d’exemple extrême, considérez l’effet de la suppression de toutes les données d’une source : une actualisation complète ne voit qu’une table vide, qui peut être traitée très rapidement. En revanche, une actualisation incrémentielle doit traiter chaque ligne supprimée, ce qui le rend beaucoup plus lent.

Des ralentissements similaires peuvent également se produire dans des cas moins extrêmes. Une bonne ligne de conduite pour une charge de travail favorable consiste à limiter les changements dans la source ou la cible à moins de 5 % des lignes.

Comment la localité affecte-t-elle les performances de l’actualisation incrémentielle ?¶

Le deuxième facteur le plus important qui affecte l’actualisation incrémentielle est la localité, qui fait référence à la proximité des données ou des actions en fonction de différentes dimensions.

Par exemple, si vous avez une table avec une colonne d’horodatage et que vous insérez toujours des lignes avec l’heure actuelle dans cette colonne, votre charge de travail présente une forte localité entre l’ordre d’insertion et la colonne d’horodatage.

La localité peut se manifester sous diverses formes, mais certaines sont particulièrement importantes pour l’actualisation incrémentielle. L’amélioration de la localité dans l’un des domaines suivants augmente les performances des actualisations incrémentielles, bien qu’il ne soit pas toujours possible d’obtenir une forte localité dans les trois catégories.

Attentes en matière de performances pour les actualisations incrémentielles de chaque opérateur¶

Le tableau suivant indique les performances approximatives attendues pour les actualisations incrémentielles des opérateurs individuels. Les performances sont mesurées par rapport à une actualisation complète, en supposant que seulement 5 % des lignes ont été modifiées et que les tâches d’actualisation durent au moins une minute.

Pour les opérateurs qui sont affectés par la localité, le tableau montre les performances attendues avec une bonne et une mauvaise localité. Notez que, pour certains opérateurs, une faible localité peut conduire à de moins bonnes performances que des actualisations complètes.

Pour plus d’informations, voir Actualisation incrémentielle par les opérateurs.

Optimisation des performances du mode d’actualisation incrémentielle pour les tables dynamiques complexes¶

Les tables dynamiques contiennent généralement plusieurs opérateurs, ce qui rend plus difficile la prévision de leurs performances avec des actualisations incrémentielles. Cette section explique comment relever ce défi et donne quelques conseils pour améliorer les performances des tables dynamiques complexes.

Lorsque plusieurs opérateurs sont impliqués, les actualisations incrémentielles calculent les modifications en travaillant sur chaque opérateur séparément, en le transformant en un fragment de plan de requête qui peut calculer les modifications en fonction de ses entrées. Pour chaque entrée, ce nouveau fragment peut demander l’entrée avant les changements, après les changements ou simplement les changements eux-mêmes. En appliquant ce processus à chaque opérateur de la requête d’origine, vous obtenez un nouveau plan de requête qui calcule les changements en utilisant une combinaison de balayages de changements et de balayages complets de tables. Ce plan est optimisé par l’optimiseur de requêtes de Snowflake et exécuté comme n’importe quelle autre requête.

Lorsqu’une actualisation incrémentielle ne donne pas de bonnes performances, c’est généralement parce qu’il y a trop de changements ou que la localité est mauvaise. Les requêtes complexes rendent plus difficile l’identification de ces problèmes. Les performances des opérateurs incrémentaux dépendent généralement de la quantité de changements et de la localité de leurs entrées. Toutefois, ces entrées sont les sorties d’autres opérateurs, de sorte que la quantité et la localisation des données peuvent changer au fur et à mesure qu’elles passent par les opérateurs.

Par conséquent, pour comprendre les performances d’une actualisation incrémentielle complexe, il faut prendre en compte les données de chaque opérateur séparément. Voici quelques scénarios courants et des suggestions pour y remédier :