Dans un data warehouse traditionnel on premise, une opération sql inefficaces peut entraîner un temps d’exécution plus long.
Dans un data warehouse modern dans le cloud type Snowflake, cela entraine une surconsommation des crédits (Coût financier).
En plus de devoir écrire des requêtes sql plus efficace, les utilisateurs de Snowflake doivent également comprendre l’architecture de Snowflake et les différents caches associés (Metadata cache, Query result cache et Warehouse cache) pour pouvoir tirer parti des résultats pré-calculés.
Metadata cache :
Le cloud services layer gère les métadonnées des objets, telles que la structure, le nombre de lignes et les valeurs distinctes par colonne. L’examen de ces métadonnées via des fonctions SQL associées ou l’interface utilisateur de Snowflake ne nécessitera pas de virtual warehouse en cours d’exécution et ne consommera pas de crédits.
Snowflake stocke les métadonnées au niveau de la table (par exemple, la taille en octets et la date de création) et conserve les statistiques (par exemple, le nombre min/max) pour les colonnes de chaque micro-partition de la table.
Le cloud services layer stocke également les métadonnées pour les définitions et la structure des objets. Cela inclut le DDL pour les objets de base de données et les détails tels que la liste des colonnes, les types de et les contraintes. Les détails DDL peuvent être récupérés via des fonctions SQL telles que get_ddl qui ne nécessitera pas de virtual warehouse en cours d’exécution ou en interrogeant directement INFORMATION_SCHEMA. Ce dernier nécessitera un entrepôt actif et consommera des crédits.
Query Result cache :
Tous les résultats de requête dans un compte Snowflake sont conservés pendant 24 heures par le Query Result cache et peuvent être réutilisés par d’autres utilisateurs. Un nouveau résultat mis en cache peut être conserver entre 24 heures et une durée maximale de 31 jours, après quoi le résultat est purgé.
Il existe des considérations à prendre en compte pour garantir que les résultats mis en cache peuvent être réutilisés.
· La requête doit être syntaxiquement équivalente
· Les fonctions dynamiques telles que current_date() ne sont pas utilisées
· Les données des tables sous-jacents n’ont pas changé
· Les utilisateurs disposent des autorisations requises pour accéder aux sources sous-jacentes.
Obtenir un résultat à partir du Query Result cache est infiniment préférable au recalculer de la requête car l’opération se produit instantanément et ne consomme aucun crédit de calcul.
Warehouse cache :
Lorsqu’un virtual warehouse accède aux données de la couche de stockage (jacent tel que les buckets AWS S3), les données sont lues dans le cache du virtuel warehouse (implémenté à l’aide du stockage SSD). La quantité de stockage SSD dépend de la taille du virtual warehouse.
La lecture à partir du stockage SSD est plus rapide que la lecture à partir d’un stockage distant, et l’optimiseur de requêtes tentera d’utiliser le cache avant de passer au stockage distant. Cependant, contrairement aux caches du cloud services layer (Metadata cache et Query result cache), le warehouse cache présente deux différences significatives :
· Le cache est spécifique à un entrepôt donné
· La suspension du virtual warehouse purge son cache.
Dans cette optique, les utilisateurs accédant aux mêmes sources de données gagneraient à partager le même virtual warehosue. Cependant, des compromis doivent être considérés entre les crédits requis pour maintenir un virtual warehouse actif afin de préserver le cache et les E/S requises pour lire les données à partir du stockage distant.