共计 4893 个字符，预计需要花费 13 分钟才能阅读完成。
| 导读 | 数据库管理系统（DBMS）是任何数据密集型应用系统中最重要的一个部分。它们可以处理大量的数据和复杂的工作负载。但是由于它们有成百上千个配置“按钮”（knob），这些配置按钮控制着诸多因素，比如用于缓存的内存容量和数据写入到存储设备的频次，因而管理起来很难。企业组织常常聘请专家帮助调优活动，不过对许多企业来说专家的成本高得离谱。 |
本文是由卡内基·梅隆大学的三位嘉宾达娜·范·阿肯（Dana Van Aken）、安迪·帕夫洛（Andy Pavlo）和杰夫·戈登（Geoff Gordon）共同撰写的文章。该项目演示了学术研究人员如何可以使用 AWS Cloud Credits for Research Program（https://aws.amazon.com/research-credits/）来支持其科研突破。
OtterTune 是由卡内基·梅隆大学数据库小组（http://db.cs.cmu.edu/projects/autotune/）的学生和研究人员开发的一种新工具，它能自动为 DBMS 的配置按钮找到合适的设置。目的在于让任何人都更容易部署 DBMS，甚至是数据库管理方面毫无专长的那些人。
OtterTune 有别于其他的 DBMS 配置工具，原因在于它充分利用从调优之前部署的 DBMS 获得的知识来调优新部署的 DBMS。这大大减少了调优新部署的 DBMS 所需要的时间和资源。为此，OtterTune 维护一个资料库，包含从之前的调优会话收集而来的调优数据。它使用该数据来构建机器学习模型，这些模型采集了 DBMS 对不同配置作出反应的信息。OtterTune 使用这些模型来指导用户针对新的应用程序进行尝试，建议使用改善特定目标（比如缩短延迟或提高吞吐量）的设置。
我们在本文中探讨了 OtterTune 的机器学习管道的每个组件，并演示了它们彼此如何联系，从而调优 DBMS 的配置。之后，我们评估了 OtterTune 对 MySQL 和 Postgres 的调优效果：将其最佳配置的性能与数据库管理员（DBA）及其他自动调优工具选择的配置作了一番比较。
OtterTune 是由卡内基·梅隆大学数据库小组的学生和研究人员开发的一种开源工具。所有代码都放在 GitHub 上（https://github.com/cmu-db/ottertune），采用了 Apache License 2.0 这种许可证来发行。
下面这张图显示了 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 度量指标。
接下来，Knob Identification 组件生成一份按钮排序表，列出了对 DBMS 的性能影响最大的按钮。然后，OtterTune 将所有这些信息馈送给 Automatic Tuner。该组件将目标 DBMS 的工作负载与数据资料库中最相似的工作负载对应起来，并重复使用该工作负载数据，生成更合适的配置。
现在不妨深入探究机器学习管道中的每一个组件。
Workload Characterization：OtterTune 使用 DBMS 的内部运行时度量指标来描述工作负载的行为特点。这些度量指标准确地表述了工作负载，因为它们采集了运行时行为的许多方面。然而，许多度量指标是冗余的：一些是以不同单位记录的同一个度量值，另一些表示 DBMS 中数值高度关联的独立部分。精简冗余的度量指标很重要，因为这降低了使用它们的机器学习模型的复杂性。为此，我们基于关联模式，将 DBMS 的度量指标分成聚类（cluster）。然后，我们从每个聚类中选择一个代表性度量指标，具体来说是最靠近聚类中心的那个度量指标。机器学习管道中的后续组件使用这些度量指标。
Knob Identification：DBMS 可能有数百个按钮，但只有一小批按钮影响 DBMS 的性能。OtterTune 使用一种流行的特征选择技术（名为 Lasso），决定哪些按钮显著影响系统的整体性能。通过将这种技术运用于资料库中的数据，OtterTune 可识别 DBMS 的按钮重要性次序。
随后，OtterTune 得决定在建议配置时使用多少个按钮。使用太多的按钮大大增加了 OtterTune 的优化时间。使用太少的按钮又让 OtterTune 无法找到最佳配置。为了使这个过程实现自动化，OtterTune 使用了一种增量方法。它逐步增加用于调优会话中的按钮数量。这种方法让 OtterTune 得以为一小批最重要的按钮探究和优化配置，然后扩大范围、考虑其他按钮。
Automatic Tuner：Automated Tuning 组件通过在每个观察期之后执行分两步走的分析，决定 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 基准测试框架整合起来。
为了评估，我们针对 MySQL 和 Postgres 的性能，将 OtterTune 选择的最佳配置与下列配置进行了比较：
- 默认：DBMS 提供的配置
- 调优脚本：开源调优顾问工具生成的配置
- DBA：数据库管理员生成的配置
- RDS：为 DBMS 定制的配置，由 Amazon RD 管理，部署在同样类型的 EC2 实例上。
我们在 Amazon EC2 Spot Instances（现货实例）上进行了所有的试验。我们在两个实例上进行了每次试验：一个实例用于 OtterTune 的控制器，另一个用于部署的目标 DBMS 系统。我们分别使用了 m4.large 和 m3.xlarge 实例类型。我们将 OtterTune 的调优管理器和数据资料库部署在了搭载 20 个核心、128GB 内存的本地服务器上。
我们使用了 TPC- C 工作负载，这是评估联机事务处理（OLTP）系统性能的行业标准。
针对我们在试验中使用的每个数据库：MySQL 和 Postgres，我们测量了延迟和吞吐量。下面几张图显示了结果。第一张图显示了第 99 个百分位延迟的数量，这表示“在最糟糕情况下”事务完成所花的时间。第二张图显示了吞吐量的结果，以每秒完成的事务平均数量来测量。
MySQL 的结果：
将 OtterTune 生成的最佳配置与调优脚本和 RDS 生成的配置进行比较，就会发现：如果使用 OtterTune 配置，MySQL 的延迟缩短了约 60%，吞吐量提升了 35%。OtterTune 还生成了结果与数据库管理员选择的配置一样好的配置。
少数几个 MySQL 的按钮对 TPC- C 工作负载的性能有重大影响。OtterTune 和数据库管理员生成的配置为这每一个按钮提供了很好的设置。由于为一个按钮提供了未达最佳标准的设置，RDS 的表现要逊色一点。由于只修改了一个按钮，调优脚本的配置表现最差。
Postgres 的结果：
就延迟而言，OtterTune、调优工具、数据库管理和 RDS 生成的配置都比 Postgres 的默认设置有了相似的改进。我们也许可以将这归因于网络上 OLTP-Bench 的客户机和 DBMS 之间的往返所需要的开销。至于吞吐量，如果使用 OtterTune 建议的配置，Postgres 的性能比数据库管理员和调优脚本选择的配置高出了约 12%，比 RDS 更是高出了约 32%。
类似 MySQL，只有少数几个按钮对 Postgres 的性能有重大影响。OtterTune、数据库管理员、调优脚本和 RDS 生成的配置都修改了这些按钮，大多数提供了相当好的设置。
OtterTune 使得为 DBMS 的配置按钮找到合适的设置这个过程实现了自动化。为了调优新部署的 DBMS，它重复使用从之前的调优会话收集而来的训练数据。由于 OtterTune 不需要生成用于训练机器学习模型的初始数据集，因而显著缩短了调优时间。
接下来是什么？为了适应部署的 DBaaS 越来越流行这个形势（无法远程访问 DBMS 的主机系统），OtterTune 很快就能够自动检测目标 DMBS 的硬件功能，而不需要远程访问。
想了解 OtterTune 方面的更多细节，请参阅我们的论文或放在 GitHub 上的代码。敬请关注这个网站（http://ottertune.cs.cmu.edu/），我们很快就会推出 OtterTune 这项在线调优服务。
作者简介：
达娜·范·阿肯（Dana Van Aken）是卡内基·梅隆大学的计算机学博士生，导师是安德鲁·帕夫洛博士。
安迪·帕夫洛（Andy Pavlo）是卡内基·梅隆大学的计算机学系数据库学助理教授。
杰夫·戈登（Geoff Gordon）是卡内基·梅隆大学的副教授兼机器学习系教育部副主任。
