openGauss源码解析（179）

openGauss源码解析：AI技术（26）

8.6 AI查询时间预测

在前面介绍过“慢SQL发现”特性，该特性的典型场景是新业务上线前的检查，输入源是提前采集到的SQL流水数据。慢SQL发现功能主要主要应用在多条SQL语句的批量检查上，要求之前执行过SQL语句，因此给出的结果主要是定性的，在某些场景下可能难以满足用户对于评估精度的要求。

因此，为了弥补上述场景的不足，满足用户更精确的SQL时间预测需求，同时为AI优化器做铺垫，实现了本章所述的功能。

由于实际业务场景具有复杂的特质，现有的数据库静态代价估计模型往往统计结果失准，从而选择了一些执行计划较差的路径。因此，针对上述复杂场景，需要数据库的代价估计模型具备自我更新的能力。本特性主要功能为基于查询语句的历史数据，对当前执行的SQL语句进行查询耗时和基数的估算。

8.6.1 使用场景

AI查询分析的前提是需要获取执行计划。首先需要根据用户需求在查询执行时收集复杂查询实际查询计划（包括计划结构、算子类型、相关数据源、过滤条件等）、各算子节点实际执行时间、优化器估算代价、实际返回行数、优化器估算行数、SMP并发线程数、等信息。将其记录在数据表中，并进行持久化管理包括定期进行数据失效清理。

本功能主要分为两个方面，一个是行数估算，一个是查询预测，前者是后者预测好坏的前提。目前openGauss基于在线学习对执行计划各层的结果集大小进行估算，仅起到展示作用，并未影响到执行计划的生成。后续可帮助优化器更准确地进行结果集估算，从而获取更优的执行计划。

当前阶段本需求会提供系统函数来进行预测，并加入到explain中进行实际比较验证。

8.6.2 现有技术

当前学术界在AI4DB领域，对基于机器学习的行数估算和查询时延预测有许多尝试。

1. 传统方法

正如数据库优化器专家Guy Lohman在博客Is query optimization a “solved” problem中所说，传统数据库查询性能预测的“阿喀琉斯之踵”便是中间结果集大小的估算。对于行数估算传统基于统计信息行数估算方法主要基于三类假设。

（1） 数据独立分布假设。

（2） 均匀分布假设。

（3） 主外键假设。

而实际场景中数据往往存在一定的相关性和倾斜性，此时上述假设可能会被打破，导致传统数据库优化器在多表连接中间结果集大小估算中可能会存在数个数量级的误差。

2000年以来，以基于采样的估算、基于采样的核密度函数估算、基于多列直方图为代表的统计学方法被提出，用于解决数据相关性带来的估算问题。然而这些方法都存在一个共性问题，就是模型无法进行增量维护，而收集这些额外的统计信息会增加巨大的数据库维护开销，虽然在一些特定的问题场景（如多列Range条件选择率）取得了很大的准确率提升，但并没有被各大数据库厂商广泛采用。

传统性能预测方法主要依赖代价模型，在以下几个方面存在明显劣势。

（1） 准确性：随着底层硬件架构和优化技术不断演进，实际性能预测模型的复杂度远不可以用线性模型来建模。

（2） 可扩展性：代价模型的开发成本较高，不能面面俱到地对用户具体场景进行优化。

（3） 可校准性：代价模型灵活性仅局限于各资源维度线性相加时使用的系数，以及部分惩罚代价，灵活性较差，用户实际使用时难以校准。

（4） 时效性：代价模型依赖统计信息的收集和使用，目前缺乏增量维护方法，导致数据流动性较大的场景下统计信息长期处于失效状态。

2. 机器学习方法

机器学习模型在模型复杂度、可校准性、可增量维护性几个维度的优势能够弥补传统优化器代价模型的不足，基于机器学习的查询性能预测逐渐成为数据库学术界和产业界的主流研究方向之一。

除前文8.3节慢SQL发现部分介绍过相关方法外，清华大学的Learned Cost Estimator模型基于Multi-task Learning和字符条件的Word-Embedding方法进一步提升了预测准确率。

至此，机器学习方法虽然从实验效果上看达到了较高的准确率，但现实业务场景持续性的数据分布变化对模型的在线学习能力提出了要求。openGauss采用了数据驱动的在线学习模式，通过内核不断收集历史作业性能信息，并在AI Engine侧使用了R-LSTM（recursive long short term memory，递归长短期记忆网络）模型对算子级查询时延和中间结果集大小进行预测。