Le moteur d'exécution Pipeline est une nouvelle fonctionnalité centrale d'ApsaraDB for SelectDB, conçue pour remplacer le moteur d'exécution historique. Dans les environnements à charges de travail mixtes, l'ancien moteur basé sur le modèle Volcano n'exploite pas pleinement les CPU multicœurs, subit l'épuisement du pool de threads et laisse les requêtes volumineuses affamer les petites requêtes. Le moteur d'exécution Pipeline remplace ce moteur hérité par une architecture push pilotée par les données. Cette approche élimine la prolifération des threads et réduit la contention des ressources entre les requêtes simultanées.
Pour plus de détails sur la conception, consultez Support Pipeline Exec Engine.
Fonctionnement
Le moteur d'exécution SQL historique repose sur le modèle Volcano. Ce modèle présente trois problèmes fondamentaux dans les environnements multicœurs :
Réglage manuel du parallélisme requis. Le moteur n'exploite pas automatiquement la capacité des CPU multicœurs. Pour améliorer les performances des requêtes, définissez manuellement le degré de parallélisme. Ce paramètre s'avère difficile à ajuster correctement en production.
Épuisement du pool de threads et interblocages. Chaque instance de requête occupe un thread dans le pool. Lorsque celui-ci atteint sa capacité maximale, le moteur de requête entre dans un pseudo-interblocage et cesse de répondre aux nouvelles requêtes. Des interblocages logiques peuvent également survenir, par exemple lorsque tous les threads exécutent une tâche de sondage sur une même instance. Même sous une charge normale, les opérateurs bloquants retiennent des threads non réassignables aux instances exécutables, ce qui maintient une faible utilisation globale du CPU.
Surcharge élevée due au changement de threads. Les opérateurs bloquants dépendent du planificateur de threads du système d'exploitation. Dans les scénarios de charges de travail mixtes, cette dépendance entraîne une surcharge importante liée aux changements de contexte et dégrade le débit.
Le moteur d'exécution Pipeline résout ces problèmes grâce à trois modifications architecturales :
Passage d'une exécution pull à push. Les requêtes s'exécutent en mode push au lieu du modèle pull traditionnel. Les données circulent en aval via des pipelines sans que des threads attendent pour récupérer les résultats.
Transformation des opérations bloquantes en opérations asynchrones. Les opérateurs auparavant bloquants sont reconçus sous forme d'opérations asynchrones. Cela élimine la surcharge liée aux changements de threads et maintient une utilisation élevée du CPU.
Nombre de threads limité avec planification par tranches de temps. Le moteur plafonne le nombre de threads d'exécution et utilise un basculement par tranches de temps pour arbitrer entre les pipelines concurrents. Les requêtes volumineuses ne peuvent plus monopoliser les threads ni affamer les petites requêtes.
Configurer le moteur d'exécution Pipeline
Définissez des variables de session pour contrôler le fonctionnement du moteur d'exécution Pipeline lors d'une session de requête donnée.
Variables de session
| Variable | Valeur par défaut | Description |
|---|---|---|
enable_pipeline_engine |
true |
Active le moteur d'exécution Pipeline sur les nœuds backend (BE). Si cette valeur est définie sur true, le nœud BE utilise le moteur d'exécution Pipeline pour traiter les requêtes. |
parallel_pipeline_task_num |
0 |
Nombre de tâches de pipeline à exécuter simultanément par requête SQL. Lorsque cette valeur est 0, ApsaraDB for SelectDB la définit automatiquement à la moitié du nombre de cœurs CPU du nœud BE. |
max_instance_num |
64 |
Concurrence maximale définie automatiquement par ApsaraDB for SelectDB. Par défaut, cette variable de session est fixée à 64. |
Activer l'exécution Pipeline
Le moteur d'exécution Pipeline est activé par défaut. Pour l'activer explicitement :
SET enable_pipeline_engine = true;Définir la concurrence des pipelines
Par défaut, ApsaraDB for SelectDB définit automatiquement la concurrence des tâches de pipeline à la moitié du nombre de cœurs CPU (parallel_pipeline_task_num = 0). Pour modifier ce comportement :
SET parallel_pipeline_task_num = <n>;Lorsqueparallel_pipeline_task_numvaut0, la concurrence calculée automatiquement est limitée parmax_instance_num(valeur par défaut :64). Ajustezmax_instance_numpour modifier le plafond de la concurrence automatique.