Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Workflow d’exécution et de planification de requête
L’illustration suivante fournit présentation d’ensemble du workflow d’exécution et de planification de la requête.
Le workflow de planification et d’exécution de la requête se déroule comme suit :
-
Le nœud leader reçoit la requête et analyse leSQL.
-
L’analyseur produit un arbre de requête initial qui est une représentation logique de la requête originale. Amazon Redshift saisit ensuite cette arborescence de requêtes dans l’optimiseur de requêtes.
-
L’optimiseur évalue et, si nécessaire, réécrit la requête afin d’optimiser son efficacité. Ce processus entraîne parfois la création de plusieurs requêtes connexes pour en remplacer une seule.
-
L’optimiseur génère un plan de requête (ou plusieurs, si l’étape précédente entraîné la création de plusieurs requêtes) pour que l’exécution s’effectue avec les meilleures performances. Le plan de requête spécifie les options d’exécution telles que les types de jointures, l’ordre des jointures, les options d’agrégation et les exigences de distribution des données.
Vous pouvez utiliser la commande EXPLAIN pour afficher le plan de requête. Le plan de requête est un outil fondamental permettant d’analyser et d’ajuster des requêtes complexes. Pour de plus amples informations, veuillez consulter Création et interprétation d'un plan de requêtes.
-
Le moteur d’exécution traduit le plan de requête en étapes, segments et flux :
- Étape
-
Chaque étape est une opération individuelle nécessaire au cours de l’exécution des requêtes. Les étapes peuvent être combinées afin d’autoriser les nœuds de calcul à effectuer une requête, créer une jointure ou une autre opération de base de données.
- Segment
-
Combinaison de plusieurs étapes pouvant être effectuées par un processus unique, également la plus petite unité de compilation exécutable par une tranche de nœud de calcul. Une tranche est l’unité de traitement parallèle dans Amazon Redshift. Les segments d’un flux s’exécutent en parallèle.
- Flux
-
Ensemble de segments à répartir entre les tranches de nœuds de calcul disponibles.
Le moteur d’exécution génère du code compilé basé sur les étapes, les segments et les flux. Le code compilé s’exécute plus vite qu’un code interprété et utilise moins de capacité de calcul. Ce code compilé est ensuite diffusé aux nœuds de calcul.
Note
Lors de l’évaluation de vos requêtes, vous devez toujours comparer les durées de la seconde exécution d’une requête, car la première durée d’exécution inclut la surcharge due à la compilation du code. Pour de plus amples informations, veuillez consulter Facteurs affectant la performance des requêtes.
-
Les tranches de nœuds de calcul exécutent les segments de requête en parallèle. Dans le cadre de ce processus, Amazon Redshift tire parti d’une gestion optimisée des communications réseau, de la mémoire et des disques pour transmettre les résultats intermédiaires d’une étape du plan de requête à la suivante. Cela contribue également à accélérer l’exécution des requêtes.
Les étapes 5 et 6 s’effectuent une fois par flux. Le moteur crée les segments exécutables pour un flux et les envoie vers les nœuds de calcul. Lorsque les segments de ce flux sont terminés, le moteur génère les segments pour le prochain flux. Ainsi, le moteur peut analyser ce qui est arrivé dans le flux précédent (par exemple, si les opérations étaient basées sur le disque) pour influencer la génération de segments dans le flux suivant.
Lorsque les nœuds de calcul sont terminés, ils renvoient les résultats de la requête au nœud principal pour le traitement final. Le nœud principal fusionne les données en un seul jeu de résultats et traite tous les tris ou agrégations nécessaires. Le nœud principal renvoie ensuite les résultats au client.
Note
Au besoin, les nœuds de calcul peuvent renvoyer des données au nœud principal au cours de l’exécution des requêtes. Par exemple, si vous avez une sous-requête contenant une LIMIT clause, la limite est appliquée au nœud principal avant que les données ne soient redistribuées dans le cluster pour un traitement ultérieur.
