编者按

本文系北京理工大学科研助理牛颂登所著，本篇也是「 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 次反复）中继续不同的迭代次数。运行的线程数也是变动的，以此来模仿一天中不同的工作负载密度。

 

（三）试验后果

 

在试验时，作者通过两种形式来比拟不同调优器的度量，一种是以在线的，也就是让调优器间接在生产零碎上运行，另一种是离线的，在测试环境上复制生产零碎。

作者用了两个指标来掂量这两种形式下的调优器的品质，别离是在线调优的累计处分 Calculative Reward（CR）和离线调优的迭代最佳值 Iterative Best（IB）。如果放弃跟默认配置雷同的配置，CR 将始终是 0，如果找到的配置比默认配置还差，将会导致负的 CR。也就是说，CR 反映了调优器了解问题和适应工作负载变动的能力。IB 值记录了以后迭代下记录的最高的规范性能改良，它反映了调优器疾速摸索并且找到良好配置的能力。

 

图10 在Cassandra DBMS上运行单峰workload模式

 

图 10 是加载单峰的工作负载的后果，从 IB 值得变动能够看到 CGP 相较于另外两种在线调优算法，能更快找到良好的配置，并且找到的配置品质高于另外两种算法；从 CR 值的变动状况能够看到，OpenTuner 和 BestConfig 的累计处分值在继续地负向减少，也就是说这两种算法找的配置始终比默认的设置更差，而 CGPTuner 在第 3 天开始 CR 值开始正向减少，并且在第六天累计处分的值开始为正值并一直减少；在另一种工作负载模式上的后果相似。

 

图 11 Cassandra 单峰调优的非标准化内存和吞吐量

 

除了从优化的角度比拟了各种算法外，作者还从吞吐量和内存耗费的角度来比拟了三种算法。图 11 中的点是 Cassandra DBMS 在单峰工作负载模式上每个调优器取得的中值。能够看到，在调优的第二天，CGP 曾经基本上收敛，它为 Cassandra 缓存设置了一个较低的值，并依据传入的工作负载扭转了 JVM 堆的大小，而且这两个参数都十分靠近于最佳配置。而 OpenTuner 和 BestConfig 都没有达到收敛，始终为这两个内存参数寻找更高的值。至于吞吐量方面，CGP 在大多数工作负载上都能取得更好的后果。

综上，基于上下文的调优器能实现更高吞吐量的同时调配更少的内存，同时能依据到来的工作负载变动 JVM 堆的尺寸。

 

The Case for NLP-Enhanced Database Tuning: Towards Tuning Tools that “Read the Manual”[5]

 

（一）背景常识

 

本篇论文认为从文本文档中开掘提醒能够为当初的主动调优办法如被动学习、DRL 等减速收敛，以及缩小训练所需的数据量，作为这些办法的补充。数据库调优常识是以自然语言文本的模式提供的。例如，数据库管理员在最大限度地进步不相熟的零碎的性能时，都会首先查阅数据库系统手册。除了手册之外，在网络上的博客、在线论坛或科学论文中还公布了有数的调优提醒。相干常识不仅暗藏在文本文档中。甚至配置文件中调优参数的名称以及相干的正文，可能也提供了一些直观的语义和值得尝试的值。

 

（二）所提模型

 

图12 NLP加强的数据库调优器

 

图 12 显示了 NLP 增强型数据库调优工具的模板，零碎、数据和查问相干的文本用于造成优化的先验。首先，从零碎手册、网上博客、论坛、关联的正文以及科学论文里抽取出相干常识作为先验文本。而后论文所提的原型零碎能够从输出的先验文本中开掘数据库系统的调优提醒。

 


图13 论文所提原型概述

 

管道的第一阶段首先用基于 Robert-a 语言预处理模型提取出含有倡议特定参数的值或者范畴的要害语句，以及上下文。

 

图14 通过谷歌查问“Postgres数据库调优”和MySQL数据库调优

失去的前十个调优提醒网页文档的子集

 

以 Postgres 和 MySQL 的手册为例，能够提取出这些要害语句和上下文。例如第一条语句，（满足条件 RAM 的内存大于 1GB 时）能够将其转换为等式 shared_buffers = ¼ memory。

接下来，应用 Robert-a 的分类器依据要害语句的类型对其进行分类，这里假如的是每个提醒都能够被转换成一个波及所援用参数的等式。语句按类型分为倡议参数为特定值的提醒、定义上限、下限或推荐值汇合的提醒。而后依据分类后的要害语句，提取参数名称和提醒的值。最初对不同文档提取出的提醒进行汇总，为了缩小噪声和剔除相矛盾的属性，论文最终用到的提醒是过滤后的，至多在独立的文档中呈现两次的调优提醒。

这篇论文相比前两篇配置调优的论文，有一些毛病，就是所提原型的文本剖析不反对不同工作负载下的调优；另外，仅反对提取特定的参数值以及主内存的百分比，对于参数值范畴的提取不实用。

 

（三）试验后果

 

为了使工作更具挑战性，论文应用提醒为一个数据库系统训练两个分类器，用来自一个分类器的文档训练分类器，并解决为另一个零碎检索的所有文档，即在以另一个零碎为指标的文档上测试用第一个零碎的数据训练的分类器。

 


图15 Postgres训练产生提醒后处理MySQL提醒时的品质度量

 

图16 MySQL训练产生提醒后处理Postgres提醒时的品质度量

 

综上，该论文倡议应用文本文档和片段作为数据库调优中的一个额定的信息源，提出并评估了一个 NLP 增强型数据库调优器的简略原型来利用这些信息作为补充或证实其余信息源，并演示了与默认配置相比，主动解析来自Web的信息能够产生显著的减速。

本文通过三篇数据库调优相干论文对其各自工作进行概述，心愿能在带给读者相干概念的同时，启发翻新灵感。因为篇幅所限，本文并未列出所有数据库调优相干论文，而只是以近年论文为终点，给出些大抵的钻研方向，感兴趣的读者还须要在此基础上持续摸索。

 

*参考文献：

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

[2] Black or White? How to Develop an AutoTuner for Memory-based Analytics. SIGMOD, 2020.
[3] An End-to-End Automatic Cloud Database Tuning System Using Deep Reinforcement Learning. ICMD, 2019.

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

[5] The Case for NLP-Enhanced Database Tuning: Towards Tuning Tools that “Read the Manual”. PVLDB, 2021.