学术加油站｜机器学习应用在数据库调优领域的前沿工作解读

编者按
本文系北京理工大学科研助理牛颂登所著，本篇也是「 OceanBase 学术加油站」系列稿件第八篇。
「牛颂登：北京理工大学科研助理。 硕士期间在电子科技大学网络空间安全研究院从事聚类和强化学习相关算法研究，在应用聚类研究个性化在线学习和强化学习的奖励函数设计方向取得了一定成果，目前研究方向为机器学习和数据库相结合的领域。」
本文以 VLDB 2021 的三篇 database tuning 论文为例，对机器学习应用在数据库调优领域的前沿工作做了总结和概述。希望阅读完本文，你可以对“database tuning”有新的认识，有什么疑问也可以在底部留言探讨。

现代数据库管理系统(database management systems，下简称 DBMS)公开了许多可配置的控制运行时行为的旋钮。正确选择 DBMS 的配置对于提高系统性能和降低成本至关重要。但是由于 DBMS 的复杂性，调优 DBMS 通常需要有经验的数据库管理员(database administrators，简称 DBAs)付出相当大的努力。最近关于使用机器学习(Machine Learning，ML)的自动调优方法的研究表明，与专业 DBA 相比，基于 ML 的自动调优方法获得了更好的性能。

An Inquiry into Machine Learning-based Automatic Configuration Tuning Services on Real-World Database Management Systems[1]

（一）调优过程

为了更好地理解 DBMS 的配置调优，探究在真实的企业级 DBMS 上 ML 调优方法的效果，论文通过运行在具有非本地存储的虚拟计算设施上的 Oracle DBMS 实例来比较企业数据库真实工作负载跟踪下的三种 ML 算法（GPR、DNN、DDPG）的调优效果。

论文的主要工作主要是扩展了 OtterTune 调优服务来支持三种 ML 调优算法，并提出了对三种算法的优化，在实验的过程中发现了一些自动调优技术领域中被忽略的部署和度量问题。

图 1 OtterTune 架构

OtterTune 是一个调优服务，它用来为 DBMS 的旋钮配置找到合适的设置，由controller 和 tuning manager 组成。 其中 controller 充当目标 DBMS 和 tuning manager 之间的中介，它在目标 DBMS 上执行目标工作负载，并收集运行时数据（包括旋钮配置和系统的度量）。Tuning manager 使用 controller 提供的调优会话信息更新其数据存储库，并使用这些信息建立 DBMS 如何响应不同旋钮配置的 ML 模型，然后用这些模型来指导实验并推荐新的配置给 controller，以将配置部署到 DBMS 上。这样的迭代过程一直持续到用户对配置的改进满意为止。

▋ Target Database Application：

因为论文探究的是真实企业 DBMS 的 ML 自动调优对系统性能提升的效果，作者在 Société Générale （SG）多国银行的实际业务数据下对 OtterTune 框架进行了评估。论文中使用了 TicketTracker 这一数据和工作负载跟踪的应用程序，对 SG 的工作单据进行 2 小时的跟踪，收到包含超过 360 万个查询调用。

作者使用 Oracle Recovery Manager 工具从 TicketTracker 数据库的生产服务器上创建了快照，复制了磁盘上未压缩的 1.1 TB 大小的数据库，并做了分析，其中 27%为表数据，19% 为表索引，54% 为大对象(Large objetcs)。TicketTracker 数据库包含 1226 个表，其中只有 453 个有数据的表，数据库基于它们包含 1647 个索引。

论文中使用 Oracle 的 real application testing（RAT）工具来捕获在 DBMS 实例上执行的查询，RAT 支持在测试数据库上使用原始工作负载的精确时间、并发性和事务特征对实例上的查询进行多次重放；重放的时间被限制在一个 10 分钟的片段（包含 23 万条查询）。

TicketTracker 数据库相比于之前一些 ML 调优采用的工作负载 benchmark——TPC-C，有数百个表，而 TPC-C 只有 9 个表；TPC-C 查询的写的比率占到46%，而 TicketTracker 里只占了 9%。这也表明实际的企业级 DBMS 与已有研究中的 benchmark 有很大不同。

优化算法的目标函数设置为 Oracle 的 DB Time，它用于度量数据库在处理用户请求时所花费的总时间，也是 SG 专业 DBA 首选的指标。论文在 SG 私有云的单独 Oracle v12.2 安装上部署了 TicketTracker 数据库和工作负载的五个副本。

（二）调优算法

图2 GPR/DNN调优管道

