博客/代码标注总结-奔走的月光队-openGauss

队伍名称

奔走的月光

队伍成员及其论坛主页

罗格

周忠泉

李欣然

主题介绍

        我们队伍力求将一条 SQL 语句在 openGauss 内部的处理流程给展现出来，从模块层面入手，在确定了各自负责的模块后，接着就从代码层面入手，从实际的理论出发，争取把流程讲明白，把内部机制说清楚。

工作介绍

        我们三人的工作围绕“一条 SQL 语句的处理流程”展开，那么，当我们将眼光放到 openGauss 是如何处理一条 SQL 语句时，我们就会发现，openGauss 内部的结构是有序的，是以模块为基本单位从而层层处理 SQL 语句的：

当一条 SQL 语句由终端输入，经 postmaster 模块即通信管理模块处理与客户端的连接请求后，被 parse 模块即查询分析模块接收，得到的查询树被 optimizer 模块即查询重写和查询优化模块接收后进一步重写优化，最后将得到的计划树交给 executor 模块查询执行模块，在查询执行模块执行计划树时会和存储引擎有数据交互，最后查询执行模块会将执行结果返回终端。

        我们三人的工作便是解析这几个重要模块，弄清楚它们的内部机理，接下来我将一一介绍。

罗格：队长

        本人负责解析查询分析、查询重写、查询执行模块，其中，查询分析模块是最复杂的。对一条查询语句进行查询分析，有三步：词法分析、语法分析、语义分析。经过前两步我们构造出了词法分析器和语法分析器，语法分析器能够调用词法分析器并返回语法分析树。这棵语法分析树被传送回主调函数，然而这时还不能确定它就是有效的。有可能这条语句并不符合语法规则。自然地， 由这条语句构造出来的语法分析树就是无效的。所以，我们还要对这棵语法分析树进行语义分析，那么，将由主调函数把这棵语法分析树交给特定的函数进行语义分析。如果它确实是有效的，那就会将它转变成查询树，之后它会被交给查询重写模块。然而并不是所有 SQL 语句构造出来的查询树都会被重写，例如由功能性语句创建而来的查询树便不会被重写。

        之后便是查询执行模块，它的内部又分为好几个子模块，主要的有 Portal 模块、Executor 模块、Plan 模块、Node 模块以及 ProcessUtility 模块。分层次地讲，Portal模块是决策模块，它决定要把计划树交给 Executor 模块还是 ProcessUtility 模块，而 Plan 模块和 Node 模块是 Executor 模块的下属模块，用来处理更加精细的工作。需要说一点，查询执行模块内部被划分成了几个模块，这并不是说它们仅限于模块和模块之间的联系，事实上，它们各自的接口函数是有一种层级的调用关系的，更详细的解释本人在文末的总结博客里有叙述。

周忠泉：队员

        该队员负责解析 Postmasters 模块，即通讯管理模块。前面已经提到，通信管理模块是openGuass 在处理简单 SQL 语句时的调用的第一个模块，也是其最基础的代码模块。openGauss查询响应使用的是“单个用户对应一个服务器线程”的简单客户端/服务器模型实现的。由于我们无法预先知道需要建立多少连接，所以必须使用主进程（GaussMaster）来监听指定 TCP/IP (传输控制协议/网际协议)端口上的传入连接，只要连接请求被检测到，主进程将生成一个新的服务器线程。服务器线程使用信号量和共享内存相互通信，以确保整个并发数据访问期间的数据完整性。

        另外，openGuass 的一大亮点就是将具有创新性的 AI 技术引入数据库，该同学在AI调优技术总结中介绍了AI引入数据库的两个研究方向，即 DB4AI 和 AI4DB，并对这两个方向中涉及的主要技术以图表的方式进行了总结，然后结合 openGuass 中使用到的 AI 技术进行了解析，包括数据库快照、数据库查询优化、X-Tuner 调优策略、索引管理技术等方面。通过比较发现，openGuass 相较于其他数据库中的 AI 技术，具有学习门槛低、数据库管理简洁、性能更优的特点。

李欣然：队员

        该队员负责查询优化模块的解析工作，已知查询重写和查询优化模块同属于优化器的，当查询重写模块将查询树重写后，这棵重写后的查询树就被传送到了查询优化模块。另外，我们所说的单棵查询树可以扩展到查询树链表，因为我们不一定是单次只写一条 SQL 语句，当事务中由多条 SQL 语句时，我们便会建立起对每条 SQL 语句的语法分析树，形成一条链表，最后过渡到查询树链表，这一点是很重要的。

        查询优化的第一步是查询重写，该队员从原理上进行了描述，发现 openGauss 采用的是 CBO(Cost Based Optimization) 技术，即基于代价的查询优化，并且在 ABO(AI Based Optimization) 技术即基于机器学习的查询优化上也有所探索。第二步则是路径搜索，优化器的核心问题是获取特定 SQL 语句的最优解，这个过程通常需要枚举 SQL 语句对应的解空间，即枚举不同的候选执行路径。这些候选执行路径是等价的，但是执行效率不同，需要计算执行成本，最终得到最优执行路径。第三步则是代价估算，查询执行成本分为 I/O 成本和 CPU 成本。这两个成本与查询期间处理的元组数量正相关。因此，选择性地评估查询计划的总成本会使得最终的执行计划更为高效。

代表性博客

1、查询分析模块总结

2、查询执行模块总结

3、查询重写模块总结

4、通信管理模块总结

5、查询优化模块总结

队伍总结

        在解析 openGauss 内部的模块前，我们还解析了一部分代码，为一部分代码添加了注释，可以在华为的openGauss仓库下看到我们的合并请求：GitLink | 确实开源，这段经历也让我们明白了 openGauss 内部代码的复杂程度。在查阅 openGauss 的源代码时，我们也会将所查阅的部分和 PostgreSQL 的对应代码作比较，看一看 openGauss 代码在哪里做了改进，查找比对代码的过程中我们自己也收获了很多的经验。同时，不断地翻看找来的资料，我们也进一步理解了 openGauss 的结构和机理。

        金秋十月，此次比赛接近尾声。我们团队不遗余力，奋发向上，终于将提交我们共同努力的最好的答卷。在此，感谢CCF开源发展委员会组织的这次比赛，为我们提供了展现能力的平台，感谢团队里的两位队员，以及我们的指导老师。