概述

最近几年，特别是随着云计算的发展，出现了行业向后重叠和推动的情况。数据库龙头企业Oracle最近几年重点转而向云的变革，它全力以赴在做的一件事情就是把所有的产品和服务转移到云上来。云技术改变了数据库领领域的竞争格局，而云时代的DBA，则面临着自后向前置的运维变化。

在开始一轮新的调节会话时，用户首先需要告知 OtterTune 此番优化的具体目标（例如面向延迟抑或数据吞吐量）。其客户端控制器将接入目标 DBMS 并收集其 Amazon EC2 实例类型与当前配置等相关信息。

在此之后，该控制器会开始第一轮观察周期，在此期间其将观察 DBMS 以及与既定目标相关之各项记录。在此轮观察周期结束后，控制器将从 DBMS 当中收集各类内部指标，例如 MySQL 自磁盘处读取之页面以及向磁盘中写入之页面计数。该控制器随后会将目标信息与内部指标发送回调节管理器当中。

当 OtterTune 的调节管理器接收到这些指标后，其会将相关数据存储在自有存储库内。OtterTune 利用这些结果计算出控制器应在目标 DBMS 上安装的下一套配置方案。具体配置方案由调节管理器交付至控制器处，同时确定运行后的预期改进效果。这时，用户即可决定继续抑或中止当前调节会话。

OtterTune 为其支持的每个 DBMS 版本皆设立有一套调节黑名单。此份黑名单中囊括了各类无法调整的项目（例如 DBMS 存储文件的路径名称）或者可能引发严重乃至隐藏后果的选项（例如可能导致 DBMS 遭遇潜在数据丢失）。每开始一项调节会话时，OtterTune 即可弹出黑名单提示，用以提醒用户添加各项不希望由 OtterTune 进行调节的具体条目。

机器学习管道

将 OtterTune 所生成的最佳配置与 Tuning 以及 RDS 相关配置进行比较可以发现，MySQL 在延迟水平方面降低了约 60%，而数据吞吐量则在 OtterTune 配置的帮助下提升 22% 到 35% 之间。与此同时，OtterTune 的生成的配置方案在实际效果上与人类数据库管理员几乎不相上下。

Postgres 测试结果

在延迟方面，OtterTune、调节工具、数据库管理员以及 RDS 所给出的配置建议全部优于 Postgres 的默认设置，且提升效果基本类似。我们可以将这一结果归结于 OLTP-Bench 客户端与 DBMS 之间的往返路由造成了巨大的性能影响。在数据吞吐量方面，Postgres 在使用 OtterTune 建议配置时，实际效果较数据库管理员及 Tuning 配置选项大约提升 12%，而与 RDS 间的比较优势更是达到 32%。
与 MySQL 类似，只有少数几个调节选项会对 Postgres 性能产生显著影响。OtterTune、数据库管理员、Tuning 以及 RDS 所生成的配置都对这些条目进行了修改，且其中多数能够带来相当不错的设置效果。

总结

OtterTune 能够以自动化方式为 DBMS 各配置选项找到良好的设置方式。为了对新的 DBMS 部署系统进行调整，OtterTune 会使用以往调优会话当中收集到的训练数据。由于 OtterTune 并不需要在每次生成操作当中再次利用初始数据集进行机器学习模型训练，因此整个调节时间周期得到大幅缩减。

文章知识点与官方知识档案匹配，可进一步学习相关知识MySQL入门技能树首页概览31842 人正在系统学习中