论文中的 GPR 实现基于 OtterTune 支持的原始算法，采用高斯过程作为先验函数，计算测试点与所有训练点之间的距离，该算法利用核函数来预测测试点的值和不确定度。由两阶段组成，第一个是数据预处理阶段，它在 Otter Tune 的数据存储库中准备旋钮配置和系统的度量数据。第二个是旋钮推荐阶段，为旋钮选择合适的值。

数据预处理： 目的是为了降低度量的维度，并选出最重要的一些的 knobs。在这一阶段首先确定 DBMS 度量的子集，算法使用因子分析（factor analysis）的降维技术，能够将度量减少到更小的因子集合。将度量降维后，继续计算对目标函数影响最大的旋钮的排序列表。论文使用了 Lasso 的特征选择方法，其中旋钮数据作为输入 X，输出的是结合已经修剪过的度量的目标数据。Lasso 在 X 和 y 之间的回归过程中确定了重要的旋钮顺序。

旋钮推荐： 负责在调优会话的每次迭代结束时生成一个新的旋钮配置建议。该算法使用上一阶段的输出数据在给定旋钮排序列表的情况下预测目标 DBMS 工作负载的度量值。然后，算法使用目标工作负载和当前最相似工作负载的数据构建一个GPR 模型。将给定的旋钮数组(x)作为输入，模型输出目标值(y)和不确定性值(u)的对(y, u)。算法计算 y 和 u 之和的置信上限(UCB)。然后在 UCB 上进行梯度上升，以找到能导致良好目标值的旋钮配置。

因为高斯过程模型在较大的数据集和高维特征向量上表现不佳[2]，所以，论文修改了 OtterTune 最初的基于 GPR 的算法，使用深度神经网络(DNN)代替高斯模型。二者遵循相同的 ML 管道，都是先进行数据预处理，然后进行旋钮推荐。

DNN 依赖于对输入应用线性组合和非线性激活的深度学习算法，模型的网络结构有两个隐含层，每层有 64 个神经元。所有各层均以整流线性单元(ReLU)作为激活函数完全连接。模型实现了一种称为 dropout 正则化的流行技术，以避免模型过拟合并提高其泛化。DNN 还在旋钮推荐步骤期间将高斯噪声添加到神经网络的参数中，以控制探索和利用。

图 3 DDPG调优管道

DDPG 方法首先由 CDBTune[3]提出,它是在连续动作空间环境中搜索最优策略的一种深度强化学习算法。DDPG 由三个组件组成：(1)actor (2)critic 和(3)replay memory。actor 根据给定的状态选择一个动作(例如，对一个 knob 使用什么值)。critic 根据状态对选定的动作（即旋钮值）进行评估，并且提供反馈来指导 actor。actor 的输入是 DBMS 的度量，输出推荐的旋钮值。critic 将之前的度量和推荐的旋钮作为输入，输出一个 Q 值，DDPG 神经网络的 Q 值计算的是对未来所有预期奖励的叠加。replay memory 存储按预测误差降序排列的训练数据。

对于每个旋钮 k, DDPG 构造一个元组，其中包含 (1) 先前的度量 m_pre，(2) 当前的度量 m，以及(3)当前的奖励值 r。在接收到一个新的数据时，CDBTune 首先通过比较当前、之前的和初始目标值来计算奖励。训练时从 memory 中获取一个小批量排名靠前的 tuple，并通过反向传播更新 actor 和 critic 的权重。最后，CDBTune 将当前度量 m 输入 actor 以获得下一旋钮 k_next 的推荐。

论文对 CDBTune 的 DDPG 算法进行了一些优化，以提高 DDPG 的收敛速度（新方法被叫做 DDPG++）。首先，DDPG++ 使用即时奖励而不是累积的未来奖励作为 Q 值。第二点，DDPG++ 使用了一个更简单的奖励函数，不考虑之前的或基础目标值。第三点，DDPG++ 在得到一个新的结果时，从 replay memory 中获取多个小批量，以训练网络更快地收敛。

（三）实验结果

第一个实验评估了由 DBA 选出旋钮后再由 ML 调优算法在增加调优的旋钮数量时生成的配置的质量。图 4 显示了算法生成的优化配置在三个 vm 上的平均性能改进。（每个条的暗和亮部分分别代表每个算法的最小和最大性能）。

图4 DBA选出的调优旋钮

为了理解为什么配置执行起来效果不同，作者手动检查了每个旋钮配置，并确定了三个最重要的 Oracle 旋钮，当算法没有正确设置它们时，会对 DB Time 产生最大的影响。其中前两个参数控制 DBMS 的主缓冲区缓存的大小，第三个旋钮启用基于 Oracle 版本的优化器特性。

