接下来，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的结果