英语原文共 16 页，剩余内容已隐藏，支付完成后下载完整资料
摘要：
数据库管理系统的配置调整对于任何的密集型应用的优化都是极其重要的方面。但是数据库管理系统的配置调整长久以来都是一项很困难的任务，因为数据库管理系统的配置调整拥有着成百上千的用来控制系统里一切事情的“节点”，例如：为高速缓冲存储器工作和频繁的数据写入和储存的记忆单元的数量。这些节点也有着一些问题：1.节点并非标准化的（即：2个数据库管理系统会对同一个节点采用不同的命名方式）2.非独立工作（即：改变一个节点会影响到其他的节点）3.不能广泛适用（即：为一个应用工作的对于另一个应用而言可能只是次佳的选择）。糟糕的是，这些节点的效果反馈通常仅来源于（昂贵的）实际经验。
为了克服这些挑战，我们提出了一种借用过去的经验并且收集新的信息去调整数据库管理系统的配置的自动化方式：我们采取了一种将人为指导和自主学习的结合起来的机器学习方式：1.选择影响最为广泛的节点。2将看不见的数据库工作负载映射到以前的工作并从中汲取经验，以及3重新设定节点设置。我们在一个叫做Ottertune的新工具上实行我们的技术并且在三套数据库管理系统进行测试。我们的测试表明：在ottertune上对配置的改善和现存的任何一个工具或者专家一样优秀甚至要更加好。
1.介绍：
收集庞大的信息并且进行加工处理和分析的能力对于能够在商业和科学领域推断出新的信息是极为重要的。数据库管理系统在数据密集型应用（“大数据”）方面有着一定的争议成分。这些系统的表现通常用米制测量，例如吞吐量（即系统收集新数据的速度）和延迟（即系统能够多块的回应一个指令）。
在数据库管理系统中表现优异是很难的，因为数据库管理系统是有着很多在运行时操作几乎控制着各个方面的可调选项的复杂系统。这种结构的节点允许数据管理人员控制数据库管理系统运行时的多方面操作，例如他们可以设定相比与事务日志缓冲器有多少记忆单元可以分配给高速数据缓冲器。现代的数据库管理系统因为有很多的配置节点而臭名昭著。数据库管理系统令人费解部分是因为他们的表现和可扩展性极大的取决于他们的配置。这些节点的预设配置也很令人厌恶，而这更加加剧了这一问题。举个例子，2016年预设的MySQL配置认为它仅能够在随机存取存储器上进行调度。
考虑到这个，很多机构为了预期的工作负担采取了花费高昂的薪资雇佣专家去设定系统的节点。但是数据和应用的规格和复杂程度都在增加，充分利用数据库管理系统去满足一项应用的各方面需求已经超过了人类的能力。这是因为改善数据库管理系统高度依赖于一系列人类无法解释的因子。
对于数据库管理系统配置工具自动化以前的那些尝试有着很明显的缺陷，这使它们不能满足大部分的数据库应用的需求，这些调整工具里的很大一部分是由销售公司创作的，因此他们仅仅能够提供他们特有的数据库管理系统，小部分的调整工具才能够支持多种数据库管理系统但是仍然需要手动操作的步骤，例如需要数据库管理员备份第二份数据，在节点之间搭建信息渠道，或者监督传输流程。这些所有的工具也会独立的检查每个数据库管理系统，因此不会从以前的调整中获取新的信息。这种的工作方式效率低下，因为每次调整会花费很长的时间并且用去很多资源。
在这边文章中，我们提出一种技术，利用以前季度的样本数据进行信息的收集来调整新的数据库管理系统部署。我们的方法核心就是从这些以前的调整中提取的收集信息模式来训练机器的学习模式并且使用这种模式去1.选择最重要的节点2.将看不见的数据库工作负载映射到以前的工作并从中汲取经验，以及3重新设定节点设置从而达到预定的目标（即：延迟，吞吐量）。利用过去的经验来减少一部分用在调整数据库管理系统在新的应用中花费的时间与资源。为了测试我们的成果,我们在谷歌的TensorFlow和Python的scikit-learn的一个叫Otter Tune的测试工具对我们的技术进行了测试，并且在2个联机事务处理的数据库管理系统（MySQL,Postgres）上和1个联机分析处理数据库管理系统（Vector）上进行实验，我们的结果显示Otter Tune为这些工作事务所制造的数据库管理系统配置无论与它们的系统初始设定相比还是和其他的对配置调整的建议相比都能够达到降低58-94%的延迟。.我们还表明，Otter Tune在60分钟内生成配置，在专家DBA创建的配置的94%以内。
本文的其余部分组织如下。第二部分首先讨论数据库调整方面的挑战。然后，我们会在第三部分提供我们的方法的概述，然后，我们会在第四部分描述我们在收集数据库管理系统制度的技术。
2.动机
有一般的规则或“最佳实践”指南可用于调整DBMS，但这些并不总是为一系列应用程序和硬件配置提供良好的结果。尽管有些可以依靠特殊的规则在特定的DBMS上拥有良好的表现，但是它们并不是所有应用程序都通用的。因此，许多组织只好雇佣昂贵的专家来调整他们的系统。例如，2013年的一项调查发现，一家大型Postgress服务公司40%的参与请求是用于DBMS调优和旋钮配置问题[36]。
调整DBMS的一种常见方法是DBA将数据库复制到另一台机器，并从实际应用程序手动测量示例工作负载的性能。根据结果，如果这个测试，他们将调整DBMS的配置，根据一些组合的调优指南和直觉根据过去的经验。然后DBA重复了实验，看到了它的“油”性能提高[47]。这种“试错”的DBMS调优方法乏味、昂贵、低效，因为（1）许多旋钮不是独立的，（2）一些旋钮的值旋钮是连续的，（3）通常不能从一个应用程序重用相同的配置到下一个应用程序，（4）DBMS总是添加新的旋钮。
我们现在进一步详细讨论这些问题。 为了突出它们的含义， 我们使用MySQ L(V5.6)进行了一系列实验，这些实验在不同的旋钮设置下执行YCSB工作负载的变化。 我们将会在第7部分介绍我们的操作环境的细节。
附：DBMS调整指南强烈建议DBA一次只更改一个旋钮。 这是明智的，但可悲的是由于大量的旋钮而使得调整缓慢。 这也不是完全有用的，因为改变一个节点可能影响另一个节点。 但人类很难理解一个旋钮的影响，更不用说多个旋钮。 旋钮设置的不同组合意味着找到最优配置是极为困难。 为了证明这一点，我们通过改变其缓冲区池的大小和日志文件的大小来测量了MySQL在不同配置中的性能。 我们将结果放在图一当中。 当缓冲池和日志文件大小时，DBMS实现了更好的性能。 但是一般情况下，当缓冲池大小和日志文件大小“平衡”时，延迟较低。如果缓冲池大，日志文件大小，则DBMS保持较少的乱码页面，因此必须执行更多的刷新确保存储到磁盘。
连续设置： DBMS调整的另一个困难方面是，旋钮有许多可能的设置。2个连续的设置可能是不规则的会导致系统的表现不同。例如，DBMS缓冲池的大小可以是从零到系统上DRAM数量的任意值。 在某些范围内，增加0.1GB的旋钮可能是无关紧要的。 在其他范围内，0.1GB的增加可能导致性能急剧下降，因为那个时候DBMS已经耗尽了物理内存。为了说明这一点，我们运行了另一个实验，其中我们将MySqL的缓冲池大小从10MB增加到3GB。 结果如图所示。 1b显示延迟持续改善到1.5GB， 之后，性能下降，就是因为DBMS耗尽了物理内存。
不可重复使用的配置： 一个DBA在调整一个DBMS上花费的努力并不能使调整下一个DBMS变得更容易。 这是因为一个应用程序的最佳配置可能不是另一个应用程序的最佳配置。 在这个实验中我们使用三个MySQL旋钮配置执行三个YCSB工作负载。每个配置都是为其中一个工作负载提供最佳延迟(即config#1是工作负载的最佳延迟) #2和#3与之相对应)。 图1的1C显示，每个工作负载的最佳配置对另一个工作负载来说是最差的。 例如，从config#1切换到config#3可以改善MySQL的工作延迟使其降低了90%，但工作负载#1的延迟降低了3500%。 配置#2提供了最佳的平均性能整体。 但是工作负载#1和#3都使用优化的配置提高了2times;以上。
调整的复杂性： 最近，随着新版本和功能的发布，DBMS旋钮的数量一直在增加。 DBA很难跟上这些变化，也很难理解这将如何影响它们的系统。 图1中的图表1D 显示了不同版本的MySQL和Postgres的旋钮数量，甚至可以追溯到2001年。 这表明在过去的15年里旋钮数量增加了3倍，对于MYSQL则是将近6倍。
上面的示例显示配置DBMS是多么棘手。这种复杂性是造成数据库系统所有者经营总成本高的主要因素。 估计全体人力成本占到大规模DBMS总所有者经营成本的50%[43]并且许多DBA花费了将近25%的成本用于调优[21]。
一个更好的去分别的检查每个数据应用就是使用一个自动工具，利用从一个应用程序中获得的知识来帮助调整其他应用程序。
3.系统综述：
我们现在提出我们的自动数据库调优工具，该工具克服了我们前面描述的问题。 Ottertune是一种可以与任何DBMS一起工作的调优服务。 它包含了从以前的调优过程中收集的数据的存储库，并使用这些数据构建DBMS来响应不同旋钮配置的请求。对于一个新的应用程序，它使用这些模型来指导实验的最佳设置。每个设置都在反馈循环中为 Ottertune提供了更多的信息，使其能够改进其模型并提高其准确性。
图二展示了Ottertune的结构概述。该系统由两部分组成。 第一部分是客户端控制器，它与要调整的目标DBMS交互.. 它使用标准API从DBMS收集运行时信息(例如：安装新配置，并收集性能测量。）
第二部分则是 Ottertune调整管理。它接收从控制器收集的信息，并将其存储在其存储库中，其中包含来自以前调整过的数据。 此存储库不包含有关DBMS或其数据库的任何机密信息；它只包含旋钮配置和性能数据。Ottertune根据主要DBMS版本(例如，Postgresv9.3数据与Postgresv9.4分开)。 这可以防止Ottertune调整器从旧版本的DBMS中调整旋钮，这些旋钮可能在新版本中被废弃，或者调整旋钮只存在于较新的版本中。该管理还得到后台流程的支持，这些流程不断分析新的数据，并重新完善Ottertune的内部ML模型。 这些模型使它能够识别，在没有人输入的情况下对相关旋钮和度量进行编辑，并在存储库中找到与目标相似的工作负载。
3.1例子：
在新的调整进程开始时，DBA告诉Ottertune在选择配置时要优化什么度量（例如延迟、吞吐量）。 然后Ottertune控制器连接到目标 并收集其硬件配置和当前旋钮配置.. 我们假设此硬件配置文件是来自预定义类型列表的单个标识符(例如，AmazonEC上的实例类型) 2)。 我们将自动确定DBMS部署的硬件能力的问题推迟到今后的工作中。
然后控制器开始第一个观察周期。这段时间，控制器将观察DBMS并测量DBA选择的与DBMS无关的外部度量(例如：延迟)。 DBA可以选择执行固定时间段的一组查询或特定的工作负载跟踪。 如果DBA选择第一个选项，则观测周期的长度为等于固定的时间段。 否则，持续时间取决于DBMS重放工作负载跟踪所需的时间。 固定观测周期适合于快速、简单的查询，这是OLTP工作负载的特征，而可变长度周期通常是执行OLAP工作负载中存在的长期、复杂查询所必需的。
在观察周期的末尾，控制器会收集额外的DBMS特定的内部度量，包括MYSQL计数器的页面读取或写入磁盘。其他DBMS提供了类似的度量标准，但Ottertune不需要来自DBA的任何信息来说明它们的含义，它们是否表示性能好或坏，或者是否具有度量标准。不同的名称在不同的DBMS中意味着相同的东西。 我们在第4部分中进一步详细讨论了这个度量集合并且会在第5部分中按照我们的方法按其重要性排序DBMS的旋钮。
当Ottertune的调整管理器从控制器接收到新的观察周期的结果时，它首先将该信息存储在其存储库中。 由此，Ottertune计算下一个控制器应该安装在目标DBMS上的配置标准。 就像我们在前文讨论的那样。 选择下一个配置是Ottertune的关键任务。 有两个不同的步骤 在每个观察期之后放置，以确定系统将推荐什么样的配置。 在第一步中，Ottertune试图“理解”目标工作量，并将其映射到工作区第二步，它将专门设计一个旋钮配置，以改善目标目标的当前工作量，DBMS和硬件。 为了协助DBA决定是否终止调整进程，Ottertune为控制器提供了一个预估，即与迄今为止看到的最佳配置相比，推荐的配置有多好。这个进程将持续进行，直到DBA对初始配置的改进感到满意为止。
3.2想法及限制
Ottertune的能力种有几个方面的问题我们必须解决。 首先，我们假设控制器具有修改DBMS配置的管理权限(包括必要时重新启动DBMS)。 如果这是不可能的，那么DBA可以在单独的硬件上部署数据库的第二个副本，用于Ottertune的调整试验。 这要求DBA要么重新播放工作负载跟踪或从生产DBMS转发查询。 这与以前的工具中使用的方法相同。
重新启动DBMS通常是必要的，因为有些旋钮只有在系统停止和启动后才生效。 一些旋钮也会导致DBMS在返回联机时执行额外的处理（例如，调整日志文件的大小），这可能需要几分钟，这取决于数据库和硬软件， Ottertune目前忽略了在其建议中重新启动DBMS的成本。 当选择配置作为未来的工作时，我们推迟自动识别这些旋钮的问题，并考虑到重新启动的成本。
由于重新启动DBMS是不可取的，许多DBMS支持动态地更改一些旋钮，而不必重新启动系统。 Ottertune可在它支持的每个DBMS版本存储一个动态旋钮列表以及关于如何更新它们的说明。 然后，只有当正在调整的一组旋钮需要时，它才会重新启动DBMS。 DBA也可以选择在调整进程开始时只调整动态旋钮。 这是DBA在禁止重新启动DBMS时可用的另一种选择。 我们为每个DBMS版本保有一个由 Ottertune
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[239041]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