作者发现，GPR 在四个算法中总是快速收敛，但是 GPR 很容易陷入局部极小值。DNN 的性能是整体最好的，而 DDPG 和 DDPG++需要更多的迭代次数才能达到好的优化性能。

第二个实验是将人工完全排除在调优过程中。首先为了生成旋钮列表排序，使用Lasso 算法，根据旋钮对目标函数的估计影响程度对其进行排序，并将排序列表分为 10knobs 和 20knobs，以供 ML 算法进行调优。图 5 显示了 10 和 20 个knobs 配置的平均性能改进。

图5 OtterTune选出的调优旋钮

论文中认为，20knobs 配置的 DBMS 整体性能较差，部分原因是在 2020 年 8 月初作者进行这些实验时，私有云存储上存在更多的共享噪声，论文中对性能测量的可变性支持了这一解释。

第三个实验，作者先在一个工作负载上训练 ML 生成的模型，然后使用模型去调优另一个工作负载的 DBMS，分析另一工作负载上由 ML 生成的配置的质量。首先使用 OLTP-Bench 执行的 TPC-C 工作负载为每个算法训练模型。然后使用 TPC-C 训练的模型对 TicketTracker 工作负载上的 DBMS 进行迭代调优。图 6 是算法在每个虚拟机上对 SG 默认配置的性能改进。

图6 对不同工作负载的适应性

CGPTuner: a Contextual Gaussian Process Bandit Approach for the Automatic Tuning of IT Configurations Under Varying Workload Conditions[4]

（一）背景知识

这篇论文做的主要工作跟上一篇有些类似，都是为了找到 DBMS 中能够提升系统性能的配置，不同的是这篇论文首先认为 DBMS 处于整个 IT 栈的最顶端，下面的 JVM、操作系统的配置调优也都会影响 DBMS 的性能；第二点，DBMS 的性能还跟它所处的工作负载有关，即这篇论文分析的是实时的、在线的自动调优；论文的第三个亮点是它认为目前软件版本更新的比较快，而且版本更新会修改其可用的参数，那么从以前的知识库中重用信息就让调优的问题变得比较复杂，因此它提出的方法是不需要利用以前的知识库的。

图7 改变MongoDB缓存大小和虚拟机dirty_ratio Linux参数对DBMS性能的影响

图8 改变JVM并发垃圾收集器的线程和Linux内核的read_ahead_kb参数对Cassandra性能的影响

从图 7 和图 8 中可以看到，DBMS、JVM 和 OS 的配置都会影响 DBMS 的性能。

（二）所提模型

图 9 调优过程和架构

论文所提模型的优化目标就是在给定的工作负载 w 下，找到一个配置向量 x，将其应用在 IT 栈上面来优化系统的性能指标 y。需要注意的是，调优器能够利用先前所有迭代的 x,w 和 y，但是不需要其他额外的知识，这点是跟比如 OtterTune 这些需要利用其他知识的自动调优不同的地方。

概率模型：贝叶斯优化

替代模型： 高斯过程

采集函数： GP-Hedge。GP-Hedge 采用了多种获取函数的组合，即EI(预期的改进)、PI(改进概率)、LCB(低置信区间）等。

之所以叫基于上下文的高斯过程优化，是因为作者认为某些工作负载下的优化是相关的，比如工作负载 w 下得到的数据，可能为另一工作负载 w’ 提供一些有用的信息。基于此作者为高斯过程定义了新的正定核和新的协方差函数，作者认为如果两个（x,w）组成的点是相似的只要它们的x是相似的或者 w 是相似。但是在优化的时候，作者只优化了配置空间这一子空间，在每次优化的时候是固定了另一维度进行探索和利用。采用基于上下文的高斯过程优化的好处是在迭代过程中，所有工作负载的信息是共享的。

论文是用 MongoDB 和 Cassandra DBMS 来评估 CGPTuner，用了 YCSB 来模拟了三种不同的工作负载模式。实验时的优化目标是在不增加响应时间的前提下最小化内存消耗，来提升部署的效益。作者手动选出了调优的参数，包含 IT 栈不同的组件（DBMS、JVM 和 OS）的参数。为了验证调优器对于工作负载变化的适应能力，论文中设计了两种工作负载模式，分别是对三种不同读写比例工作负载在一天中（也就是 1 次重复）中持续不同的迭代次数。运行的线程数也是变化的，以此来模拟一天中不同的工作负载密度。