导读：该项目意在说明学术研究员如何利用针对科研项目提供AWS (亚马逊网络服务)云计算信用积分来实现他们自己的科学研究突破。

作者 | Dana Van Aken、Andy Pavlo、Geoff Gordon

编译 | AI100

数据库管理系统（DBMSs）是所有数据密集型应用的最重要组成部分。但是由于他们包含了数百个配置“旋钮”，因此很难管理。这些“旋钮”负责控制一些因素，其中包括用于缓冲储存器的内存容量，以及将数据写入存储盘的频率次数。机构和组织会经常雇佣专家来帮助他们协调各项目，但是很多情况下，聘请这些专家花费过高。

为了让每个人，甚至包括那些没有数据库管理相关技术的人，都能轻松地配置DBMS，卡耐基梅隆大学的学生和研究员共同开发的新工具OtterTune，它可以自动为数据库管理系统（简称DBMS）的配置手册找到匹配的设置。OtterTune和其他DBMS配置工具的不同之处在于它能够运用之前调整DBMS部署时所得到的知识，这明显减少了调整新的DBMS部署所需的时间和资源。因此，OtterTune保留了从以前的调优会话收集的调优数据，它使用这些数据来构建机器学习（ML）模型来抓取DBMS对于不同配置的响应。OtterTune使用这些模型指导新应用程序的实验，从而推荐使用改进特定目标（比如缩短、延迟或提高吞吐量）的设置。

在这篇博客中，我们讨论了OtterTune的机器学习管道中的每个组件，并展示了它们如何相互交互以调整优化DBMS的配置。之后，我们通过将其最佳配置的性能表现与数据库管理员（DBA）和其他自动调整工具所选择的配置进行比较，来评估OtterTune对MySQL和Postgres的调优效率。

OtterTune是由卡内基梅隆数据库研究组的学生和研究员开发的开源工具。 所有代码均可在GitHub上使用，并且已获得Apache License 2.0许可。

获取OtterTune代码：https://github.com/cmu-db/ottertune

OtterTune工作原理

下图显示了OtterTune的组成零件以及工作流程。

在新的调优会话开始时，用户告诉OtterTune要优化的特定目标（比如延迟或吞吐量）。客户端控制器连接到目标DBMS上并收集其Amazon EC2实例类型和当前配置的相关信息。

然后，控制器开始其第一个观察阶段，在此期间它观察DBMS并记录特定目标。当观察结束时，控制器从DBMS收集内部指标，比如MySQL的用于记录从磁盘读取以及写入磁盘的页面的计数器。控制器会将目标性目标和内部指标都返还给调优管理器。

当OtterTune的调优管理器收到指标时，它将这些指标存储在其存储库中。 OtterTune会使用这些结果来计算控制器应该在目标DBMS上安装的下一个配置。调优管理器将此配置返回给控制器，并对运行它的预期改进作出预估。用户可以决定是继续还是终止调优会话。

注意：

OtterTune为其支持的每个DBMS版本保留一个旋钮的黑名单。黑名单包括无法调整的旋钮（例如，DBMS存储文件的路径名称），或是那些可能具有严重或潜在后果（例如，潜在地导致DBMS丢失数据）的旋钮。在每个调优会话开始时，OtterTune为用户提供黑名单，以便他可以添加其他任何需要OtterTune避免调优的旋钮。

OtterTune提出某些假设，这些假设可能会限制一些可用性。例如，它假设用户具有允许控制器修改DBMS配置的管理权限。如果用户没有这些管理权限，那么他就可以在其它硬件上部署数据库的第二个副本来进行OtterTune的调优实验。这要求用户重播工作负载跟踪或转发来自生产级DBMS的查询。有关假设和限制的完整讨论，请参考我们的论文。

论文链接：

http://db.cs.cmu.edu/papers/2017/tuning-sigmod2017.pdf

机器学习管道

下图显示了当数据通过OtterTune的机器学习管道时它是如何处理的。所有观察都保留在OtterTune的存储库中。

OtterTune首先将观察结果传递到Workload Characterization组件中。 该组件识别一组较小的DBMS度量指标，这组指标可以最大地捕获性能表现的差异性以及不同工作负载的区别特征。

接下来，旋钮识别组件会生成一份最影响DBMS性能的旋钮排名列表，然后 OtterTune将所有这些信息提交给Automatic Tuner。该组件将目标DBMS的工作负载映射到其数据存储库中最相似的工作负载上，并重新使用此工作负载数据生成更好的配置。

让我们深入了解机器学习管道中的每个组件。

• Workload Characterization：OtterTune使用DBMS的内部运行时的度量指标来描述工作负载的行为特点。这些指标提供了工作负载的准确表现形式，因为它们抓取了其运行时行为的许多特征。然而，许多度量指标都是多余累赘的：一些是在不同单元中记录的相同测量，而其他指标代表DBMS的独立组件，它们的值都是高度相关的。删除多余的度量指标是非重要，因为这会降低使用它们的机器学习模型的复杂性。所以，我们根据其相关性模型对DBMS的度量指标进行汇总分类。 然后，我们从每个集群中选择一个代表度量指标，特别是那些最靠近集群中心的度量指标。机器学习管道中的后续组件都会使用这些度量指标。

