数据库与AI结合起来会迸发出什么样的火花？不同的数据库厂商、开源社区、高校师生们的理解也都不尽相同。虽然在精确的概念上难以形成统一的标准，但是在总体的演进思路上却是一致的。对于openGauss来说，自从在社区开源第一个版本开始，openGauss便不断地在该领域演进并贡献代码，对于此次开源的openGauss 3.0.0 版本来说也不例外。

在3.0.0版本中，openGauss的AI领域将在多个方向演进：

1. 整合现有AI4DB功能，开源openGauss数据库自治平台；

2. 重构现有AI4DB能力，实现插件化、支持服务式的运行模式；

3. 支持Prometheus 生态；

4. 新增慢SQL根因分析、时序预测等新特性，优化现有的AI能力；

5. DB4AI功能支持更多算法。

DB4AI原生引擎进一步升级

在openGauss 3.0.0中，DB4AI原生引擎支持更多机器学习算法，例如支持SVM的非线性核函数，支持XGBoost等等。同时，openGauss还提供了Explain接口，可以观察到模型的信息。

AI4DB支持服务化、插件化

原有的openGauss AI4DB 能力是离线工具形态，不能在后台对数据库进行完整的监控，也不能定期地对数据库进行问题发现。最新版本，openGauss实现了后台监控服务，并在后台定期地检查数据库系统的状态，从而形成了自治数据库平台DBMind。通过离线计算的形式，将诊断结果保存，用户可以通过Grafana等软件进行可视化，从而第一时间发现问题并获知问题的根因。

由于需要在后台定期监控openGauss数据库系统的运行状态，因此，需要对接监控平台以便采集数据库监控指标并进行离线计算。故而，在3.0.0版本中，openGauss实现了两款exporter用于与Prometheus平台进行对接，其架构形态为：

其中，openGauss-exporter 用于获取数据库系统的监控指标（metric），reprocessing-exporter用于对存储在Prometheus中的数据进行二次加工。上述两个exporter的数据，可以通过Prometheus定期采集获取。DBMind系统定期从Prometheus中获取时序数据，并在DBMind部署机上进行并行计算。待计算完成后，将计算结果存储在元数据库（meta-database）中。之后，用户可以从元数据库中获取诊断结果，更进一步地，可以通过配置Grafana等进行可视化。

如上图所示，是一种基于元数据库中的数据，采用Grafana进行可视化的示例。

与此同时，openGauss还全面整合了现有的AI能力，并重新设计了一种插件化的模式。例如，用户希望调用参数调优功能，基于强化学习来调试数据库的参数，可以通过下述命令来实现：

gs_dbmind component xtuner tune …

通过上述gs_dbmind 命令，可以调用所有的AI功能，通过component 子命令，可以调用具体的AI功能。用户可以通过下述命令来查看帮助详情：

gs_dbmind component --help

通过上述设计，openGauss社区开发者如果希望贡献某种数据库AI功能，则只需要保证接口能被gs_dbmind获取到即可。同时，开发的插件还可以调用DBMind提供的全部API，例如从Prometheus 中获取数据的dai （data access interface）接口，向元数据库（meta database）中插入数据的 dao （database access object）接口等。

AI4DB 现有AI能力全面提升

在此次发布的3.0.0版本中，openGauss 对现有的索引推荐、时序预测等功能也进行了全面升级。补充了以往版本中的疏漏场景。同时，提供慢SQL根因分析与推荐功能，帮助DBA迅速识别出慢SQL，并依据监控到的数据库运行指标，通过AI特征库识别算法创新地给出慢SQL产生的原因和置信度，同时还给出优化建议。

为下一步开发全面的数据库AI自治平台打下基础

如上文所述，在openGauss 3.0.0版本中，创新性地完成了对历史AI能力的整合，丢弃历史研发过程中遗留下的包袱，轻装上阵，创新性地实现了可服务化、可离线式、插件式、自由组装的DBMind平台，并跟随数据库安装包一同发布。对于诊断后的结果，用户可以自行采用Grafana等工具进行自定义地可视化（当然，我们也会提供Grafana示例）。

这为我们未来更进一步地将DBMind平台升级打下基础，预计本年度openGauss会将更多AI功能丰富到该平台中，同时将该平台从现有代码仓库中独立出来，并提供原生的Web前后端展示平台，同时支持自修复功能，让用户真正体会到一键式、开箱即用的数据库自动驾驶。

- END -