通过大规模机器学习自动调优数据库参数

目录

1. 引言

2. 挑战

3. 系统概览

3.1 举例

3.2 假设和限制

4. 工作负载识别

4.1 统计收集

4.2 修剪冗余监控指标

5. 识别重要的参数

5.1 使用Lasso进行特征选择

5.2 依赖

5.3 增量参数选择

6. 自动调优

6.1 工作负载映射

6.2 配置推荐

7. 实验评估

7.1 工作量

7.2 训练数据收集

7.3 参数数量

7.4 调优评估

7.5 执行时间分解

7.6 功效对比

---

     英文论文地址：

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

数据库管理系统（DBMS）配置优化是任何数据密集型应用程序努力的基本方面。但这在历史上是一项艰巨的任务，因为DBMS有数百个配置参数，控制系统中的一切，比如高速缓存使用的内存量和数据写入存储的频率。这些参数的问题在于它们不标准化（即，两个DBMS相同参数却使用了不同的名称），不独立（即改变一个参数可能影响其他），不通用（适用于一个应用程序，但是对于另一个来说是次优的）。更糟的是，有关这些参数的选取通常只来自宝贵的经验。

       为了克服这些挑战，我们提出了一种自动化方法。利用过去的经验并收集新信息进行调整DBMS配置：我们使用有监督和无监督的组合机器学习方法要（1）选择最有影响力的参数，（2）将看不见的数据库工作负载映射到以前的工作负载，从中我们可以转移经验，（3）推荐参数设置。我们OtterTune工具中实现了我们的技术并在三个DBMS上进行了测试。 我们的评估表明OtterTune建议配置尽可能好或更好与现有工具或人类专家产生的。
 

