亚马逊AWS官方博客
通过机器学习自动优化 DBMS
本客座文章由卡内基梅隆大学的 Dana Van Aken、Geoff Gordon 和 Andy Pavlo 发布。本项目演示学术研究人员如何利用我们的 AWS Cloud Credits for Research Program 实现科学突破。点击：原文链接
数据库管理系统 (DBMS) 是所有数据密集型应用程序最重要的组成部分。它们可以处理大量数据和复杂工作负载。但它们拥有成百上千的配置“开关”，控制了诸如用于缓存的内存量以及将数据写入存储的频率等诸多因素，因此管理起来很困难。组织通常会聘请专家来帮助完成优化活动，但对许多组织来说专家的费用过于高昂。
卡内基梅隆大学数据库研究组的学生和研究人员开发了一款新工具 OtterTune，它可以针对 DBMS 配置开关自动查找较佳的设置。其目标是让每个人都可以轻松部署 DBMS，即使是毫无数据库管理专业知识的人。
与其他 DBMS 配置工具不同，OtterTune 利用在优化之前的 DBMS 部署期间获得的知识来优化新的部署。这可以显著缩短优化新 DBMS 部署所需的时间以及减少所需的资源。为此，OtterTune 维护了一个存储库，用于存储在之前的优化会话中收集的优化数据。它利用此类数据来构建机器学习 (ML) 模型，以捕获 DBMS 对不同配置的响应方式。OtterTune 使用这些模型来指导新应用程序的试验，进而推荐可改善最终目标 (例如，减少延迟或提高吞吐量) 的设置。
在本文中，我们将讨论 OtterTune ML 管道中的每一个组件，并演示这些组件如何彼此交互以优化 DBMS 配置。然后，我们将通过比较 OtterTune 推荐的最佳配置与数据库管理员 (DBA) 及其他自动优化工具选择的配置的性能，评估 OtterTune 对 MySQL 和 Postgres 的优化效力。
OtterTune 是一款开源工具，由卡内基梅隆大学数据库研究组的学生和研究人员开发。GitHub 上提供了所有代码，并且代码已获得 Apache 2.0 许可。
OtterTune 工作原理
下图显示了 OtterTune 的组件和工作流。
在新的优化会话开始时，用户须告知 OtterTune 要优化的最终目标 (例如，延迟或吞吐量)。客户端控制器连接到目标 DBMS，并收集其 Amazon EC2 实例类型和当前配置。
然后，控制器开始第一个观察期，观察 DBMS 并记录最终目标。该观察期结束后，控制器收集 DBMS 中的内部指标，例如，MySQL 从磁盘读取的页数以及写入磁盘的页数。控制器向优化管理器返回最终目标和内部指标。
OtterTune 的优化管理器收到指标时，将指标存储在存储库中。OtterTune 根据结果计算控制器应在目标 DBMS 上安装的下一个配置。优化管理器向控制器返回此配置，并估计优化此配置能够获得的预期改进。用户可以决定是继续还是终止优化会话。
备注
OtterTune 维护其支持的各 DBMS 版本的开关黑名单。该黑名单中包含无优化意义的开关 (例如，DBMS 存储文件的路径名称)，或者可能导致严重或隐藏后果 (例如，可能导致 DBMS 丢失数据) 的开关。每个优化会话开始时，OtterTune 会向用户提供该黑名单，让用户添加他们不希望 OtterTune 优化的任何其他开关。
OtterTune 做出了一些假设，这些假设可能会限制其对某些用户的有用程度。例如，它假设用户拥有管理权限，允许控制器修改 DBMS 的配置。如果用户不具备该权限，则可以在其他硬件上部署另外一份数据库，用于进行 OtterTune 优化试验。这要求用户重播工作负载跟踪或转发来自生产 DBMS 的查询。有关假设和限制的完整讨论，请参阅我们的文章。
机器学习管道
下图显示了在数据流过 OtterTune 的 ML 管道时如何得到处理。所有观察结果都保存在 OtterTune 的存储库中。
OtterTune 先将观察结果传入 Workload Characterization 组件。此组件确定能够最准确地捕获不同工作负载的性能差异和显著特点的一小部分 DBMS 指标。
接下来，Knob Identification 组件生成对 DBMS 性能影响最大的开关的排序列表。OtterTune 随后将所有此类信息馈送到 Automatic Tuner。此组件将目标 DBMS 工作负载映射到其数据存储库中最相似的工作负载，并再次使用此工作负载数据生成更好的配置。
我们来详细讨论一下 ML 管道中的每个组件。
Workload Characterization： OtterTune 使用 DBMS 的内部运行时指标来确定工作负载行为方式的特征。这些指标准确代表了工作负载，因为它们捕获了其运行时行为的许多方面。不过，许多指标都是多余的：一些指标其实是相同的，只是单位不同；还有一些指标表示 DBMS 的各独立组件，但它们的值高度相关。必须清除多余的指标，这可以降低使用这些指标的 ML 模型的复杂性。为此，我们基于 DBMS 指标的关联模式将它们集群化。然后，我们从每个集群中选择一个具有代表性的指标，具体而言就是最接近集群中心的指标。ML 管道中的后续组件会使用这些指标。
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 来实现对应的 ML 算法。这些算法在后台进程中运行，从而在 OtterTune 存储库中有新数据可用时纳入这些数据。
而对于 Automatic Tuner，ML 算法是关键。它们在每个观察期之后运行，从而纳入新数据，以便 OtterTune 能够选取下一次尝试的开关配置。由于要考虑性能，我们使用 TensorFlow 来实现这些算法。
为了收集有关 DBMS 硬件、开关配置和运行时性能指标的数据，我们将 OtterTune 的控制器与 OLTP-Bench 基准测试框架集成在了一起。
试验设计
为进行评估，我们比较了使用 OtterTune 选择的最佳配置与使用以下配置的 MySQL 和 Postgres 的性能：
- 默认：DBMS 提供的配置
- 优化脚本：开源优化顾问工具生成的配置
- DBA：DBA 选择的配置
- RDS：由 Amazon RD 管理并部署在相同 EC2 实例类型上的 DBMS 的自定义配置
我们在 Amazon EC2 竞价型实例上进行了所有试验。我们在两个实例上运行了每个试验：一个针对 OtterTune 控制器，另一个针对目标 DBMS 部署。我们分别使用了 m4.large 和 m3.xlarge 实例类型。我们在配备 20 个内核和 128 GB RAM 的本地计算机上部署了 OtterTune 的优化管理器和数据存储库。
我们使用了 TPC-C 工作负载，它是评估联机事务处理 (OLTP) 系统性能的行业标准。
评估
对于我们在试验中使用的每个数据库 (MySQL 和 Postgres)，我们测量了延迟和吞吐量。下图显示了结果。第一张图显示 99% 的延迟，表示最坏情况下完成事务的时间。第二张图显示吞吐量结果，以每秒完成的平均事务数衡量。
MySQL 结果
比较 OtterTune 生成的最佳配置与优化脚本和 RDS 生成的配置后发现，使用 OtterTune 配置，MySQL 的延迟减少了大约 60%，吞吐量提高了 22%-35%。OtterTune 还生成了几乎与 DBA 选择的配置一样出色的配置。
只有少数几个 MySQL 开关显著影响 TPC-C 工作负载的性能。OtterTune 和 DBA 生成的配置为每个这些开关提供了理想的设置。RDS 的表现稍差一些，因为它为一个开关提供了次优的设置。优化脚本的配置效果最差，因为它只修改了一个开关。
Postgres 结果
在延迟方面，与 Postgres 的默认设置相比，优化工具 OtterTune、DBA 和 RDS 生成的配置全都获得了类似的改善。我们或许可以把这些改善归功于 OLTP-Bench 客户端与 DBMS 之间的网络往返行程所需的开销。在吞吐量方面，与 DBA 和优化脚本选择的配置相比，OtterTune 建议的配置使 Postgres 的吞吐量提高了大约 12%，与 RDS 相比，提高了大约 32%。
与 MySQL 类似，只有少数几个开关显著影响 Postgres 的性能。OtterTune、DBA、优化脚本以及 RDS 生成的配置全都修改了这些开关，并且大部分提供了非常理想的设置。
结论
OtterTune 可自动完成为 DBMS 的配置开关寻找理想设置的过程。为优化新的 DBMS 部署，它会再次使用之前优化会话中收集的训练数据。由于 OtterTune 不需要生成初始数据集即可训练其 ML 模型，因此优化时间明显缩短。
接下来做什么？为适应 DBaaS 部署 (无法远程访问 DBMS 主机计算机) 的日益普及，OtterTune 将很快能够在无需远程访问的情况下，自动检测目标 DBMS 的硬件功能。
有关 OtterTune 的更多详细信息，请参阅我们的文章或 GitHub 上的代码。请密切关注本网站，我们即将在网站中提供 OtterTune 作为联机优化服务。
作者简介
Dana Van Aken 是卡内基梅隆大学计算机科学系的博士生，由 Andrew Pavlo 博士指导。她的主要研究课题是数据库管理系统。她目前的工作重点是开发自动化技术以使用机器学习来优化数据库管理系统。
Andy Pavlo 博士是卡内基梅隆大学计算机科学系数据库学科的助理教授，也是卡内基梅隆大学数据库研究组和并行数据实验室的一名成员。他的工作还需要与英特尔大数据科技中心协作。
Geoff Gordon 博士是卡内基梅隆大学机器学习系的副教授兼副教导主任。他的研究课题包括人工智能、统计机器学习、教育数据、游戏理论、多机器人系统，以及概率域、对立域和常规求和域的规划。
本文首发于亚马逊AWS官方博客网站，原创文章如转载，请注明出处。