摘要
该文回顾了过去十年数据库自动化调优的一些进展，并得出了一个结论：自动化调优数据库必须建立在反馈控制回路的模式上，而且必须要有合理的数学模型和系统组件上的工程实现。
1. 理解这个难题
数据库系统调优一般都是由有经验的DBA来管理，很困难而且成本高。
1.1 为什么自动化调优比以往更重要
目前互联网越来越多，但是一个网站或者服务不可用造成的损失是巨大的。也就需要公司尽可能早地发现系统的瓶颈，提前纠正，进行性能的提升。
1.2 为什么自动化调优在当前的电子服务时代更困难了
有以下原因
- 复杂的多层结构。
- 服务联盟：不同服务之间会有相互调用。
- 工作负载的多样性和可变性
- 长寿命的应用程序和长距离的工作负载依赖
2. 一些耐人寻味的方法
有些人认为使用hard code一些经验法则就可以解决问题，但是这种方法并不可行，因为这些经验法则并不适用于所有的情况。例如，对于缓存大小的选择，5分钟规则是一个经验法则，但是对于某些应用来说，5分钟规则并不适用。另一些人认为只要升级硬件就够了。但是这种方法也不可行，因为有些问题只能通过软件的调整来解决，而不是硬件的升级。
3. 来自COMFORT项目的教训
这一章主要讨论的是COMFORT项目的一些经验教训。一方面讨论下通用的自动化调优规则，另一方面去解决个别的自动化调优问题。
COMFORT项目是一个欧洲联盟的项目，目的是研究如何自动化调优数据库系统。该项目的主要贡献是提出了一个反馈控制回路的模式，以及一些工程实现的方法。
3.1 通用的自动化调优规则
主要原则是系统不断地观察某些性能指标，每当这些指标超过关键阈值时，系统就会动态地调整一些在线调整参数。这个原则很简单，但是当应用到真实的系统时，问题就变得很明显了。不清楚在什么情况下应该考虑哪些参数，以及它们应该被调整多少。一个简单的反馈控制回路可能会对某些问题过度反应，从而导致系统在两个不同的状态之间来回摇摆。为了解决这些问题，我们在这个方法上加了更多的结构，将反馈控制回路分成了三个阶段：观察、预测和反应，简称OPR周期。
观察阶段监测性能指标和工作负荷参数，这些指标可被视为性能问题或工作负荷模式的重大转变的指标。虽然吞吐量和查询或事务响应时间是很好的全局指标，但它们并不能提供任何关于问题原因的线索。因此，除了这些宏观指标外，我们还调查了应该测量哪些微观数据，以确定动态重新调整的需要。 此外，微观指标也可以指导我们选择适当的调优参数来解决问题。
只有当我们预测到有明显的改善，并且系统可望保持运行稳定时，才应该调整一个参数。稳定性检查是很重要的，否则我们可能只改善某些方面，而在其他方面引入系统退化的风险。事实证明，保守的预测步骤对于一个稳健的反馈控制回路来说是绝对重要的。这个步骤的关键作用，特别是它对数学预测模型的需求，往往被低估了。
三阶段反馈循环的最后一步是反应步骤。从科学的角度来看，这是三个步骤中最简单的：当预测步骤给我们一个明确的建议，即哪个参数应该调整多少，我们只需要转动参数。 然而，这种在线调整可能会产生工程问题：要建立一个系统，使所有的调整参数都能在系统为其工作负荷服务时动态变化，并不那么容易。
3.2 例子：负载控制
过渡的锁冲突可能导致系统的崩溃，这种情况被称为thrashing。这种情况下，系统的吞吐量会急剧下降，响应时间会变得非常不可接受，甚至接近无穷大。当然，这种情况只会在具有高度数据争用的更新密集型工作负载中出现（即使用锁进行并发控制时的锁争用）。需要注意的是，thrashing行为并不一定是由死锁引起的；它可能是死锁自由的访问模式引起的，而且是由传递锁等待引起的：等待锁的事务可能会阻塞其他事务，而这种情况的频率可能会急剧增加，以至于除了少数事务之外，所有事务都会被阻塞。
在数据竞争激烈的情况下，通常考虑的运行时调整参数是多程序级别（MPL），即允许并发执行的最大事务数量。不幸的是，对于一个给定的工作负载，要找到一个合适的MPL限制设置并不容易。如果MPL设置得太高，系统就容易发生阻塞；如果MPL设置得太低，许多事务就会在系统接纳队列中等待太长时间，而这些等待时间就是用户感知的响应时间的一部分。
对于混合工作负载，一个全局的MPL限制实际上是不合适的。我们对这个问题的自我调整方法是在事务管理器中建立一个具有短期反应能力的反馈控制回路。观察阶段的一个关键问题是找到一个适当的指标来表明锁争夺的水平。我们的第一次尝试是基于被阻塞的事务的比例，这是一个在[TGS85]的分析工作中已经考虑过的指标。 然而，事实证明，这并不能充分反映事务长度变化的影响。 我们的直觉让我们找到了一个指标，它隐含地按照一个事务持有的锁的数量的比例给事务分配权重。这个指标就是冲突比: 非阻塞事务持有的锁/所有事务持有的锁
我们观察到，无论实际的事务混合是什么，这个指标的值在1.3左右都表示非常高的thrashing危险。我们将这个值称为临界冲突比。我们的一些比较主观的发现后来被Thomasian精心设计的数学模型证实了。除此之外还引入了一个额外的队列来进行削峰，在队列中的事务会在之后进行重试。
3.3 Example: Dynamic Data Placement
另一个问题是动态数据落盘，我们在中对此进行了更详细的研究。主要目标是将数据放置到磁盘上，以便在任何时候每个磁盘的负载都大致相同。尽管有大量的文献涉及这种负载平衡问题，但我们几乎没有找到任何工作能够解决实际问题，即随着时间的推移，工作负载模式会发生变化。因此，以前冷的（即不经常访问）数据可能会变得热（即经常访问），反之亦然。我们对这个问题的解决方法，我们称之为磁盘冷却，再次基于反馈控制循环。与负载控制问题相比，这个问题的范围更广，时间范围更长：它会影响整个存储系统，数据迁移的时间范围是几个小时或可能是几分钟，而不是几秒钟。从算法上讲，我们的方法可以用贪婪启发式算法来描述。
在观察阶段，我们监测文件、扩展和块的热度。热度，最初是在[Co88]中提出的，是对数据对象的访问率（即每个时间单位的访问次数）的一种估计。它基于一个滑动窗口，该窗口跟踪一个数据对象的最后k次访问的时间点t1, ..., tk。然后k / (tk - t1)是一个动态调整的对象静态访问率的最大似然估计。(同样的原理用于LRU-k缓存算法[OW93]。)热度指标是一个对象引起的实际磁盘负载的抽象，因为它不区分许多小请求和少数大请求（例如，对单个块的随机访问与对物理上连续的块的顺序访问）。然而，它的关键点是它是加法的：整个磁盘的热量仅仅是驻留在磁盘上的数据对象的总热量。如果最热的磁盘的负载超过了利用率最低的磁盘的热量，我们认为并行磁盘系统的负载是不平衡的。
在预测步骤中，我们评估可能的数据迁移的好处和成本。作为迁移的候选对象，我们从最热的磁盘中选择可移动的对象（例如，extents），按照温度从高到低的顺序，其中温度是热量和大小的商数[Co88]。这种选择标准的原理是为了大大减轻热磁盘的负担，同时也是为了尽量减少迁移本身的额外运行时间成本。对象被转移到的磁盘是按照磁盘热度从高到低的顺序选择的，但要考虑到可能的放置限制。在实际启动数据迁移之前，我们评估了一个简单的排队模型，以检查迁移步骤是否会对已经过载的源磁盘造成不适当的性能下降。我们还研究了该方法的一般情况，即统计学文件捕获了某些类别的数据对象的周期性负载模式；在这种情况下，我们在调用数据迁移之前包括一个更详细的效益/成本分析[SWZ93]。
磁盘冷却方法的反应步骤是相当直接的。它只需要在线移动数据对象，并适当维护记账结构，如程度表。在九十年代早期，这种在线重组仍然被广泛认为是不可能的，但是今天所有工业强度的系统都应该有必要的机制[DE96]。
3.4 Example: Workflow Server Configuration
最后一个例子是最近关于工作流管理平台自动调整的工作，这种平台是复杂的分布式系统，包括一个或多个工作流引擎、应用服务器和中间件组件，如请求代理和消息队列服务器。为了分配负载和提高可用性，这些服务器中的一个或多个可能被复制到不同的计算机上，这就产生了一个问题：为了满足响应时间、吞吐量和可容忍的服务停机时间的指定目标，每个服务器类型需要多少个副本。
尽管这个长期系统配置问题的性质与前两个调整问题的性质完全不同，但我们的方法可以被投进反馈控制环框架。从该模型中得出各种服务器类型的预期负载。
假设一个给定的系统配置，预测步骤计算出各种工作流程类型的最大可持续吞吐量和平均周转时间，并使用排队模型来评估互动工作流程步骤的预期等待和重新响应时间。同样，根据不同类型服务器的估计故障率和重启率，通过马尔可夫可用性模型计算出预期停机时间。
最后，反应步骤对可能的假设配置进行迭代，使用预测模型来评估每个候选配置，并寻找满足所有性能和可用性目标的最低成本配置。其结果作为建议的重新配置（通常涉及硬件升级或重新分配现有计算机上的软件服务器）推荐给系统管理员。
与前两个小节的例子相比，数学模型在这里发挥了更大的作用；问题的长期性使我们可以使用更复杂和计算成本更高的技术。此外，我们旨在优化的指标是端到端的性能指标，而不是前面例子中的低级指标。除了用户感知的响应时间和可用性之外，我们还将所谓的可执行性指标作为优化目标，反映了一些服务器副本的瞬时中断所造成的性能下降的影响。这甚至考虑到了为维护而计划的中断。这方面的一个技术难题是用指数分布的状态停留时间来捕捉这种定期事件，这也是马尔科夫模型的基础；解决方案将状态扩展为子网，使状态停留时间遵循广义的埃朗分布，因此也可以近似于恒定时间。
3.5 学到的经验教训
有一些积极的看法：
- 反馈控制机制确实是算法和系统组件自动调优的一个合适的框架，但是不是万能;
- 数学模型能够使得反馈机制更加稳定，尤其是减少对拨动的过渡反应的风险;
- 收集工作负载属性和性能指标的统计数据是另一个关键资产。对于某些指标，如平均响应时间，使用指数加权平均值是一个好主意，而不是简单地使用最近的观测值。这样做可以减少由于短期的异常值而引起的过度反应;
- 尽早提醒系统管理员负载增加或工作负载模式的重大变化，往往可以在管理员意识到并分析问题之前，节省几天不可接受的性能下降;
- 用另一个调优的参数取代难以找到合适设置的微妙调优参数也有好处;
还有一些需要谨慎思考的点：
- 数学模型可能会极为复杂，难以计算;
- 限制观察和预测步骤的空间和时间开销往往是至关重要的;
- 反应阶段有一个固有的风险，即反应过度，最终导致调优参数的不稳定（如振荡）调整，特别是在工作负荷模式发生重大转变之后;
还有一些负面的经验教训：
- 即使能够完全理解并自动化处理一个调优问题，该调优参数可能会对其他的组件产生影响，会导致整个系统不可预测和不稳定。
- 我们今天已经可以实现什么？
作者对技术现状的主观评测：
- 那些对性能只有微小影响的旋钮（例如，组提交计时器或日志缓冲区大小），已经从产品提供的管理界面中基本消除了。
- 越来越多的调整旋钮带有可重复的默认值（例如，范围大小、表扫描的预取大小），甚至可以根据底层硬件（和操作系统）配置自动校准
- 在现有的情况下采用强大的经验法则。
- 适用的地方采用KIWI方法。这主要是针对磁盘I/O的瓶颈问题。
- 剔除那些即使在最佳条件下也只能提供边际收益的调谐方案。
- 移除需要黑魔法的调谐选项。这指的是那些即使是有经验的系统管理员也发现几乎不可能以适当的方式来处理的旋钮。
- 磁盘存储层面的调整问题基本上已经解决了
- 索引选择是一个已解决的问题[DE99]。通过将子问题的精确优化与搜索空间修剪的法学结合起来，这个问题甚至对于具有许多表和复杂工作负载的大型数据库来说都是可行的。几乎所有的商业数据库系统都有一个索引向导，推荐人们应该创建哪些索引，而且系统管理员很难超越这些工具。但是，请注意，这种向导完全不考虑索引选择可能对并发控制和资源争夺的影响（他们也可能忽略了一些特殊的功能，如多表聚类和其他花哨的连接索引）。
- 物化视图的选择大多得到了解决。
- 数据库系统应该为查询优化器维护的统计数据的适当选择和组织，例如某种类型的直方图或更普遍的数据概要，现在似乎已经被充分理解。
目前还有很多困难：
- 对查询运行时间和结果大小进行足够准确的预测，并生成误差可控的近似查询结果。
- 一般来说，查询优化仍然是一个大问题。即使有更好的统计数据（见上文），也有许多潜在的错误源可能导致糟糕的执行计划。
- 内存管理。动态调整查询工作空间和缓存区域大小的灵活机制已经到位，但严重缺乏在线优化的良好策略。
- 事务隔离级别。
- 对于传统的OLTP工作负载来说，MPL限制、准入控制和调度都已经解决了，但是对于同时具有OLTP和OLAP部分的混合工作负载以及对数据以及内存、磁盘和处理器的潜在争夺来说问题仍然广泛存在。
- 硬件资源配置仍然具有挑战性，除非有一个详细和精确的静态工作负载的特征，作为适当的容量规划工具的输入。
- 缺少一种理论，或者至少是一些原则，来应对调整旋钮的相互作用。我们怎样才能确保一个组件中的旋钮设置不会对另一个组件产生不必要的副作用？
5. 我们应该做什么？
作者认为应该开发一个RISC风格的数据库，但是现在数据库好像都没有这么发展的。这块就不展开详细叙述了。