Améliorer les performances des requêtes dans Snowflake et ses coûts associés

Dans le blog précédent, nous avons compris comment Utiliser de manière optimale l’entrepôt et les tables Snowflake.

Continuons donc la série de blogs, où nous allons maintenant nous concentrer sur l’amélioration des performances dans Snowflake et ses coûts associés.

Comme nous le savons, les tables Snowflake sont micro-partitionnées, ce qui améliore considérablement les performances des requêtes. Cependant, au fil du temps, vous pouvez rencontrer une lenteur dans les requêtes en raison de l’augmentation des opérations DML sur de grands ensembles de données.

Dans ce cas, vous pouvez regrouper la table ou utiliser le service d’optimisation de la recherche pour améliorer les performances. Avant de décider quelle option choisir, vous devez considérer les cas d’utilisation spécifiques dans lesquels ils sont les plus avantageux et les impacts financiers associés. Sinon, vous risquez de rencontrer moins d’optimisations et des coûts de maintenance plus élevés.

Regroupement dans Snowflake

Le clustering dans Snowflake ne doit pas être confondu avec le partitionnement en termes de Big Data.

Le clustering dans Snowflake est un processus où il gère toujours les micro partitions mais maintenant dans l’ordre de la clé de clustering définie plutôt que dans l’ordre des insertions de données. Cela améliore les performances. Il y aura moins d’analyse de micro partition nécessaire pour une valeur de clé en cluster définie.

Lorsque vous choisissez le clustering sur une table, tenez compte des éléments suivants :

• Recommandé lorsque la table contient plusieurs téraoctets (To) de données et que les performances de la table se dégradent avec le temps en raison de nombreuses mises à jour et suppressions.
• L’utilisation d’un maximum de 3 à 4 colonnes de clustering est recommandée pour une clé de clustering. Au-delà, il n’y aurait pas d’impact significatif.
• Triez les colonnes en cluster avec les filtres les plus utilisés, puis par les prédicats de jointure les plus utilisés, puis utilisés Trier par, Grouper par clauses.
• Utilisez une colonne de clé de clustering contenant les éléments suivants :
  • Nombre suffisant de valeurs distinctes pour permettre un élagage efficace sur la table
  • Un nombre suffisamment petit de valeurs distinctes pour permettre à Snowflake de regrouper efficacement les lignes dans les mêmes micro-partitions.
• Triez les colonnes de la cardinalité la plus basse à la cardinalité la plus élevée.
• Si une colonne à cardinalité élevée doit encore être utilisée pour le clustering, définissez la clé comme une expression sur la colonne plutôt que sur la colonne directement pour réduire le nombre de valeurs distinctes.

Coûts associés au ReClustering

Lorsqu’une table existante est mise en cluster :

• Les micropartitions d’origine sont marquées supprimées mais conservées dans le système pour permettre le voyage dans le temps et la sécurité intégrée. Ils ne sont purgés qu’après Time Travel et Failsafe.
• De nouvelles micro partitions seront créées de la même taille que les anciennes partitions. Par conséquent, la maintenance des anciennes et des nouvelles partitions représente un coût supplémentaire.

Par exemple: Avant de recluster, disons que la taille de la table est de 100 Go, et si 2 Go sont ajoutés quotidiennement et 1 Go est supprimé, la table d’origine serait alors de 101 Go et la taille du voyage dans le temps serait de 2 Go pour ce jour. Mais après le reclustering, l’original contiendra toujours 101 Go de partitions actives selon la clé de cluster, et le voyage dans le temps aura également 100 Go de données, selon les anciennes micro partitions. Ces données de voyage dans le temps de 100 Go resteront jusqu’à ce qu’elles soient déplacées vers la zone Failsafe.

• Le clustering est toujours associé à un coût de reclustering automatique en arrière-plan dans l’entrepôt autogéré de Snowflake, et le coût associé doit également être pris en compte.

Services de requêtes d’optimisation de la recherche

Le clustering ne garantit pas l’amélioration des performances sur les colonnes non clusterisées.

Si vous avez des requêtes fréquentes sur des colonnes non clusterisées et que les performances sont la clé, quel que soit le coût, optez pour un service d’optimisation de la recherche sur l’ensemble du tableau de colonnes spécifiques.

Cela revient à activer l’indexation sur des bases de données RDBMS comme Oracle sur des colonnes spécifiques.

Impact sur les coûts de l’utilisation des requêtes d’optimisation de la recherche

Ressources de stockage :

Le service d’optimisation de la recherche crée une structure de données de chemin d’accès à la recherche qui nécessite de l’espace pour chaque table sur laquelle l’optimisation de la recherche est activée.

Le coût de stockage du chemin d’accès de recherche dépend de plusieurs facteurs :

• Le nombre de valeurs distinctes dans la table.
• Dans le cas extrême où toutes les colonnes ont des types de données qui utilisent le chemin d’accès de recherche et où toutes les valeurs de données de chaque colonne sont uniques, le stockage requis peut être égal à la taille de la table d’origine.
• En règle générale, cependant, la taille est d’environ 1/4 de la taille de la table d’origine.

Ressources de calcul :

• La consommation de ressources est plus élevée lorsque le taux de désabonnement est élevé.
• Ces coûts sont à peu près proportionnels à la quantité de données ingérées (ajoutées ou modifiées) et aux valeurs distinctes sur la table.
• Les suppressions ont également un certain coût.
• Le clustering automatique, tout en améliorant la latence des requêtes dans les tables avec l’optimisation de la recherche, peut encore augmenter les coûts de maintenance de l’optimisation de la recherche.
• Utilisez la fonction SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS pour estimer le coût de l’ajout de l’optimisation de la recherche à une table.

Pour réduire les coûts lors de l’utilisation de l’optimisation de la recherche :

• SUPPRIMER moins fréquemment.
• INSERT, UPDATE et MERGE : le regroupement de ces types d’instructions DML sur la table peut réduire les coûts de maintenance par le service d’optimisation de la recherche.
• Si vous recluster la table entière, envisagez de supprimer la propriété SEARCH OPTIMIZATION pour cette table avant de recluster, puis de rajouter la propriété SEARCH OPTIMIZATION à la table après la reclustering.

Vous recherchez une analyse approfondie et des avis d’experts? Découvrez nos autres ressources maintenant.

TROUVÉ CELA UTILE ? PARTAGEZ-LE