Optimiser le calcul des requêtes

Lors de l'évaluation des calculs exigés pour une requête, tenez compte de la quantité de travail requise. Quel est le temps CPU nécessaire ? Utilisez-vous des fonctions telles les fonctions JavaScript définies par l'utilisateur nécessitant des ressources processeur supplémentaires ?

Les bonnes pratiques présentées ci-dessous vous aideront à mieux contrôler les opérations de calcul des requêtes.

Évitez de transformer les données à plusieurs reprises via des requêtes SQL

Bonne pratique : Si vous utilisez SQL pour effectuer des opérations ETL, évitez les situations vous amenant à transformer les mêmes données de façon répétée.

Par exemple, si vous utilisez SQL pour raccourcir des chaînes ou extraire des données à l'aide d'expressions régulières, matérialisez les résultats transformés dans une table de destination : vous gagnerez en efficacité. Les fonctions telles que les expressions régulières nécessitent des calculs supplémentaires. Il vaut mieux donc interroger la table de destination sans ajouter la surcharge de la transformation.

Évitez les fonctions JavaScript définies par l'utilisateur

Bonne pratique : Évitez d'utiliser des fonctions JavaScript définies par l'utilisateur. Optez plutôt pour des fonctions UDF natives.

L'appel d'une fonction UDF JavaScript nécessite l'instanciation d'un sous-processus. L'activation de ce processus et l'exécution de la fonction UDF ont un impact direct sur les performances des requêtes. Si possible, utilisez plutôt un fichier UDF (SQL) natif.

Utilisez des fonctions d'agrégation approximative

Bonne pratique : Si votre cas d'utilisation le permet, utilisez une fonction d'agrégation approximative.

Si la fonction d'agrégation SQL que vous utilisez est dotée d'une fonction d'approximation équivalente, celle-ci accélère les performances des requêtes. Par exemple, au lieu de COUNT(DISTINCT), utilisez APPROX_COUNT_DISTINCT(). Pour en savoir plus, consultez la section Fonctions d'agrégation approximative du document de référence SQL standard.

Vous pouvez également utiliser les fonctions HyperLogLog++ pour effectuer des approximations (y compris des agrégations approximatives personnalisées). Pour en savoir plus, consultez la section Fonctions HyperLogLog du document de référence SQL standard.

Ordonnez les opérations de requête pour optimiser les performances

Bonne pratique : N'utilisez ORDER BY que dans la requête de plus haut niveau ou dans les clauses de fenêtrage (fonctions analytiques). Transférez les opérations complexes en fin de requête.

Si vous devez trier les données, commencez par les filtrer pour réduire le nombre de valeurs à trier. Si vous commencez par le tri, vous aurez beaucoup plus de données à ordonner que nécessaire. Il est préférable de trier un sous-ensemble de données plutôt que de trier la totalité des données et d'appliquer une clause LIMIT.

Lorsque vous utilisez une clause ORDER BY, celle-ci ne doit apparaître que dans la requête de plus haut niveau. Placer une clause ORDER BY au milieu d'une requête a un impact considérable sur les performances, à moins de l'utiliser dans un fenêtrage (fonction analytique).

Une autre technique d'ordonnancement des requêtes consiste à reporter les opérations complexes, telles que les expressions régulières et les fonctions mathématiques, à la fin de la requête. Là encore, cette technique permet d'élaguer les données autant que possible avant d'effectuer les opérations complexes.

Optimisez vos modèles de jointure

Bonne pratique : Pour les requêtes qui associent des données provenant de plusieurs tables, optimisez vos modèles de jointure. Commencez par la table la plus grande.

Lorsque vous créez une requête à l'aide de la commande JOIN, tenez compte de l'ordre dans lequel vous fusionnez les données. L'optimiseur de requête SQL standard peut déterminer quelle table doit figurer sur tel côté de la jointure. Il est toutefois recommandé d'ordonner vos jointures de façon appropriée. La bonne pratique consiste à placer la table la plus grande en premier, suivie de la plus petite, puis de continuer par taille décroissante.

Lorsqu'une grande table constitue le côté gauche de la jointure JOIN et une petite le côté droit de la jointure JOIN, une jointure de diffusion est créée. Celle-ci envoie toutes les données de la plus petite table à chaque emplacement qui traite la plus grande table. Il est conseillé d’effectuer d’abord la jointure de diffusion.

Pour visualiser la taille des tables dans votre jointure JOIN, consultez la section Obtenir des informations sur les tables.

Élaguez les requêtes partitionnées

Bonne pratique : Lorsque vous interrogez une table partitionnée par période, utilisez la pseudo-colonne _PARTITIONTIME pour filtrer les partitions.

Lorsque vous interrogez des tables partitionnées, utilisez la pseudo-colonne _PARTITIONTIME. Le filtrage des données avec _PARTITIONTIME permet de spécifier une date ou une plage de dates. Par exemple, la clause WHERE suivante utilise la pseudo-colonne _PARTITIONTIME pour spécifier des partitions entre le 1er janvier 2016 et le 31 janvier 2016 :

WHERE _PARTITIONTIME
BETWEEN TIMESTAMP(“20160101”)
    AND TIMESTAMP(“20160131”)

La requête ne traite que les données des partitions spécifiées par la plage de dates. Filtrer les partitions améliore les performances des requêtes et réduit les coûts.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…