编者按
本文系北京理工大学科研助理牛颂登所著，本篇也是「 OceanBase 学术加油站」系列稿件第八篇。
「牛颂登：北京理工大学科研助理。硕士期间在电子科技大学网络空间安全研究院从事聚类和强化学习相关算法研究，在应用聚类研究个性化在线学习和强化学习的奖励函数设计方向取得了一定成果，目前研究方向为机器学习和数据库相结合的领域。」
本文以 VLDB 2021 的三篇 database tuning 论文为例，对机器学习应用在数据库调优领域的前沿工作做了总结和概述。希望阅读完本文，你可以对“database tuning”有新的认识，有什么疑问也可以在底部留言探讨。
现代数据库管理系统(database management systems，下简称 DBMS)公开了许多可配置的控制运行时行为的旋钮。正确选择 DBMS 的配置对于提高系统性能和降低成本至关重要。但是由于 DBMS 的复杂性，调优 DBMS 通常需要有经验的数据库管理员(database administrators，简称 DBAs)付出相当大的努力。最近关于使用机器学习(Machine Learning，ML)的自动调优方法的研究表明，与专业 DBA 相比，基于 ML 的自动调优方法获得了更好的性能。
（一）调优过程
为了更好地理解 DBMS 的配置调优，探究在真实的企业级 DBMS 上 ML 调优方法的效果，论文通过运行在具有非本地存储的虚拟计算设施上的 Oracle DBMS 实例来比较企业数据库真实工作负载跟踪下的三种 ML 算法（GPR、DNN、DDPG）的调优效果。
论文的主要工作主要是扩展了 OtterTune 调优服务来支持三种 ML 调优算法，并提出了对三种算法的优化，在实验的过程中发现了一些自动调优技术领域中被忽略的部署和度量问题。
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 数据库和工作负载的五个副本。
（二）调优算法
论文中的 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 还在旋钮推荐步骤期间将高斯噪声添加到神经网络的参数中，以控制探索和利用。
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 上的平均性能改进。（每个条的暗和亮部分分别代表每个算法的最小和最大性能）。
为了理解为什么配置执行起来效果不同，作者手动检查了每个旋钮配置，并确定了三个最重要的 Oracle 旋钮，当算法没有正确设置它们时，会对 DB Time 产生最大的影响。其中前两个参数控制 DBMS 的主缓冲区缓存的大小，第三个旋钮启用基于 Oracle 版本的优化器特性。
作者发现，GPR 在四个算法中总是快速收敛，但是 GPR 很容易陷入局部极小值。DNN 的性能是整体最好的，而 DDPG 和 DDPG++需要更多的迭代次数才能达到好的优化性能。
第二个实验是将人工完全排除在调优过程中。首先为了生成旋钮列表排序，使用Lasso 算法，根据旋钮对目标函数的估计影响程度对其进行排序，并将排序列表分为 10knobs 和 20knobs，以供 ML 算法进行调优。图 5 显示了 10 和 20 个knobs 配置的平均性能改进。
论文中认为，20knobs 配置的 DBMS 整体性能较差，部分原因是在 2020 年 8 月初作者进行这些实验时，私有云存储上存在更多的共享噪声，论文中对性能测量的可变性支持了这一解释。
第三个实验，作者先在一个工作负载上训练 ML 生成的模型，然后使用模型去调优另一个工作负载的 DBMS，分析另一工作负载上由 ML 生成的配置的质量。首先使用 OLTP-Bench 执行的 TPC-C 工作负载为每个算法训练模型。然后使用 TPC-C 训练的模型对 TicketTracker 工作负载上的 DBMS 进行迭代调优。图 6 是算法在每个虚拟机上对 SG 默认配置的性能改进。
（一）背景知识
这篇论文做的主要工作跟上一篇有些类似，都是为了找到 DBMS 中能够提升系统性能的配置，不同的是这篇论文首先认为 DBMS 处于整个 IT 栈的最顶端，下面的 JVM、操作系统的配置调优也都会影响 DBMS 的性能；第二点，DBMS 的性能还跟它所处的工作负载有关，即这篇论文分析的是实时的、在线的自动调优；论文的第三个亮点是它认为目前软件版本更新的比较快，而且版本更新会修改其可用的参数，那么从以前的知识库中重用信息就让调优的问题变得比较复杂，因此它提出的方法是不需要利用以前的知识库的。
从图 7 和图 8 中可以看到，DBMS、JVM 和 OS 的配置都会影响 DBMS 的性能。
（二）所提模型
论文所提模型的优化目标就是在给定的工作负载 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 次重复）中持续不同的迭代次数。运行的线程数也是变化的，以此来模拟一天中不同的工作负载密度。
（三）实验结果
在实验时，作者通过两种方式来比较不同调优器的度量，一种是以在线的，也就是让调优器直接在生产系统上运行，另一种是离线的，在测试环境上复制生产系统。
作者用了两个指标来衡量这两种方式下的调优器的质量，分别是在线调优的累计奖励 Calculative Reward（CR）和离线调优的迭代最佳值 Iterative Best（IB）。如果保持跟默认配置相同的配置，CR 将始终是 0，如果找到的配置比默认配置还差，将会导致负的 CR。也就是说，CR 反映了调优器理解问题和适应工作负载变化的能力。IB 值记录了当前迭代下记录的最高的标准性能改进，它反映了调优器快速探索并且找到良好配置的能力。
图 10 是加载单峰的工作负载的结果，从 IB 值得变化可以看到 CGP 相较于另外两种在线调优算法，能更快找到良好的配置，并且找到的配置质量高于另外两种算法；从 CR 值的变化情况可以看到，OpenTuner 和 BestConfig 的累计奖励值在持续地负向增加，也就是说这两种算法找的配置始终比默认的设置更差，而 CGPTuner 在第 3 天开始 CR 值开始正向增加，并且在第六天累计奖励的值开始为正值并不断增加；在另一种工作负载模式上的结果类似。
除了从优化的角度比较了各种算法外，作者还从吞吐量和内存消耗的角度来比较了三种算法。图 11 中的点是 Cassandra DBMS 在单峰工作负载模式上每个调优器获得的中值。可以看到，在调优的第二天，CGP 已经基本上收敛，它为 Cassandra 缓存设置了一个较低的值，并根据传入的工作负载改变了 JVM 堆的大小，而且这两个参数都非常接近于最佳配置。而 OpenTuner 和 BestConfig 都没有达到收敛，始终为这两个内存参数寻找更高的值。至于吞吐量方面，CGP 在大多数工作负载上都能获得更好的结果。
综上，基于上下文的调优器能实现更高吞吐量的同时分配更少的内存，同时能根据到来的工作负载变化 JVM 堆的尺寸。
（一）背景知识
本篇论文认为从文本文档中挖掘提示可以为现在的自动调优方法如主动学习、DRL 等加速收敛，以及减少训练所需的数据量，作为这些方法的补充。数据库调优知识是以自然语言文本的形式提供的。例如，数据库管理员在最大限度地提高不熟悉的系统的性能时，都会首先查阅数据库系统手册。除了手册之外，在网络上的博客、在线论坛或科学论文中还发布了无数的调优提示。相关知识不仅隐藏在文本文档中。甚至配置文件中调优参数的名称以及相关的注释，可能也提供了一些直观的语义和值得尝试的值。
（二）所提模型
以 Postgres 和 MySQL 的手册为例，可以提取出这些关键语句和上下文。例如第一条语句，（满足条件 RAM 的内存大于 1GB 时）可以将其转换为等式 shared_buffers = ¼ memory。
接下来，使用 Robert-a 的分类器根据关键语句的类型对其进行分类，这里假设的是每个提示都可以被转换成一个涉及所引用参数的等式。语句按类型分为建议参数为特定值的提示、定义下限、上限或推荐值集合的提示。然后根据分类后的关键语句，提取参数名称和提示的值。最后对不同文档提取出的提示进行汇总，为了减少噪声和剔除相矛盾的属性，论文最终用到的提示是过滤后的，至少在独立的文档中出现两次的调优提示。
这篇论文相比前两篇配置调优的论文，有一些缺点，就是所提原型的文本分析不支持不同工作负载下的调优；另外，仅支持提取特定的参数值以及主内存的百分比，对于参数值范围的提取不适用。
（三）实验结果
为了使任务更具挑战性，论文使用提示为一个数据库系统训练两个分类器，用来自一个分类器的文档训练分类器，并处理为另一个系统检索的所有文档，即在以另一个系统为目标的文档上测试用第一个系统的数据训练的分类器。
综上，该论文建议使用文本文档和片段作为数据库调优中的一个额外的信息源，提出并评估了一个 NLP 增强型数据库调优器的简单原型来利用这些信息作为补充或证实其他信息源，并演示了与默认配置相比，自动解析来自Web的信息可以产生显著的加速。
本文通过三篇数据库调优相关论文对其各自工作进行概述，希望能在带给读者相关概念的同时，启发创新灵感。由于篇幅所限，本文并未列出所有数据库调优相关论文，而只是以近年论文为起点，给出些大致的研究方向，感兴趣的读者还需要在此基础上继续探索。
