Du 17 au 19 avril, la Conférence Postgres 2024, l'une des plus grandes conférences PostgreSQL au monde, s'est tenue en grande pompe à San Jose, aux États-Unis. Cette conférence comprenait quatre volets : Ops, Dev, Essentials et Google Cloud. Les sujets étaient centrés sur le noyau PostgreSQL et. Des sujets tels que la gestion et l'application, les exemples d'utilisateurs et l'expérience ont été lancés, et des professeurs principaux de Google, AWS, EDB, Yugabyte, DBeaver et d'autres sociétés ont été invités à assister à la conférence. Forte de sa forte influence au sein de la communauté technologique internationale, Tuoshupai a été invité à participer à cet événement en tant que sponsor de la conférence et à prononcer un discours technique.
Lors de la conférence, l'expert technique de PieCloudDB, Richard Guo, en tant que nouveau contributeur PostgreSQL, a été invité à prononcer un discours technique "Une introduction de haut niveau au planificateur de requêtes dans PostgreSQL", combinant l'expérience de la construction de l'optimiseur de base de données PieCloudDB. L'optimiseur PostgreSQL du point de vue d'un développeur. Son fonctionnement et le processus de conversion d'un arbre de requête en arbre de plan sont présentés en détail. Le discours de Richard a reçu des commentaires positifs de la part du public et a conduit à une interaction et une communication approfondies.
Dans un système de gestion de base de données (SGBD), le traitement des requêtes SQL est un processus complexe et critique. Pour PostgreSQL, une instruction SQL doit passer par les cinq étapes principales suivantes, de la réception à l'exécution :
- Analyseur : responsable de la vérification des erreurs de syntaxe et de la génération d'un arbre d'analyseur ;
- Analyse (Analyzer) : effectuer une analyse sémantique basée sur l'arbre d'analyse et générer un arbre de requête ;
- Réécrivain : réécrivez l'arborescence des requêtes selon les règles qui existent dans le système ;
- Planification/optimisation (Planificateur) : générer un arbre de plan avec la plus grande efficacité d'exécution basée sur l'arbre de requête ;
- Exécuteur : accédez aux tables et aux index dans l'ordre dans l'arborescence du plan et exécutez la requête correspondante.
La même instruction de requête peut généralement être exécutée de plusieurs manières. En tant que composant important de la base de données, le rôle de l'optimiseur de requêtes est de trouver le plan de requête ayant le coût le plus bas parmi tous les modes d'exécution possibles et de le convertir en arborescence de plan exécutable.
Ce qui suit se concentrera sur la phase de planification/optimisation du traitement des requêtes PostgreSQL, qui est également la phase la plus importante et la plus complexe de l'ensemble du processus. Le processus est généralement divisé en quatre étapes : l'étape de prétraitement, l'étape d'optimisation de numérisation/connexion, l'étape d'optimisation hors numérisation/connexion et l'étape de post-traitement.
1. Étape de prétraitement
Au début de la phase de prétraitement, les requêtes sont généralement simplifiées autant que possible en simplifiant les expressions constantes (fonctions, booléennes, CASE, etc.) et en incorporant des fonctions SQL simples. Dans le même temps, l'arborescence des jointures sera simplifiée en convertissant IN, EXISTS et d'autres types de sous-requêtes en semi-jointures, en promouvant les sous-requêtes et en éliminant les jointures externes (en les convertissant en jointures internes ou anti-jointures).
En plus de ces méthodes, diverses méthodes d'optimisation sont utilisées plus tard dans la phase de prétraitement, notamment :
- Distribuer les contraintes WHERE et JOIN/ON
- Construire des classes d'équivalence
- Recueillir des informations sur les restrictions des ordres d'adhésion
- Éliminez les connexions inutiles
- ...
2. Phase de scanning/optimisation de la connexion
La phase d'analyse/optimisation de connexion traite principalement les parties FROM et WHERE de l'instruction de requête, et prend également en compte les informations ORDER BY. Cette partie est entièrement déterminée par le coût.
Cette étape détermine d'abord le chemin d'analyse pour la table de base, estime le coût du chemin d'analyse, puis utilise la programmation dynamique et des algorithmes génétiques pour rechercher l'intégralité de l'espace de séquence de connexion et générer le chemin de connexion. Lors de la recherche dans l'espace d'ordre de connexion, il est également nécessaire de prendre en compte les restrictions d'ordre de connexion causées par les jointures externes.
En programmation dynamique, la recherche de connexion se déroulera de la manière suivante :
- Générez d’abord un chemin d’analyse pour chaque table de base
- Générer des chemins de jointure pour toutes les jointures possibles de deux tables
- Générer des chemins de jointure pour toutes les jointures possibles des trois tables
- Générer des chemins de jointure pour toutes les jointures possibles de quatre tables
- ...
- Jusqu'à ce que toutes les tables de base soient connectées ensemble
Cependant, le coût de ce processus est très élevé : en théorie, il existe n ordres de connexion différents pour la connexion de n tables. Il est irréaliste de parcourir tous les ordres de connexion possibles. Par conséquent, certaines méthodes heuristiques sont généralement utilisées pour réduire l'espace de recherche. Pour les tables qui n'ont pas de conditions de jointure, essayez de ne pas les diviser en plusieurs sous-problèmes pour réduire la complexité.
3. Phase d'optimisation au-delà de la numérisation/connexion
A ce stade, l'optimiseur priorisera GROUP BY, l'agrégation, les fonctions de fenêtre et DISTINCT, puis traitera les opérations de collecte (UNION/INTERSECT/EXCEPT), et enfin traiter ORDER BY. Chacune des étapes ci-dessus générera un ou plusieurs chemins. L'optimiseur filtrera ces chemins en fonction du coût et ajoutera les nœuds LockRows, Limit et ModifyTable aux chemins filtrés.
4. Étape de post-traitement
À ce stade, l'optimiseur doit convertir le chemin le moins coûteux en une arborescence de plan et ajuster certains détails dans l'arborescence de plan :
- Aplatir la table de plage d'une sous-requête
- Modifiez les variables du nœud de plan supérieur sous la forme OUTER_VAR ou INNER_VAR pour pointer vers la sortie du sous-plan.
- Supprimez SubqueryScan, Append, MergeAppend et autres nœuds inutiles
Après avoir terminé cette étape, l'optimiseur obtiendra l'arborescence de plan complète et pourra transmettre l'arborescence de plan à l'exécuteur pour exécution, et enfin obtenir les résultats de la requête.
En tant qu'entreprise d'innovation de haute technologie basée en Chine, Tuoshupai a été profondément impliquée dans la technologie et l'écosystème open source international à travers des contributions de code, des conférences, le parrainage et la participation à des conférences, la coopération écologique et d'autres formes ces dernières années. À l'avenir, Tuoshupai continuera d'élargir ses horizons internationaux, de s'intégrer activement dans la vague d'innovation technologique mondiale, d'étendre son influence internationale et de construire une entreprise internationale axée sur la technologie.
J'ai décidé d'abandonner l'open source Hongmeng Wang Chenglu, le père de l'open source Hongmeng : L'open source Hongmeng est le seul événement logiciel industriel d'innovation architecturale dans le domaine des logiciels de base en Chine - OGG 1.0 est publié, Huawei contribue à tout le code source. Google Reader est tué par la "montagne de merde de code" Fedora Linux 40 est officiellement publié Ancien développeur Microsoft : les performances de Windows 11 sont "ridiculement mauvaises" Ma Huateng et Zhou Hongyi se serrent la main pour "éliminer les rancunes" Des sociétés de jeux bien connues ont publié de nouvelles réglementations : les cadeaux de mariage des employés ne doivent pas dépasser 100 000 yuans Ubuntu 24.04 LTS officiellement publié Pinduoduo a été condamné pour concurrence déloyale Indemnisation de 5 millions de yuans