Cet article est partagé par la communauté Huawei Cloud « [GaussTech Issue 2] Analyse du processus d'exécution des instructions de requête SQL GaussDB », auteur : base de données GaussDB.
L'importance de SQL pour les bases de données relationnelles est évidente. Tel un chef d'orchestre, il guide l'interprétation correcte de l'œuvre ainsi que l'harmonie et l'unité du rythme. En tant que nouvelle génération de base de données relationnelle distribuée, Huawei Cloud GaussDB présente d'excellentes performances techniques et une excellente compétitivité industrielle. De nombreuses personnes sont curieuses de connaître les technologies clés de GaussDB et ont laissé des messages sur le forum :
Aujourd'hui, nous allons commencer par le moteur SQL GaussDB et découvrir le processus d'exécution des instructions de requête SQL GaussDB, y compris les principes et les points techniques clés du moteur SQL GaussDB.
Si vous avez des questions ou des points d'intérêt techniques clés au cours du processus de compréhension, vous pouvez participer à [Yunka Q&A] pour découvrir le mystère du moteur SQL GaussDB, interagir et gagner des cadeaux , et laisser des messages pour une interaction entre experts. -one Répondez aux questions et vous aurez une chance d'obtenir des récompenses pour avoir posé des questions.
↓↓↓↓ Ce qui suit est le texte
Tout d'abord, présentons brièvement la structure du système de GaussDB, puis analysons le processus d'exécution des instructions de requête SQL GaussDB.
Architecture système GaussDB
Figure (1) Centralisé
Figure (2) Répartition
Lors de l'exécution des instructions SQL GaussDB, les rôles clés suivants sont impliqués :
| GTM |
Le Global Transaction Manager est chargé de générer et de conserver des informations uniques au monde telles que les ID de transaction globale, les instantanés de transaction, les horodatages et les informations de séquence. |
| CN |
Nœud coordinateur. Responsable de la réception des demandes d'accès des applications et du renvoi des résultats d'exécution au client ; responsable de la décomposition des tâches et de la planification des fragments de tâches à exécuter en parallèle sur chaque DN. Chaque CN est connecté à chaque DN et chaque CN détient une copie des métadonnées avec le même contenu de métadonnées. |
| DN |
Nœud de données. Responsable du stockage des données commerciales (prenant en charge le stockage de lignes, de colonnes et de stockage hybride), de l'exécution des tâches de requête de données et du renvoi des résultats d'exécution au CN. |
Parmi eux, DN est principalement responsable de l'exécution des instructions SQL GaussDB. Son architecture logique est illustrée dans la figure suivante :
Figure (3) Architecture logique de GaussDB
GaussDB comprend deux moteurs principaux : SQL Engine et Storage Engine . Le moteur SQL est parfois appelé processeur de requêtes et ses principales fonctions sont l'analyse SQL, l'optimisation et l'exécution des requêtes. L'analyse SQL effectue une analyse lexicale, une analyse syntaxique et une analyse sémantique sur l'instruction SQL d'entrée pour générer une arborescence de requêtes. Une fois que l'arborescence de requêtes a subi l'optimisation des règles (RBO) et l'optimisation des coûts (CBO), un plan d'exécution est généré. L'exécuteur extrait, exploite, met à jour, supprime et autres opérations sur les données pertinentes en fonction du plan d'exécution pour obtenir les résultats que l'utilisateur souhaite interroger.
Le moteur de stockage est responsable de la gestion de toutes les E/S de données. Il comprend le traitement de lecture et d'écriture des données (traitement des demandes d'E/S pour les lignes, les index, les pages, les allocations et les versions de lignes), la gestion du tampon de données (Buffer Pool) et les transactions. directeur. Parmi eux, la gestion des transactions implique le mécanisme de verrouillage (Lock) et la gestion des journaux de transactions (XLOG) qui maintiennent les attributs ACID.
Entre le moteur SQL et le moteur de stockage se trouve la couche AM (Access Method). AM encapsule la couche de stockage pour prendre en charge plusieurs moteurs de stockage (Astore, Ustore, etc.). La couche SQL n'appelle pas la couche de stockage directement, mais via la couche AM, la couche AM appellera différents corps d'exécution en fonction des différents moteurs de stockage.
Il ressort du diagramme d'architecture logique de GaussDB que la conception de l'architecture de GaussDB suit les principes de conception de l'abstraction du système logiciel moderne et du découplage hiérarchique, notamment : un mécanisme de transaction unifié, un système de journalisation unifié, un système de contrôle de concurrence unifié, un système de méta-information unifié et système de gestion de cache unifié. Par conséquent, l’architecture technique de GaussDB présente les principales caractéristiques suivantes :
-
Prend en charge l'optimisation, l'exécution et le découplage de la couche de stockage SQL ;
-
Prend en charge les moteurs de stockage enfichables.
Processus d'exécution de l'instruction de requête SQL
Le processus d'exécution d'une instruction de requête SQL (SELECT) est le suivant :
Figure (4) Processus d'exécution de l'instruction de requête
Comme le montre la figure ci-dessus, une instruction SQL doit générer une arborescence de requêtes via l'analyse SQL, l'optimisation des requêtes pour générer un plan d'exécution, puis transférer le plan d'exécution à l'exécuteur de requêtes pour effectuer les opérations d'exécution d'opérateur physique.
SQL est un langage descriptif entre calcul relationnel et algèbre relationnelle. Il absorbe la description de certains opérateurs logiques de l'algèbre relationnelle, tout en abandonnant la partie « procédurale » de l'algèbre relationnelle. La fonction principale de l'analyse SQL est de compiler une instruction SQL dans un arbre de requête composé d'opérateurs relationnels, qui comprend généralement des sous-modules d'analyse lexicale, d'analyse syntaxique et d'analyse sémantique.
L'optimisation des règles (RBO) effectue une transformation d'algèbre relationnelle équivalente sur la base de l'arborescence de requêtes, convertissant une instruction SQL en un SQL équivalent plus efficace, et joue un rôle clé dans l'optimiseur de base de données. En particulier dans les requêtes complexes, cela peut apporter des améliorations de performances de plusieurs ordres de grandeur.
L'exécution de requêtes consiste à exécuter des instructions de requête SQL conformément au plan d'exécution. La rationalité du choix de la méthode de stockage sous-jacente affectera l’efficacité de l’exécution des requêtes.
analyseur
1. Analyse lexicale : Identifiez les mots-clés, identifiants, opérateurs, terminaux, etc. pris en charge par le système à partir de l'énoncé de requête, et déterminez la partie inhérente du discours de chaque mot.
La norme SQL définit les mots-clés SQL et les informations sur les règles grammaticales. Au cours du processus d'analyse lexicale, GaussDB divise une instruction SQL en unités atomiques indépendantes en fonction des informations sur les mots-clés et des informations sur les intervalles, et chaque unité est affichée sous forme de mot.
2. Analyse grammaticale : Selon les règles de grammaire SQL définies, utilisez les mots générés dans l'analyse lexicale pour faire correspondre les règles de grammaire et générer l'arbre de syntaxe abstraite (AST) correspondant.
3. Analyse sémantique : vérifiez la validité de l'arbre syntaxique, vérifiez si les tables, colonnes, fonctions et expressions correspondantes dans l'arbre syntaxique ont des métadonnées correspondantes et convertissez l'arbre syntaxique abstrait en arbre de requête.
Le processus d'analyse sémantique est également le processus de liaison sémantique de validité. Grâce à l'inspection de l'analyse sémantique, l'arbre syntaxique abstrait est converti en arbre de requête. Les arbres de requêtes peuvent être représentés sous la forme d’expressions d’algèbre relationnelle.
optimiseur
L'optimiseur est un moyen très important pour améliorer l'efficacité des requêtes. Il comprend deux parties : l'optimisation des règles et l'optimisation des requêtes.
L'optimisation des règles est une transformation d'algèbre relationnelle équivalente basée sur l'arbre de requêtes. Puisqu'il s'agit d'une forme d'optimisation basée sur l'algèbre relationnelle, elle peut également être appelée optimisation algébrique. Bien que les résultats obtenus par deux expressions d’algèbre relationnelle soient exactement les mêmes, leurs coûts d’exécution peuvent être très différents, ce qui constitue la base de l’optimisation des règles.
L'optimisation des règles suit deux principes de base :
(1) Équivalence : les résultats de sortie de l'instruction originale et de l'instruction réécrite sont les mêmes.
(2) Efficacité : l'exécution de l'instruction réécrite prend moins de temps que l'instruction originale et utilise les ressources plus efficacement.
GaussDB implémente certaines techniques d'optimisation de règles clés, telles que :
Predicate pushdown : déclenchez le filtrage conditionnel plus tôt et réduisez le nombre de lignes traitées
Élimination des opérations redondantes : Éliminez les tables et colonnes redondantes pour réduire la quantité de calculs
Promotion de sous-requête : après la promotion, davantage d'ordres de jointure peuvent être mis en correspondance
Conversion externe vers interne : la jointure interne peut correspondre à plus d'ordres de jointure
Promotion des sous-liens : réduire les opérations de sous-plan et de diffusion
Éliminez les jointures inégales : réduisez les opérations NestLoop et Broadcast
Dans le processus de servir un grand nombre de clients, GaussDB résume les modèles d'utilisation du SQL métier et implémente des règles de réécriture avancées. Dans les prochaines colonnes, nous présenterons en détail la technologie d’optimisation des règles de GaussDB.
Optimisation des requêtes
L'optimisation des requêtes est basée sur le résultat de « l'optimisation des règles » et combinée avec les informations statistiques internes de la base de données pour planifier la méthode d'exécution spécifique de l'instruction SQL, c'est-à-dire le plan d'exécution. Basée sur différentes méthodes d'optimisation, la technologie d'optimisation des requêtes peut être divisée en :
(1) CBO (Cost Based Optimization, optimisation des requêtes basée sur le coût) : estimez le coût des chemins d'exécution candidats correspondant à l'instruction SQL et sélectionnez le chemin d'exécution le moins coûteux parmi les chemins candidats comme plan d'exécution final.
(2) ABO (AI Based Optimization, optimisation des requêtes basée sur l'apprentissage automatique) : grâce à l'apprentissage continu de l'expérience historique, ABO résume le modèle du scénario cible, forme un modèle dynamique et optimise de manière adaptative le scénario réel de l'utilisateur, obtenant ainsi le scénario réel de l'utilisateur. plan d'exécution optimal.
GaussDB utilise la technologie d'optimisation basée sur CBO et la combine avec ABO pour explorer activement l'efficacité de la modélisation, la précision de l'estimation et l'adaptabilité. Les étapes sont les suivantes :
Figure (5) Étapes d'optimisation des requêtes
Modèle d'informations statistiques : les informations statistiques sont la pierre angulaire du calcul du coût du chemin du plan. L'exactitude des informations statistiques joue un rôle crucial dans l'estimation du nombre de lignes et l'estimation des coûts dans le modèle d'estimation des coûts, ce qui affecte directement la qualité du plan de requête. Les caractéristiques des données de la table de base GaussDB incluent des valeurs distinctes, des valeurs MCV (Most Common Values), des histogrammes, etc.
Estimation des lignes : une fois qu'une contrainte a déterminé le taux de sélection, le nombre de lignes à traiter pour chaque chemin planifié peut être déterminé et le nombre de pages à traiter peut être calculé en fonction du nombre de lignes à préparer. estimation du coût.
Estimation des coûts : Estimez les coûts d'exécution des différents opérateurs en fonction de la quantité de données. La somme des coûts de chaque opérateur correspond au coût total du plan.
Lorsque le chemin planifié traite des pages, il existe un coût d'E/S, et lorsque le chemin planifié traite des tuples (par exemple, une évaluation d'expression sur des tuples), il existe un coût en CPU. Puisque GaussDB est une base de données distribuée, la transmission de données entre CN et DN entraînera des coûts de communication. Par conséquent, le coût total d'un plan peut être exprimé comme suit :
Coût total = coût IO + coût CPU + coût de communication
-
Recherche de chemin : traitez le processus de recherche de chemin de connexion en résolvant l'algorithme optimal de chemin (programmation dynamique, algorithme génétique) et trouvez le chemin de connexion optimal avec l'espace de recherche minimum.
GaussDB utilise une combinaison de modes de recherche ascendante et aléatoire. Le processus de recherche est également un processus de transformation d'une arborescence de requêtes en un plan d'exécution. Par exemple, chaque table peut avoir différents opérateurs d'analyse, et les opérateurs de jointure logique peuvent également être convertis en une variété d'opérateurs de jointure physique différents.
-
Génération de plan : convertissez le chemin d'exécution de la requête en plan d'exécution (PlanTree) et fournissez-le à l'exécuteur pour exécution.
L'optimisation des requêtes peut prendre beaucoup de temps, en particulier lorsqu'il s'agit de requêtes complexes. La mise en cache du plan est une fonctionnalité importante de GaussDB. Elle peut mettre en cache le plan d'exécution d'une instruction de requête afin que le plan d'exécution dans le cache puisse être directement utilisé la prochaine fois que la même requête est exécutée, évitant ainsi les calculs répétés et optimisant les performances de la requête.
Optimisation des requêtes distribuées
En tant que base de données distribuée native, la technologie d’optimisation des requêtes distribuées est particulièrement importante.
L'architecture distribuée GaussDB utilise pleinement les ressources informatiques de chaque nœud et ses performances globales augmentent linéairement à mesure que l'échelle du nœud s'étend. Afin de maximiser les performances et l'utilisation des ressources dans une architecture distribuée, GaussDB prend en charge quatre plans distribués, à savoir le plan léger CN, le plan FQS (Fast Query Shipping), le plan Stream et le plan Remote-Query, comme le montre la figure suivante :
Figure (6) Quatre plans distribués
-
CN léger : les instructions sont directement envoyées à un seul DN pour exécution (LIGHT_PROXY)
-
Principe d'exécution : CN délivre directement le message de déclaration QPBE au DN correspondant via le socket.
-
-
Scénarios applicables : L'instruction peut être exécutée directement sur un DN (instruction de fragment unique).
-
Émission d'instructions FQS (Fast Query Shipping) : plan d'émission d'instructions SQL
（REMOTE_FQS_QUERY）
-
Principe d'exécution : CN génère directement un plan RemoteQuery sans passer par l'optimiseur, et l'envoie à DN via la logique de l'exécuteur. Chaque DN génère un plan d'exécution basé sur l'instruction pushdown et l'exécute, et les résultats de l'exécution sont résumés sur le CN.
-
-
-
Scénarios applicables : les instructions peuvent être entièrement transmises à plusieurs DN pour être exécutées, et aucune interaction de données n'est requise entre les DN.
-
-
Livraison du plan STREAM : plan de distribution du plan SQL distribué (STREAM)
-
Principe d'exécution : CN génère un plan d'exécution avec les opérateurs de flux basé sur l'instruction originale via l'optimiseur et l'envoie à DN pour exécution. Il y a une interaction de données (nœud de flux) pendant le processus d'exécution de DN. L'opérateur de flux établit des connexions entre les DN pour l'échange de données, et CN résume les résultats de l'exécution. DN effectue la plupart des calculs.
-
-
-
Scénarios applicables : instructions complexes avec interaction de données entre CN et DN, et entre DN et DN pendant l'exécution .
-
-
Plan Remote-Query : plan distribué pour émettre certaines instructions SQL (REMOTE_QUERY)
-
Principe d'exécution : CN génère un plan RemoteQuery à partir d'une partie de l'instruction originale via l'optimiseur et envoie chaque RemoteQuery à DN. Une fois que DN est exécuté, les données de résultat intermédiaires sont envoyées à CN. Une fois que CN les a collectées, il effectue le calcul d'exécution de. le plan d'exécution restant. Par conséquent, le CN entreprend la plupart des calculs.
-
-
Scénarios applicables : il existe très peu de scénarios qui ne remplissent pas les trois premières conditions de génération et les performances sont très mauvaises.
Dans une architecture distribuée, les données d'une même table seront distribuées sur différents nœuds de données. Lors de la création d'une table, vous pouvez choisir de hacher ou de répartir aléatoirement les données sur chaque table. Afin d'effectuer correctement une opération de jointure entre deux tables, il peut être nécessaire de redistribuer les données des deux tables. Par conséquent, le plan d'exécution distribué de GaussDB ajoute trois opérateurs Stream qui font des données une méthode de distribution spécifique.
Figure (7) Opérateur de flux
Lors de la génération d'un chemin distribué, il sera examiné si les données des deux tables et les conditions de connexion se trouvent dans le même nœud de données. Sinon, l'opérateur de distribution de données correspondant sera ajouté. L'opérateur de redistribution Stream est sélectionné sur la base du principe de réduction du flux de données entre les nœuds DN.
C'est précisément grâce à l'utilisation raisonnable des opérateurs Stream qu'il est possible pour GaussDB de traiter des données à grande échelle dans une architecture distribuée. L'optimisation des opérateurs Stream est également une partie importante de l'optimisation des requêtes GaussDB.
Figure (8) Technologie d'optimisation de requêtes distribuées GaussDB
[ Points techniques clés ] Optimisation des requêtes distribuées : quatre plans d'exécution distribués et trois opérateurs Stream.
Actionneur
L'instruction reçue par l'exécuteur est le plan d'exécution généré par l'optimiseur pour l'instruction de requête SQL. Le plan d'exécution est composé de certains opérateurs d'exécution (opérateurs), expressions, etc. Il opère principalement sur l'ensemble de relations et génère finalement le résultat souhaité par l'utilisateur. ensemble de résultats souhaités. Voici plusieurs types courants d’opérateurs d’exécution :
1. Nœud du plan d'analyse
Le nœud d'analyse est chargé d'extraire les données des sources de données sous-jacentes, qui peuvent provenir du système de fichiers ou du réseau. De manière générale, les nœuds d'analyse sont situés au niveau des nœuds feuilles de l'arborescence d'exécution, servant de source d'entrée de données pour l'exécution, représentant généralement SeqScan, IndexScan et SubQueryScan.
Fonctionnalités clés : données d'entrée, nœuds feuilles, filtrage d'expressions
2. Nœud du plan de contrôle
Les opérateurs de contrôle ne mappent généralement pas les opérateurs algébriques, mais sont des opérateurs introduits pour que l'exécuteur puisse effectuer certains processus spéciaux, tels que Limit, RecursiveUnion et Union.
Principales fonctionnalités : utilisé pour contrôler le flux de données
3. Matérialiser le nœud de plan
Les opérateurs matérialisés font généralement référence aux exigences de l'algorithme. Lors du traitement logique des opérateurs, les données de la couche inférieure doivent être mises en cache. Parce que la quantité de données renvoyées par les opérateurs de la couche inférieure ne peut pas être prédite à l'avance, il est nécessaire d'en tenir compte. algorithme selon lequel toutes les données ne peuvent pas être placées. Conditions de mémoire, telles que Agg, Sort.
Caractéristique clé : toutes les données doivent être analysées avant d'être renvoyées
4. Les opérateurs de nœud de plan de jointure sont conçus pour gérer les opérations d'association les plus courantes dans les bases de données. Ils sont divisés en MergeJoin, NestLoop Join et HashJoin en fonction de différents algorithmes de traitement et sources d'entrée de données.
Principales fonctionnalités : requête associée
5. Autres opérateurs
L'architecture et la technologie de l'exécuteur déterminent également l'efficacité opérationnelle globale de l'exécution des requêtes de base de données. Le moteur d'exécution GaussDB combine pleinement les caractéristiques de la technologie matérielle moderne et utilise une variété de technologies logicielles modernes telles que les moteurs de vectorisation et LLVM pour une exécution efficace.
Figure (9) Architecture d'exécution entièrement parallèle de GaussDB
GaussDB utilise également diverses technologies pour améliorer les performances d'exécution des requêtes lors de l'exécution de plans distribués. Par exemple, lors de l'exécution de requêtes complexes, l'opérateur de réexécution sera poussé vers le nœud DN pour exécution, comme l'opérateur AGG. Lorsque l'opérateur pushdown est exécuté, la localité des données sera prise en compte et le calcul sera effectué localement autant que possible pour réduire la surcharge de transmission des données dans le réseau.
Si vous avez des questions ou êtes intéressé par des points techniques clés, vous pouvez dévoiler le mystère du moteur SQL GaussDB dans [Yunka Q&A], interagir les uns avec les autres et laisser un message dans la publication de l'événement pour gagner des cadeaux, et des experts répondront. questions en tête-à-tête et ont également la possibilité de recevoir des incitations pour poser des questions.
Cliquez pour suivre et découvrir les nouvelles technologies de Huawei Cloud dès que possible~
Linus a pris les choses en main pour empêcher les développeurs du noyau de remplacer les tabulations par des espaces. Son père est l'un des rares dirigeants capables d'écrire du code, son deuxième fils est directeur du département de technologie open source et son plus jeune fils est un noyau. contributeur à l'open source. Huawei : Il a fallu 1 an pour convertir 5 000 applications mobiles couramment utilisées Migration complète vers Hongmeng Java est le langage le plus sujet aux vulnérabilités tierces Wang Chenglu, le père de Hongmeng : l'open source Hongmeng est la seule innovation architecturale. dans le domaine des logiciels de base en Chine, Ma Huateng et Zhou Hongyi se serrent la main pour « éliminer les rancunes ». Ancien développeur de Microsoft : les performances de Windows 11 sont « ridiculement mauvaises » " Bien que ce que Laoxiangji est open source, ce ne soit pas le code, les raisons qui le sous-tendent. sont très réconfortants. Meta Llama 3 est officiellement publié. Google annonce une restructuration à grande échelle.