• Knob Identification：DBMS有数百个旋钮，但只有一小拨旋钮会影响DBMS的性能表现。OtterTune使用流行的特征选择技术Lasso来确定哪个旋钮最能影响系统的整体性能表现。根据将该技术应用于其存储库的数据，OtterTune就能给DBMS旋钮的重要性排序。

然后，OtterTune必须决定在进行配置推荐时要使用多少个旋钮。使用太多会明显增加OtterTune的调优时间。使用太少则可能会阻止OtterTune找到最佳配置。为了将此过程自动化，OtterTune使用增量方法。它会逐渐增加调优会话中使用的旋钮数量。这种方法能够让OtterTune在考虑其他拓展范围之前，寻找并优化其中一小部分最重要的旋钮配置。

• Automatic Tuner：该组件通过每个观察期之后执行的两步分析法来确定OtterTune应该推荐的配置。

首先，系统使用Workload Characterization组件中标识的度量指标性能数据，从先前调优会话中识别出最能表示目标DBMS工作负载的工作负载。它将会话指标与先前工作负载的指标进行比较，以确定哪些指标与不同的旋钮设置相似。

然后，OtterTune会选择尝试另一种旋钮配置。它使统计模型适用于两类数据，它所收集到的和存储库中最相似的工作负载的数据。这个模型让OtterTune预测DBMS在每个可能的配置中会出现的执行程度。 OtterTune会继续优化下一个配置，用搜索代替开发（即用“收集信息来改进模型”来取代“目标度量指标上做好即可”）。

实现

OtterTune是用Python编写的。

对于Workload Characterization 与 Knob Identification 组件而言，运行性能不是关键问题，于是我们可以用 scikit-learn 来实现相应的机器学习算法。这些算法一般在后台进程运行，并在OtterTune存储库中使用新的数据。

对 Automatic Tuner 组件来说，机器学习算法处在关键路径上。每个观察周期结束，它们都会运行起来，以合并新数据，使得 OtterTune 可以选择下一个配置来作尝试。此处需要考虑性能，我们就用 TensorFlow 来实现这些算法。

为收集 DBMS 硬件信息、配置数据和运行时的性能指标，我们将 OtterTune 控制器与 OLTP-Bench 基准测试框架集成到了一起。

实验设计

为了方便评估，我们用 OtterTune 所选的最佳配置来对比 MySQL、Postgres 的下述性能表现：

• 默认配置：DBMS 默认配置

• 调优脚本：由开源调优工具所生成的配置

• DBA：DBA 专家手工选出的配置

• RDS：由 Amazon 研发部门定制并部署在同一 EC2 实例上的 DBMS 配置

我们是在 Amazon EC2 Spot Instances 上进行的所有实验。我们使用两个实例来运行每一个实验：一个用于 OtterTune 控制器，一个用于目标 DBMS 部署。所用的实例类型分别是 m4.large 与 m3.xlarge。我们另用一个 128 GB 内存的 20 核心本地服务器来部署 OtterTune 调优管理器和数据存储库。

工作负载采用的是评估 OLTP 性能的行业标准 TPC-C。

结果评估

我们在实验中测试的是 MySQL 与 Postgres 的延迟和吞吐量。结果对比如下图所示：

其中，左侧图表显示的是第99百分图上的延迟，表示“最糟状况”下的事务处理所需时间。右侧图表显示的是吞吐量对比结果，以每秒完成的事务处理平均数来衡量。

MySQL 结果

相比于 MySQL 的调优脚本与 RDS 配置，OtterTune 所生成的最佳配置在延迟上能降低约60％，吞吐量方面则有 22％-35％ 的提升。而对于 DBA 专家的手工配置，OtterTune 在表现上几乎一致。

能显著影响 TPC-C 负载性能的 MySQL 的选项只有少数几个。OtterTune 和 DBA 专家所给出的配置均可作为每个选项的良好设定。RDS 配置表现较差的原因，是它并非是给所有选项都提供了最优配置。调优脚本表现最差的原因是它仅修改了一个选项。

Postgres 结果

相比于 Postgres 的默认配置，OtterTune 与调优脚本、DBA 专家、RDS 在延迟方面的表现大体相近，这可能是 OLTP-Bench 客户端和 DBMS 间网络通讯所需的时间消耗较大。但吞吐量方面，OtterTune 的表现要比 DBA 专家与调优脚本的效果高 12%，更比 RDS 的效果高 32％。

同 MySQL 类似，能显著影响 Postgres 性能的选项也仅有几个。而且，OtterTune、DBA、调优脚本与 RDS 均能修改这些选项，且都能给出相当不错的配置。

结论

自动化数据库管理系统的调优过程，OtterTune 的最大优势，是不需要生成用于训练机器学习模型的初始数据集，可大大降低调优时间。因为它的 DBMS 调优和部署，是重用先前阶段所收集下来的训练数据。

下一步是什么？为了适应日益普遍的 DBaaS 部署，需要远程访问的 DBMS 主机将日渐淘汰，OtterTune 很快也将无需远程访问便能自动检测目标 DBMS 的硬件功能。

有关 OtterTune 的更多信息，请参阅我们的论文或 GitHub 代码库。通过这个网站 http://ottertune.cs.cmu.edu/ ，OtterTune 很快将成为一项在线的调优服务。

原文地址

https://aws.amazon.com/cn/blogs/ai/tuning-your-dbms-automatically-with-machine-learning/