1. 引言

       收集，处理和分析大量数据的能力对于能够推断出商业新知识至关重要和科学领域。 对于数据密集型（“大数据”）应用程序，DBMS是关键组件。 这些系统的表现通常以诸如此类的指标来衡量吞吐量（例如，它可以多快收集新数据）和延迟（例如，它能够以多快的速度响应请求）。

       在DBMS中实现良好的性能并非易事因为具有许多可调参数几乎可以控制他们运行时操作的各个方面[。 这样的配置参数允许数据库管理员（DBA）控制DBMS的运行时行为。 例如，他们可以设置数据缓存分配的内存相对于事务日志缓冲区。 现代DBMS因拥有许多配置而臭名昭著。 DBMS的如此神秘的一部分原因就在于他们的性能和可扩展性高度依赖在他们的配置上。 进一步加剧了这个问题是这些默认配置是出了名的坏。

       鉴于此，许多组织都在招聘昂贵的专家为预期的工作负载配置系统的参数。但是作为数据库和应用程序在规模和复杂性方面都在增长，满足应用程序需求的DBMS已经超越人类的能力。这是因为配置正确的DBMS高度依赖于许多因素，超出人类可以推理的范围。
        以前尝试使用自动DBMS配置工具有某些缺陷使它们不适合一般用途数据库应用。许多调整工具都是创建的供应商，因此他们只支持该特定公司DBMS 。少数支持的调优工具，多个DBMS仍然需要手动步骤，例如拥有DBA（1）部署数据库的第二个副本，（2）映射参数之间的依赖关系或（3）指导训练过程。所有这些工具还独立检查每个DBMS部署，因此无法应用从以前获得的知识进行调整。这是低效的，因为每个调整工作都可以需要很长时间并且使用大量资源。

       在本文中，我们提出了一种重用训练数据的技术从以前的会话中调整新的DBMS部署。我们方法的关键是培养机器学习（ML）模型从这些先前的调优收集的测量结果，并使用模型要（1）选择最重要的参数，（2）映射看不见的数据库工作负载到已知的工作负载，以便我们可以转移以前的经验，以及（3）推荐参数设置，提高目标（例如，延迟，吞吐量）。重用过去的经验减少了所需的时间和资源为新应用程序调整DBMS。为了评估我们的工作，我们在OtterTune的调优工具中使用Google TensorFlow 和Python的scikit-learn，并为两个OLTP DBMS（MySQL，Postgres）进行了实验和一个OLAP DBMS（Vector）。我们的结果显示了OtterTune为这些工作负载生成DBMS配置与默认设置或由其他调优顾问生成的配置相比，延迟降低了58-94％
。我们也表明OtterTune在60分钟内生成配置占专家DBA创建的94％以内。

2. 挑战

       有一般规则或“最佳实践”指南可用用于调优DBMS，但这些并不总能提供良好的结果适用于各种应用和硬件配置。虽然
人们可以依靠某些规则来实现良好的表现特别是DBMS，它们并非适用于所有应用程序。从而，许多组织都聘请昂贵的专家来调整他们的系统。例如，2013年的一项调查发现，40％的参与度对一家大型Postgres服务公司的请求是用于DBMS调优的
和参数配置问题。

       调优DBMS的一种常用方法是DBA进行复制数据库到另一台机器，并手动测量性能来自实际应用程序的示例工作负载。基于
这个测试的结果，然后他们将调整DBMS的配置。由过去的经验和调整指南以及直觉的某种组合选择参数，然后DBA重复实验
看性能是否有所改善。这样一个“三分之二 - 错误“DBMS调优的方法繁琐，昂贵，而且
效率低下。因为（1）许多参数不是独立的，（2）某些参数的值是连续的，（3）通常不能从一个应用程序到下一个应用程序重用相同的配置（4）DBMS总是添加新的参数

        依赖关系：DBMS调优指南强烈建议DBA一次只能更换一个参数。这是明智但可悲的。鉴于大量的参数，速度很慢。它也不是完全有用的，因为改变一个参数可能会影响另一个参数的好处。但人类很难理解一个参数的影响，更不用说多个之间的相互作用了。不同的参数设置的组合意味着找到最佳配置是NP-hard 。为了证明这一点，我们进行了测量MySQL针对不同配置的性能改变其缓冲池的大小和日志文件的大小。结果表明DBMS实现了更好的性能当缓冲池和日志文件大小都很大时。但总的来说，当缓冲池大小和日志文件大小时，延迟很低“平衡。”如果缓冲池很大，日志文件大小是小，然后DBMS维护较少数量的脏页因此必须执行更多的刷新到磁盘。

      连续设置：DBMS调优的另一个难点是有很多可能的参数设置，和不同的设置。例如，DBMS缓冲池的大小可以是
任意值从零到系统上的DRAM量。在某些范围内，此参数增加0.1 GB可能无关紧要，而在其他范围内，增加0.1 GB可能会导致性能急剧下降，当DBMS耗尽物理内存时。 为了说明这一点，我们进行了另一个实验。我们将MySQL的缓冲池大小从10 MB增加到3 GB。结果表明延迟持续改善直到1.5 GB，之后性能下降，因为DBMS耗尽了物理内存。

不可重用的配置：DBA花费的精力在调优一个DBMS时，不会更容易调整下一个DBMS。
这是因为一个应用程序的最佳配置可能对另一个来说不是最好的。 

调整复杂性：最后，DBMS参数的数量总是如此。随着新版本和功能的发布而增加。 它是
DBA很难跟上这些变化并了解它们这将如何影响他们的系统。 这种复杂性是导致高总成本的主要因素。 人员估计是
几乎占大型DBMS拥有成本的50％，许多DBA将近25％的时间花在调优上。比单独检查每个数据库应用程序更好的方法
是使用利用知识的自动化工具从一个应用程序获得，以协助调整其他人。

3. 系统概览

我们现在介绍我们的自动数据库调整工具，克服了我们上面描述的问题。 OtterTune是一个调整适用于任何DBMS的服务。 它维护着一个存储库从先前的调优会话收集的数据，并使用此数据建立DBMS如何响应不同旋钮配置的模型。对于新应用程序，它使用这些模型来指导实验并建议最佳设置。 每个推荐在一个反馈循环中为OtterTune提供更多信息允许它改进模型并提高其准确性。

 

 显示了OtterTune架构的概述。系统由两部分组成。第一个是客户端控制器与要调整的目标DBMS交互。它收集运行时
来自DBMS的信息使用标准API（例如，JDBC）进行安装新配置，并收集性能测量。第二部分是OtterTune的调优管理器。它收到了
从控制器收集的信息并将其存储在其存储库中使用先前调优会话的数据。这个存储库确实不包含任何有关DBMS或其内容的机密信息，数据库只包含参数配置和性能数据。 调优管理器支持训练OtterTune的内部ML模型通过持续分析新数据和改进的后台流程。这些模型允许它在没有人为输入的情况下识别相关的参数和指标，以及在存储库中查找与目标类似的工作负载。

3.1 举例

       在新的调优会话开始时，DBA告诉OtterTune选择配置时要优化的指标（例如，延迟，
吞吐量）。 OtterTune控制器然后连接到目标DBMS并收集其硬件配置文件和当前参数配置。 我们假设这个硬件配置文件是单一的
来自预定义类型列表的标识符（例如，实例类型亚马逊EC2）。

       控制器开始第一个观察期。控制器将观察DBMS的一段时间并测量由DBA选择的独立于DBMS的外部指标（例如，延迟）。 DBA可以选择执行一组固定时间段的查询或特定工作负载跟踪。如果DBA选择一组固定时间段的查询，那么选择观察的长度等于固定的时间段。否则，持续时间取决于DBMS重放工作负载所需的时间跟踪。固定观察期非常适合快速，简单查询(这是OLTP工作负载的特征)，而执行长时间运行通常需要可变长度的周期，(OLAP工作负载中存在复杂查询).

       在观察期结束时，控制器收集其他DBMS特定的内部指标。 比如包括MySQL用于读取或写入磁盘页面的计数器。 其他DBMS提供类似的指标，但OtterTune不需要来自DBA的任何有关其含义的信息，无论是否表示性能好坏，或指标是否表示不同的名称在不同的DBMS中（相同的参数含义）

        当OtterTune的调优管理器从控制器观察期间收到新的结果时，它首先存储该信息在其存储库中。从此，OtterTune然后计算下一个配置(收集器安装在目标DBMS）。在OtterTune中，选择下一个配置是至关重要的。在每个观察期后（确定系统推荐哪一种配置）有两个不同的步骤发生。在第一步，OtterTune尝试“理解”目标工作负载并将其映射到过去的工作负载(相同的DBMS和硬件配置文件)。一旦调优管理器使用它到目前为止收集的数据找到了最佳匹配，然后开始第二个步骤，它推荐一个特定的参数配置
旨在改善当前工作负载，数据库，硬件的目标，为了协助DBA决定是否终止调优会话，OtterTune的控制器提供了更多推荐配置
与目前为止看到的最佳配置进行比较。此过程一直持续到DBA对改进感到满意为止与初始配置相比。

3.2 假设和限制

       OtterTune功能我们必须强调几个方面。最重要的是我们假设控制器具有管理性
修改DBMS配置的权限（包括必要时重新启动DBMS）。如果这是不可能的，对于OtterTune的调试试验，那么
DBA可以在单独的硬件上部署数据库的第二个副本。这要求DBA要么重放工作负载跟踪或转发生产中的查询
DBMS。这与以前的工具中使用的方法相同。通常需要重新启动DBMS，因为有些配置仅在系统停止并启动后生效。一些参数
导致DBMS在执行时需要额外处理当联机时（例如，调整日志文件的大小），这可能会占用几分钟，具体取决于数据库和硬件。 OtterTune目前忽略了重新启动DBMS的成本建议。我们推迟自动识别的问题这些参数并考虑重新启动的成本选择配置作为未来的工作。

       因为不希望重新启动DBMS，所以许多DBMS都支持动态更改一些参数而无需重新启动
系统。 OtterTune存储了一系列动态参数在它支持的每个DBMS版本上都可用，以及有关如何更新它们的说明。重新启动DBMS，只有当调整的一组参数需要重启时。 DBA可以只调优动态参数，如果禁止数据库重启的话。我们保留了OtterTune支持的每个DBMS版的参数黑名单。在每个调整会话的开始时，DBA需提供参数列表的黑名单。允许DBA添加任何参数到黑名单中，DBA希望OtterTune避免调优的任何其他参数，比如没有意义调整的参数（例如，DBMS存储文件的路径名，或者隐藏的或有严重的后果的参数（例如，可能导致DBMS丢失数据）。再次，自动确定是否更改参数将导致应用程序可能丢失数据超出了我们在这里工作的范围。

      最后，我们还假设数据库的物理设计是合理的。 这意味着DBA已经安装了适当的索引，物化视图和其他数据库元素。

       在接下来的部分中，我们将介绍OtterTune如何收集调优会话期间来自DBMS的运行时指标。 然后从这些数据创建模型，允许它（1）选择最多有影响力的参数，（2）将以前看不见的数据库工作负载映射到已知的工作负载，以及（3）推荐参数设置。 我们一开始讨论如何识别调优工具收集的指标最能表征应用程序的工作负载。 整个过程见下图

上图是OtterTune机器学习管道 - 此图显示了OtterTune中数据的处理路径。 之前的所有观察都存在于数据库中。 首先将此数据传递到Workload Characterization组件，该组件标识最有区别的DBMS度量标准。接下来，参数识别（Sect.5）组件生成最重要的参数的排序列表。 所有这些信息然后输入自动调优（第6节）组件，它将目标DBMS的工作负载映射到先前看到的工作负载并生成更好的配置。

4. 工作负载识别

       调优系统的第一步是发现最佳模型代表目标工作量的显著方面，以便它可以识别存储库中之前看到的工作负载与它相似。这使OtterTune能够利用它从以前调整会话收集的信息，以帮助指导为新应用程序寻找一个好的参数配置。我们可能会考虑两种方法来做到这一点。首先是分析逻辑级别的目标工作负载。这意味着检查查询和数据库模式来计算指标，例如每个查询访问的表/列的数目和每个交易的读/写比率。可以使用以下方式进一步细化这些指标通过DBMS的“假设”优化器API(用于估计额外的运行时间信息)，比如最常访问哪些索引。
然而，这种方法的问题在于它是不可能确定改变某个特定参数的影响，因为所有这些估计是基于逻辑数据库而不是
查询的实际运行时的行为。此外，DBMS如何执行查询以及这个查询与内部组件(受调优参数影响)的关系是取决于数据库的许多因素（例如，大小，基数，工作集大小）。因此，这个信息不可以仅仅通过检查工作量来捕获。

         更好的方法是使用DBMS的内部运行时指标表征工作负载的行为方式。 所有现代DBMS都公开有关系统的大量信息。 例如，MySQL的InnoDB引擎提供了有关数字的统计信息页面读/写数，查询缓存利用率和锁开销。OtterTune使用运行时统计信息来表征工作负载执行时记录。 这些指标提供了更多准确表示工作负载，因为它们捕获更多其运行时行为的各个方面。 它们的另一个优点是它们直接受到参数设置的影响。 例如，如果控制DBMS分配的内存量的参数到它的缓冲池太低，那么这些指标就表明了增加缓冲池缓存未命中数。所有DBMS
提供类似的信息，只是具有不同的名称和不同的粒度。 但正如我们将展示的那样，OtterTune的模型构建算法不需要标记指标。

4.1 统计收集

OtterTune的控制器支持模块化架构它为不同的DBMS执行适当的操作
收集运行时统计信息。在每次观察周期开始时，控制器首先重置目标DBMS的所有统计数据。然后它在这个周期结束时检索新的统计数据。从那时起，OtterTune就不知道哪些指标实际上很有用，它收集DBMS的每个数字指标使其可用并将其作为键/值对存储在其存储库中。这个收集过程的主要挑战是如何表达DBMS和数据库的子元素的度量标准。一些系统，如MySQL，只报告整个统计数据。但是，其他数据库系统提供单独的统计数据针对表或数据库。商业DBMS甚至保持独立各个组件的统计信息（例如，IBM DB2对每个缓冲池实例跟踪统计信息）。这种细粒度数据问题是DBMS提供多个具有相同名称的指标。一种可能的解决方案是在子元素的名称前加上前缀到度量标准的名称。例如，Postgres的数字度量为表“foo”读取的块存储在存储库中
如foo.heap_blks_read。但这种方法意味着它无法实现将此度量映射到其他数据库，因为它们的表会有所不同的名字。而 OtterTune存储指标与单个标量值相同的名称。这是有效的，因为Otter-Tune目前只考虑全局旋钮。我们推迟了这个问题调整表格或组件特定的参数作为未来的工作。

4.2 修剪冗余监控指标

       下一步是自动删除多余的指标。删除这些元素非常重要，因为使用OtterTune必须考虑捕获在性能和识别不同工作负载可变性的最小指标集。 减小此集的大小会减少ML算法的搜索空间，反过来加速整个过程和增加了模型适合OtterTune基于内存来调优的可能性。 我们将在后续章节中展示OtterTune可用的指标足以区分在同一硬件上部署的DBMS的不同工作负载。冗余DBMS指标出于两个原因。 首先是为完全相同的度量标准提供不同粒度的那些系统。 例如，MySQL读取数据量就innodb_data_read和innodb_pages_read而言。这两个指标是相同的度量只是在不同的单位，因此没有必要同时考虑他们。其他类型的冗余指标就是那些指标表示DBMS的独立组件但其值是强相关的。 例如，我们从实验中发现更新了元组数量的Postgres度量标准pg_stat_database.tup_updated与衡量数量的指标pg_statio_user_tables.idx_blks_hit几乎一致。

       我们使用两种经过充分研究的技术进行修剪。 首先是降维技术，称为因子分析，讲高维DBMS指标转换为低维数据。 然后我们使用第二种技术，称为k-means ，用于聚类这种低维数据，成为有意义的群体。 使用降维技术是许多聚类算法的预处理步骤，因为它们减少了数据中“噪音”的数量。 这个提高了聚类分析的稳健性和质量。

       给定一组包含任意相关的实值变量，FA将这些变量减少到一组较小的因子来捕获原始变量的相关模式。 每个因素是原始变量的线性组合; 因子系数类似于并且可以用相同的方式解释线性回归中的系数。 此外，每个因素都有单位方差与所有其他因素无关。 这意味着人们可以通过多少变化来排序因子来解释原始数据。 我们发现只有最初的几个因素对于我们的DBMS指标数据而言意义重大，这意味着大部分数据可变性由前几个因素捕获。

	Config1	Config…	Config j	Config n
metric 1
Metric …
Metric i
Metric m

这个config是一组参数设置，还是某个参数的值，还没搞明白?

因子分析算法：

https://blog.csdn.net/guang_mang/article/details/78724142

       然后，我们使用每个指标的一行作为坐标，通过k-means聚类。 我们为每个类保留一个指标，即最靠近集群中心的那个。 使用k-means方法的一个缺点是它需要最佳数量的聚类（K）作为其输入。 我们使用简单的启发式来完全自动化这个选择过程和近似K.虽然这种方法不保证找到最佳解决方案，它不需要人类手动解释问题的图形表示确定最佳簇数。 我们比较了这种启发式与其他技术[55,48]选择K和发现他们选择的值相差一到两个最接近我们的近似值。 这种变化几乎没有差别在OtterTune生成的配置质量方面

 

5. 识别重要的参数

      修剪冗余指标后，OtterTune接下来会识别哪些参数对DBA的目标影响最大。 DBMS可以有数百个参数，但只有一个子集实际上影响了DBMS的性能。因此，减少了参数数目限制了必须考虑的DBMS配置总数。
     OtterTune使用流行的线性特征选择技术回归，称为Lasso [54]，来发现与系统整体性能最强相关性的参数。为了
检测参数之间的非线性相关性和依赖性，我们还在回归中包含多项式特征。

    OtterTune的调优管理器在后台不断执行这些计算，当新数据来自不同的调优会话。在我们的实验中，每次调用Lasso都需要
20分钟消耗和10 GB内存用于存储库具有数百万个数据点的100k试验。

     我们现在描述如何使用Lasso识别重要的旋钮以及它们之间可能存在的依赖关系。 然后我们讨论OtterTune如何在调整过程中使用它。

5.1 使用Lasso进行特征选择

5.2 依赖

5.3 增量参数选择

6. 自动调优

       现在，在这一点上，OtterTune有（1）非冗余的集合指标，（2）最有影响力的配置参数，以及（3）来自先前调整会话的数据存储在其存储库中。OtterTune重复分析了迄今为止收集的数据会话然后给出下一个配置。 它在调优过程中的每次观察期完成后执行两步分析。 在第一步，系统识别来自先前调整会话的哪个工作负载与目标工作量的最相似。 它通过比较这个会话的指标与之前看到的工作负载的指标，来看看与之前哪个配置最相似。 曾经OtterTune已将目标工作负载与其存储库中最相似的工作负载相匹配，然后启动第二步的分析，选择一个参数配置以最大化目标。 我们现在更详细地描述这些步骤。

6.1 工作负载映射

        第一步的目标是匹配目标DBMS的工作负载基于所选指标组的值从在数据库中找到最相似的工作负载。OtterTune所做的匹配质量随着数目标工作负载收集的数据而增加，，这就是我们想要的期望。 因此，使用动态映射方案优于静态映射（即在第一个观察期结束后的一次映射）因为它使OtterTune能够做得更多随着调整会话的进展。

矩阵集合()有相同的行和列。n是指标的个数(前面通过因子分析降维和k-means聚类进一步修剪后的指标)。每个指标对应一个矩阵，每个元素含义：某个工作负载在某个参数配置下的该指标的值。如果有多个观测值，就取中位数。某个指标在不同工作负载和不同配置下的值.

	Config1	Config…	Config j	Config n
工作负载1
工作负载 …
工作负载 i
工作负载 m

工作负载映射：

1. 目标工作负载表征向量。计算到上面指标对应矩阵的距离，即对应指标到每个工作负载的距离

2. 将第一步计算出的每个指标到每个工作负载的距离取平均值，得到目标工作负载到历史工作负载的距离。

3. 取距离最小的那个的工作负载就是与目标工作负载最相似的

在计算得分之前，所有指标具有相同的数量级至关重要。 否则，得到的分数将是不公平的，因为任何规模大得多的指标将主导平均距离计算。 OtterTune通过计算每个指标的十分位数，然后根据它们所属的十进制值对值进行分箱，确保所有度量标准具有相同的数量级。 然后，我们用相应的bin编号替换矩阵中的每个条目。 通过这一额外步骤，我们可以为Otter-Tune存储库中的每个工作负载计算准确且一致的分数。比如某指标值的范围是1到1000，那么分成10等份就是1-100,2-200，...,10-1000等。如果某指标值是160，那取值为2.

6.2 配置推荐

       OtterTune使用高斯过程（GP）回归来推荐它认为可以改进目标度量的配置。 GP回归是一种最先进的技术，其威力大约等于深度网络的威力。 GP有许多吸引人的功能，使其成为建模配置空间和提出建议的合适选择。最重要的是，GP提供了一种理论上合理的方式来权衡探索（即获取新知识）和利用（即制作） 基于现有知识做出的决定。另一个原因是GP默认情况下会提供置信区间。尽管可以使用自举等方法来获取深度网络和其他不具有范围的模型的置信区间。 虽然像bootstrapping（自助抽样）这样的方法可以用来获得深度网络和其他没有给出它们的模型的置信区间，但它们的计算成本很高，因此对于在线调优服务来说是不可行的

       OtterTune通过重用先前选择的工作负载中的数据来训练GP模型，从而开始推荐步骤。 它通过添加目前已观察到的目标工作负载的指标来更新模型。 但由于映射的工作负载与未知工作负载不完全相同，因此系统不完全信任模型的预测。 我们通过增加OtterTune尚未尝试进行此调整会话的GP模型中所有点的噪声参数的方差来处理此问题。 也就是说，我们在协方差中添加一个脊项(ridge )。 我们还为OtterTune选择的每个配置添加了一个较小的脊线项(ridge )。 这对于“噪声”虚拟化环境是有帮助的，其中外部DBMS度量（即，吞吐量和时延）从一个观察周期到下一个观察周期发生变化。

      现在，对于此步骤中的每个观察期，OtterTune尝试找到比此会话中迄今为止所见的最佳配置更好的配置。 它通过（1）搜索GP中的未知区域（即，其几乎没有数据的工作负载）或（2）选择其GP中接近最佳配置的配置来完成此操作。 前一种策略被称为探索。 这有助于OtterTune查找配置，其中旋钮设置为超出其过去尝试过的最小值或最大值的值。 这对于尝试某些参数是有用的，其中上限可能取决于底层硬件（例如，可用的存储量）。 第二种策略称为利用。 这是OtterTune找到了一个很好的配置，它尝试对参数进行微调，以确定它是否可以进一步提高性能。

         在选择下一个配置时，OtterTune选择的这两种策略中的哪一个取决于其GP模型中数据点的方差。 它始终选择具有最大预期改进的配置。 这种方法背后的直觉是，每次OtterTune尝试配置时，它“更信任”来自该配置和类似配置的结果，并且其GP中这些数据点的方差减小。 预期的改进在采样点处接近于零，并且在它们之间增加（尽管可能少量）。 因此，它总是会尝试一种它认为最佳的配置或者它的配置

知之甚少。 随着时间的推移，随着未知区域数量的减少，GP模型预测的预期改善会下降。 这意味着它将探索其解决方案空间中良好配置周围的区域，以进一步优化它们。

       初始值的选择：

       OtterTune使用梯度下降来找到GP模型预测的表面上的局部最优值，使用一组称为初始化集的配置作为起始点。初始化集中有两种类型的配置：第一种是在当前调整会话中已完成的最佳性能配置，第二种是在每个参数的有效值范围内随机选择每个参数值的配置。具体地，最佳配置与随机配置的比率是1比10。在梯度下降的每次迭代期间，优化器在局部最优方向上一步一步走直到它收敛或已经达到其可以采取的最大步数的极限。 OtterTune从优化配置集中选择最大化潜在改进的配置，以便下次运行。这个搜索过程很快;在我们的实验中，OtterTune的调优管理器需要10-20秒才能完成每个观察期的梯度下降搜索。较长时间的搜索没有产生更好的结果。

        与我们在Otter-Tune中使用的其他基于回归的模型类似（参见Sects.5.1和6.1），我们采用预处理来确保特征是连续的并且具有大致相同的比例和范围。 我们使用虚拟变量对分类特征进行编码，并在将其作为输入传递给GP模型之前标准化所有数据。

       一旦OtterTune选择下一个配置，它就会返回此配置以及从运行此配置到客户端的预期改进。 DBA可以使用预期的改进计算来确定他们是否满足OtterTune迄今为止生成的最佳配置。

去学习高斯随机回归  加油

7. 实验评估

        我们现在对OtterTune自动优化DBMS配置的能力进行评估。我们使用Google TensorFlow和Python的scikit-learn实现了所有OtterTune算法。我们在评估中使用了三种不同的DBMS：MySQL（v5.6），Postgres（v9.3）和Actian Vector（v4.2）。 MySQL和Postgres是使用OS的包管理器安装的。 Vector是从其网站上提供的软件包安装的。我们没有修改默认配置中的任何参数，只是从远程IP地址启用传入连接。我们在AmazonEC2上进行了所有部署实验。每个实验包含两个实例。第一个实例是OtterTune的控制器，我们与OLTP-Bench框架集成。这些客户端部署在具有4个vCPU和16 GB RAM的m4.large实例上。第二个实例用于目标DBMS部署。我们使用了带有4个vC-PU和15 GB RAM的m3.xlarge实例。我们在具有20个内核和128 GB RAM的本地服务器上部署了OtterTune的调优管理器和存储库。我们首先描述了我们在数据收集和评估中使用的OLTP-Bench的工作负载。然后，我们讨论我们的数据收集以填充OtterTune的存储库。本节的其余部分是展示OtterTune功能的实验。

7.1 工作量

对于这些实验，我们使用来自OLTP-Bench测试平台的工作负载，其复杂性和系统需求不同：
YCSB：
雅虎！ Cloud Serving Benchmark（YCSB）以数据管理应用程序为模型，具有简单的工作负载和高可扩展性要求。它由六种OLTP事务类型组成，它们基于Zip-fian分发访问随机元组。该数据库包含一个包含10个属性的表。我们使用一个18m元组（~18GB）的数据库。
TPC-C：
这是评估OLTP系统性能的当前行业标准。它由五个事务组成，其中九个表模拟订单处理应用程序。我们在每个实验中使用一个包含200个仓库（~18 GB）的数据库。
维基百科：
此OLTP基准测试源自运行流行的在线百科全书的软件。该数据库包含11个表和8种不同的事务类型。这些交易对应于维基百科中文章和“监视列表”管理中最常见的操作。我们将OLTP-Bench配置为加载一个总数为~20 GB的10万篇文章的数据库。因此，复杂数据库模式与大型二级索引的组合使该基准测试对于DBMS的压力测试非常有用。
TPC-H：
这是一个决策支持系统工作负载，它模拟OLAP环境，其中几乎没有查询的先验知识。它包含3个3NF模式中的8个表和22个具有不同复杂性的查询。我们在每个实验中使用比例因子10（~10 GB）

        对于OLTP工作负载，我们将OtterTune配置为使用五分钟观察周期，并将目标指标分配为99％的延迟。 我们没有发现更短或更长的固定期间在我们的评估中产生统计上显着的差异，但是其工作负载模式变化较大的应用可能需要更长的时间段。 对于OLAP工作负载，OtterTune使用可变长度观察周期，该周期是该周期内目标工作负载的总执行时间。 工作负载的总执行时间是OLAP实验的目标指标

7.2 训练数据收集

        OtterTune需要先前调整会话的语料库，探索不同的旋钮配置才能正常工作。 否则，每个调优会话将是第一次看到任何应用程序，并且它将无法利用它从以前的会话中获得的知识。 这意味着我们必须使用初始数据来引导OtterTune的存储库以训练其ML模型。 我们使用了YCSB和TPC-H的排列，而不是运行OLTP-Bench套件中的每个工作负载。

         我们创建了15种不同工作负载混合的YCSB变体。 对于TPC-H，我们将查询分为四组，每组都是整体工作量的象征[12]。 所有训练数据都是使用DBMS的默认隔离级别收集的。我们还需要评估不同的旋钮配置。 对于每个工作负载，我们使用随机值在旋钮上执行参数扫描。 在某些情况下，我们必须手动覆盖这些旋钮的有效范围，因为如果任何旋钮设置超过任何机器资源的物理容量，DBMS将拒绝启动（例如，如果设置了缓冲池的大小大于RAM的数量）。 这在实际部署方案中不会成为问题，因为如果DBMS未启动，则OtterTune无法收集数据。

        我们使用这些不同的工作负载和参数配置，每个DBMS执行了超过30,000次试验。 这些试验中的每一个都被视为OtterTune中的观察期，系统从DBMS收集外部指标（即吞吐量，延迟）和内部指标（例如，读取/写入的页面）。对于每个实验，在加载我们的训练数据后，我们重置OtterTune的 数据库到它的初始状态。 这是为了避免我们的测量从先前的实验获得额外知识。 对于OLAP实验，我们还确保OtterTune的ML模型不会使用与目标工作负载相同的TPC-H工作负载混合数据进行训练。

7.3 参数数量

        我们首先分析OtterTune在每个观察期间优化不同数量的参数时的性能。这个实验的目的是表明OtterTune可以正确识别调整每个DBMS的最佳参数数。虽然使用更多参数可能允许OtterTune找到更好的配置，但它也增加了计算开销，数据要求和算法的内存占用。我们对OLTP DBMS（MySQL和Postgres）使用TPC-C基准测试，为OLAP DBMS（Vector）使用TPC-H。我们评估两种类型的参数计数设置。第一个是固定计数，其中OtterTune在整个调整会话中考虑相同的一组参数。第二个是增量方法，OtterTune随着时间的推移逐渐增加参数的数量。对于此设置，调优管理器以四个参数开始，然后每60分钟将计数增加两个。使用每个参数计数设置，我们选择按照其影响排名的前k个参数。.我们使用15小时的调整会话来确定固定设置是否可以达到与增量方法相同的性能;我们注意到这比我们预期的DBA运行OtterTune要长.

     增量方法使OtterTune能够在大约45分钟内找到MySQL的良好配置。 与Postgres和Vector不同，与固定参数设置相比，增量方法为MySQL的调优性能提供了显着的提升。 MySQL的下一个最佳参数设置是固定的四个参数。 这四个参数包括DBMS的缓冲池和日志文件大小（参见图1a），以及用于将数据刷新到存储的方法。 较大的参数计数设置包括控制其他线程策略和预取到缓冲池中的页数的能力。 但根据我们的实验，我们发现这些对静态TPC-C工作负载的性能影响最小。 因此，包括这些影响较小的旋钮会增加模型中的噪音量，从而更难找到重要的旋钮。

7.4 调优评估

        我们现在演示如何从以前的调优会话中学习，以提高OtterTune找到良好DBMS旋钮配置的能力。为了实现这一点，我们将OtterTune与另一个名为iTuned的调整工具进行了比较，该工具也使用高斯过程模型来搜索最佳的DBMS配置。

       与OtterTune不同，iTuned不使用从先前调整会话收集的数据来训练其GP模型。它使用随机抽样技术（Latin Hypercube Sampling）生成初始的10个DBMS配置集，这些配置在调优会话开始时执行。 iTuned使用来自这些初始实验的数据来训练GP模型，然后以相同方式搜索最佳配置。

         对于这种比较，我们使用OLTP DBMS（MySQL和Postgres）的TPC-C和Wikipedia基准标记以及OLAP DBMS（Vector）的TPC-H工作负载的两种变体。 OtterTune使用最后一个工作负荷映射阶段确定的最相似的工作负荷混合数据来训练其GP模型。两个调整工具都使用增量旋钮方法来确定每个观察期间要调整的旋钮数量（见第5.3节）。不同之处在于，iTuned仅在完成初始实验集后才开始使用此方法

        TPC-C：
图6中的结果显示，OtterTune和iTuned都在调优会话的早期阶段找到配置，从而提高了默认配置的性能。但是，有两个关键的区别。首先，OtterTune在MySQL的前30分钟和Postgres的45分钟内找到了更好的配置，而iTuned需要60-120分钟来生成为这些系统提供任何重大改进的配置。第二个观察结果是OtterTune为此工作负载生成了比iTuned更好的配置。在MySQL的情况下，图6a显示OtterTune的最佳配置比iTuned的延迟降低了85％。使用Postgres，它降低了75％。两种方法都为某些单独的旋钮选择相似的值，但iTuned无法为OtterTune的多个旋钮找到适当的平衡。OtterTune在平衡这些旋钮方面做得更好，因为它的GP模型可以更好地理解配置空间，因为它们经过了更多的数据训练

7.5 执行时间分解

        为了更好地理解在观察期结束时计算新配置时OtterTune会发生什么，我们检测其调优管理器记录它从Sect调整算法的不同部分花费的时间。我们使用TPC-C用于MySQL和Postgres，TPC-H用于Vector。执行时间的四个类别如下：

1. 工作量执行：DBMS执行工作负载以收集新度量标准数据所需的时间。
2. 准备和重新加载配置：OtterTune控制器安装下一个配置并为下一个观察期准备DBMS所需的时间（例如，必要时重新启动)
3. 工作负载映射：OtterTune的动态映射方案从其存储库中识别当前目标的最相似工作负载所需的时间
4. 配置生成：OtterTune的调优管理器计算目标DBMS的下一个配置所用的时间。 这包括梯度下降搜索和GP模型计算。

图9中的结果显示了OtterTune在调整会话期间花费的平均时间的细分。工作负载执行时间是OtterTune MySQL和Postgres总时间的最大部分。这是预期的，因为这两个DBMS都在5分钟的观察期内执行目标工作负载。相比之下，Vector执行一系列TPC-H查询，平均需要5秒才能完成。这些结果表明，Otter的控制器需要62秒才能为每个新配置重启MySQL，而Postgres和Vector分别需要3分钟和6.5分钟才能重启。 Postgres更长的准备时间是在观察期之间运行vacuum命令以回收过期元组占用的任何存储的结果。对于Vector，准备时间较长，因为必须卸载所有数据，然后在每次重新启动DBMS时将其重新加载到内存中。所有三个DBMS分别在30-40秒和5-15秒之间完成工作负载映射和配置建议步骤。这是因为OtterTune存储库中可用于在这些步骤中训练模型的每个工作负载的数据量大致相同

7.6 功效对比

       在我们的上一个实验中，我们比较了使用OtterTune选择的最佳配置与人类DBA和开源调优顾问工具选择的最佳配置时MySQL和Postgres的性能。我们还将OtterTune的配置与云数据库创建的配置进行比较，与其他实验在相同的EC2实例类型上运行。 我们在附录B中提供了这些实验的配置。

       每个DBA都提供了与我们所有实验中使用的相同的EC2设置。 他们被允许调整他们想要的任何旋钮，但不允许修改DBMS外部的东西（例如，内核参数）。 在客户端实例上，我们为他们提供了一个脚本，用于执行5分钟观察期的工作负载以及一个完整的日志记录，该日志记录了该工作负载以前执行的查询。 允许DBA根据需要多次重启DBMS和/或工作负载。

       对于DBaaS，我们使用为Amazon RDS生成的配置。 我们在这些实验中使用与其他部署相同的实例类型和DBMS版本。 我们最初在RDS管理的DBMS上执行了工作负载，但发现这没有提供公平的比较，因为Amazon不允许您禁用复制设置（这会导致性能下降）。 为了解决这个问题，我们从RDS实例中提取了DBMS配置，并在与其他实验相同的EC2设置上对它们进行了评估。 我们禁用控制复制设置的旋钮与我们的其他实验一致。

MySQL的：

        我们的第一位DBA是来自立陶宛的首席MySQL调优和优化专家，拥有超过15年的经验，并在一家知名的互联网公司工作。 他们在20分钟内完成了调音，总共修改了8个旋钮。

       MySQL调优工具（MySQLTuner [2]）检查OtterTune收集的相同类型的DBMS指标，并使用静态启发式方法来推荐旋钮配置。 它使用迭代方法：我们执行工作负载，然后运行调优脚本。脚本发出建议而不是精确设置（例如，将缓冲池大小设置为至少2 GB）。 因此，我们将每个旋钮设置为配置文件中建议的下限，重新启动DBMS，然后重新执行工作负载。 我们重复此操作，直到脚本停止推荐设置以进一步改进配置。 在完成建议之前，这个过程需要45分钟（即8次迭代），并修改了5个旋钮。

      图10显示，当使用OtterTune生成的最佳配置与TPC-C调优脚本生成的最佳配置时，MySQL的吞吐量提高了约35％，延迟提高了60％。我们看到调优脚本的配置提供了所有（非默认）配置中最差的性能。原因是调整脚本只修改四个最有影响力的旋钮之一，即缓冲池的大小。调优脚本修改的其他旋钮是独立缓冲池的数量和查询缓存设置。然而，我们发现这些旋钮没有可测量的效果。这些结果与我们在Sect中的研究结果一致。 7.3显示了MySQL的大部分性能改进来自调整前四个旋钮。图10中的延迟和吞吐量测量结果表明，使用OtterTune配置时，MySQL的吞吐量提高了22％，延迟提高了约57％到RDS。 RDS修改了四个最有影响力的旋钮中的三个：缓冲池的大小，日志文件的大小以及用于将数据刷新到磁盘的方法。尽管如此，我们仍然看到RDS配置的性能仅略高于调优脚本的性能。一个有趣的发现是，RDS实际上将日志文件（和其他文件）的大小减小到小于MySQL的默认设置。我们希望选择这些设置来支持部署在可变大小的EBS存储卷上的实例，但是我们还没有找到支持这一点的文档

 

参考文献：

通过机器学习来自动调优 DBMS，让任何人都可以部署数据库管理系统

http://blog.jobbole.com/111486/