摘要

过去，研究员和供应商都搭建了查询工具去帮助 DBA 实现系统调优、物理设计。然而，之前大部分工作是不完整的，因为 DBA 仍无法摆脱数据库更改的裁定工作，并且在问题发生后仍需要采取应对措施。

真正的“自治”数据库管理系统Database Manage System所需要的是一种为自治而设计的新架构。这与以前的工作不同，因为系统所有方面都受集成规划组件控制，该组件不仅优化系统以适应当前负载，也预测未来的负载趋势，以便系统能够相应地进行准备。这样，DBMS 就可以支持所有以前的调优技术，而不需要人力确定正确的方式和适当的时间去部署它们。它还支持一些对现代高性能 DBMS 很重要的优化，这点在今天是很难的，因为管理这些系统的复杂性已经突破专家的能力上限。

本文介绍了第一代 Self-Driving DBMS——Peloton 的架构。由于深度学习算法的进步以及硬件、自适应数据库架构的改进，Peloton 的自主能力现在有了可能性。

介绍

从 1970 年以来，关系模型和声明式查询语言就以消除数据管理负担为卖点。40年后，DBMS 变得更加复杂，功能越来越多。使用现有的自动调优工具是一项繁重的任务，因为它们需要费力准备工作负载样本、空闲的硬件来测试更新，最重要的原因是需要直观了解 DBMS 内部结构。如果 DBMS 可以自动完成这些事，那么它将消除部署数据库所涉及的许多复杂性和成本。

以前关于调优系统的工作关注点在针对数据库单个方面的独立工具上。例如，一些工具能够选择数据库的最佳逻辑或物理设计，如索引、分区方案、数据组织或物化视图。其他工具可以为应用选择调优参数。这些工具中的大多数都以相同的方式操作：DBA 为其提供样本数据库和工作负载跟踪，以指导搜索过程去找到最佳或接近最佳的配置。主要的 DBMS 供应商（包括 Oracle、Microsoft 和 IBM）都以这种方式操作。最近有一种推动集成组件支持自适应架构的趋势，但这同样只专注于解决一个问题。同样，云厂商使用动态资源分配服务，不会对单个数据库进行调优。

所有这些对一个完全自治的系统来说都是不够的，因为它们在 DBMS 之外，不能同时解决多个问题。也就是说，它们从系统外部观察 DBMS 的行为，并在问题发生后建议 DBA 如何修正问题。调优工具假定操作它们的人有足够的知识，可以在特定时间内更新 DBMS，不对应用产生大影响。然而，数据库领域在过去十年中发生了巨大的变化，我们不能假定 DBMS 是由一个了解数据库优化的专家部署而成。再说，即使这些这些工具可以实现自治， DBMS 架构也会在重大更新时给 DBMS 施加很大压力，也无法突破未来的瓶颈。

本文中，作者证明了自治数据库系统是可以实现的。下文首先会讨论该系统所面临的主要挑战。然后，作者提出了 Peloton 的架构，以及使用 Peloton 中集成深度学习框架的测量结果。

问题概述

自治 DBMS 面临的第一个挑战是理解应用的负载。最基本的级别是将查询定义为 OLTP 或 OLAP 应用。如果 DBMS 确定了应用属于二者中的哪一类，那么它就可以决定如何优化数据库。例如，如果是 OLTP，DBMS 应该将元组存储在面向行的布局中，并为写进行优化。如果是 OLAP，那么 DBMS 使用面向列的布局，这样更适应访问表列子集的只读查询 。处理这个问题的一种方法是部署专门用于 OLTP 和 OLAP 负载的独立 DBMS，然后在它们之间定期流更新。但是这不适合 HTAP，因为它在数据由 OLTP 写入时就执行 OLAP 查询，所以无法将 DBMS 独立部署开。更好的方法是部署一个支持混合 HTAP 负载的 DBMS 。这种系统会自动为不同数据库段选择适当的 OLTP 或 OLAP 优化。

除了要理解应用的负载，DMS 也需要预测资源利用趋势。这帮助它能够预测未来需求和部署优化，同时对性能影响最小。许多程序的使用模式密切契合人类的日常生活。这也是为什么 DBA 会在非高峰时间安排更新，以避免正常业务时间的服务中断。不可否认，有些工作负载异常是 DBMS 无法预料的。但这些模型可以预先警告，使得 DBMS 能够比外部监控系统更快地实施缓解措施。

现在， DBMS 可以依靠这些模型去确定数据库调优与优化操作，以更好应对预期的工作负载。自治 DBMS 不支持 DBA 的任务，这些任务需要系统外部信息，比如权限、数据清洗和版本控制。如下表所示，自治 DBMS 可以支持三种优化类型。第一个是数据库物理设计，第二个是数据组织的修改，最后是影响 DBMS 的运行时行为。对于每一个优化操作，DBMS 将需要评估它们对数据库的潜在影响。这些评估不仅包括行动部署后消耗的资源，还包括 DBMS 部署行动时消耗的资源。

即使系统能够预测程序的工作负载，选择要使用的操作 ，并确定实施操作的最佳时间，仍然存在额外的挑战。如果 DBMS 不能有效地应用这些优化，没有带来较大的性能下降，那么系统将无法快速适应变化。这也是目前自治 DBMS 不可能实现的另一个原因。如果系统只能每周更新一次，那么它很难规划如何纠正系统。因此，论文认为需要一个灵活的基于内存的 DBMS 体系结构，可以在部署过程中逐步优化，而不会对应用程序产生可察觉的影响。

最后，一个自治 DBMS 有两个额外的约束，它必须关联如今的应用程序。首先，DBMS 不能要求开发人员重写应用代码以适应自治 DBMS。第二，不能依赖只支持某些编程环境的程序分析工具。

自治架构

研发发现现有 DBMS 对于自治操作过于笨重 ，因为它们需要在更改时重新启动，而且上表中的许多操作太慢了。因此，DBMS 需要一个崭新的架构，对集成的自治组件有更全面、更细致的控制 。

接下来描述 Peloton 架构中的组件。Peloton 架构是一种全新的架构，而不是改造现有的 DBMS（例如，Postgres/MySQL）。最重要的是，它使用了多版本并发控制，在不阻塞 OLAP 查询的前提下交叉 OLTP 事务和操作。另一个特点是，它使用了一个内存存储管理器，具有无锁的数据结构和灵活的布局，可以快速执行 HTAP 工作负载。这些设计已经使我们能够支持 Peloton 的优化操作。

Peloton 的自治流程如上图所示。除了环境设置（比如内存阈值与目录路径），论文的目标是让Peloton 在没有任何人为提供的指导信息的情况下高效运行。系统自动学习如何提高应用程序查询和事物的延迟。延迟是 DBMS 中最重要的度量标准，因为它全面代表性能情况。本文的其余部分假设延迟是主要优化目标。可以为分布式环境中的其他重要指标添加额外的约束，例如服务成本和资源。

Peloton 包含一个嵌入式监视器，跟踪系统的内部事件流的执行查询。每个查询条目都标注了其资源利用率。流还定期被 DBMS/OS 遥测数据和优化操作的开始/结束事件打断。然后，DBMS 根据这些监控数据为应用程序的预期工作负载构建预测模型。它使用这些模型来识别瓶颈和其他问题（例如，缺少索引、超载节点），然后选择最佳操作。系统执行此操作的同时仍然处理应用程序的常规工作负载，并收集新的监控数据，以了解这些操作如何影响其性能。

工作负载分类

第一个组件是 DBMS 的集群器，它使用无监督学习方法对具有类似特征的应用程序查询进行分类。集群工作负载减少了 DBMS 维护的预测模型数量，从而使预测应用程序的行为更容易（也更准确）。Peloton 的初始实现使用 DBSCAN 算法。这种方法已被用于对静态 OLTP 工作负载进行聚集操作。

这种集群的一大问题是使用什么查询特征。这两种类型的特性是查询的时间度量和查询的逻辑语义。虽然前者使 DBMS 能够更好地聚集类似的查询，且不需要理解它们的含义，但它们对数据库内容或其物理设计设计的变化更敏感。即使数据库没有更改，在高并发工作负载中也可能发生类似的问题。另一个方法是根据逻辑执行计划的结构（例如表、谓词）对查询进行分类，这些特征独立于数据库的内容及其物理设计。这些特征是否会产生集群以生成良好的预测模型还有待观察，或者运行时指标的准确性是否超过了再训练的成本。运行时度量可能会使系统在更短的时间内收敛到稳定的状态，因此系统不必经常重新训练它的预测模型。或者，即使集群经常变化，硬件加速训练也能使系统以最小 的开销加速重建模型。

下一个问题是如何确定集群何时失效。当这种情况发生时，DBMS 必须重新构建集群，这可能打乱已有的分类，并要求它重新训练所有的预测模型。Peloton 使用标准交叉验证技术来确定集群的错误率何时超过阈值。DBMS 还可以利用操作对查询的影响来决定何时重建集群。

负载预测

下一步是训练预测模型，预测每个工作负载集群的查询抵达率。除了异常热点外，这种预测使系统能够识别工作负载周期性和数据增长趋势，为负载波动做好准备。在 DBMS 执行一个查询后，它用它的集群标识符标记每个查询，然后填充一个直方图📊，该直方图跟踪在一段时间内每个集群收到的查询数量。Peloton 使用这些数据来训练预测模型，预测应用程序未来将执行的每个集群的查询数。DBMS 还为事件流中的其他 DBMS/OS 指标构建了类似的模型。

以前在自治系统方面的尝试使用了 auto-regressive-moving average 模型（ARMA）来预测在云中自动伸缩的 web 服务工作负载。ARMA 可以捕获时间序列数据中的线性关系，但它们通常需要一个人来识别模型中的差分顺序和 term 的数量。此外，线性假设对于许多数据库工作负载可能并不有效，因为它们受到外部因素的影响。

RNN 是预测非线形系统时间序列模式的一种有效方法。LSTM 是 RNN 的一种变体，允许网络学习时间序列数据中的周期性和重复趋势，而常规的 RNN 无法做到这一点。LSTM 包含一些特殊的 block，用于决定是否保留旧的信息以及何时将其输出到网络中。尽管 RNN 被吹捧为能够解决许多以前难以解决的问题，但仍需要研究如何使其适用于自治 DBMS。

RNN 的准确性也依赖于它的训练集数据的大小。但是跟踪在 DBMS 中执行的每个查询都会增加模型构建的计算成本。幸运的是，我们没有必要知道将来查询的确切数量。相反，Peloton 为每个组维护多个 RNN，它们在不同的时间范围和间隔粒度上预测工作负载。尽管这些粗粒度的 RNN 不准确，但它们减少了 DBMS 必须维护的训练数据和运行时的预测成本。组合多个 RNN 使 DBMS 能够处理对精确度要求更高的即时问题，也能够适应评估范围更广的长期计划。

行动计划与执行

最后一个组件是 Peloton 的控制框架，能够持续监控系统和选择优化行动，以提高应用程序的性能。这就是自治组件和 DBMS 架构紧密耦合的最明显好处，因为它使不同的部分能够相互提供反馈。作者也相信有机会在系统更多部分中使用强化学习，包括并发控制和查询优化。

行动生成：系统搜索可能提高性能的操作。Peloton 将这些操作存储在一个目录中，并记录在操作调用的历史。这种搜索是由预测模型指导的。它还可以删除冗余操作，降低搜索复杂度。

在需求竞争低时，Peloton 可以用更多的核去完成动作部署，在竞争高时，只能用更少的核。

行动计划：现在有了行动目录，DBMS 根据预测、当前数据库配置和目标函数去选择部署哪个行动。滚动时域控制模型receding-horizon control model，RHCM的基本思想：在每个时间单元，系统使用预测来估计某个有限时域的工作负载。然后，它会搜索动作，以最小化目标函数。但它只能应用于第一个动作，在下个时间单元重复流程前只好等待部署完成。这就是高性能 DBMS 至关重要的原因。如果动作在几分钟内完成，则系统不必监视工作负载是否已经转移，并决定中止正在执行的动作。

在 RHCM 下，计算过程被建模为一棵树，其中每一层包含 DBMS 可以调用每个操作的时间。该系统通过估算行动的成本效益来搜索树，并选择最低成本的行动序列。也可以选择在一个时间单元内不执行任何操作。一种降低这个过程复杂性的方法是，在搜索树的更深层次随机选择要考虑的行动，而不是评估所有可能的行动。这种抽样会加上权重，以便更有可能考虑为数据库当前状态及其预期工作负载提供最优行动。它还避免了最近调用的行动，但后来系统取消这条规则。

一个行动的成本是对部署它所需的时间估计，以及在这段时间内 DBMS 性能会下降多少。由于以前没有部署过很多行动，因此不可能总是从以前的历史记录生成这些信息。系统使用分析模型来评估每个操作类型的成本，然后通过反馈机制自动改进它们。这样的好处是在部署行动后查询的延迟时间发生了变化。这个好处来自 DBMS 的内部查询计划器成本模型。它是加权计算的行动部署后查询样本延迟改进的总和，权重是预测模型预测的期望查询完成率。

除了上述的成本-收益分析之外，系统还必须评估一个行动如何随时间推移影响 Peloton 的内存使用。任何导致 DBMS 超过内存阈值的行动都需要舍弃。

重要的是，系统在考虑行动时应该考虑多长时间跨度。太短会阻止 DBMS 及时为即将到来的负载峰值做好准备，但太长会使 DBMS 无法缓解突然出现的问题，因为模型太慢。此外，由于计算每个时间纪元的成本-收益是昂贵的，它可能创建另一个深度学习网络来近似它们值函数。

部署：Peloton 支持非阻塞方法部署行动。例如，重新组织表的布局或将其移动到不同的位置并不会阻止查询该表。有些操作，如添加索引，需要特别考虑。这样 DBMS 就不会因为在操作进行时数据被修改，导致任何错误发生。

DBMS 还从其集成的机器学习组件处理资源调度和竞争问题。使用单独的协处理器或 GPU 来处理繁重的计算任务，可以避免降低 DBMS 的速度。否则，DBMS 将不得不使用一台单独的机器，专门用于所有的预测和计算组件。这将使系统的设计复杂化，并由于协调而增加额外的开销。

其他注意事项

要让自治 DBMS 得到广泛应用，还需要克服一些非技术挑战。最重要的是 DBA 不愿意将数据库控制权交给自动化系统。为了简化过渡，自治 DBMS 可以以可视化方式公开其决策过程。例如，如果它选择添加一个索引，可以向 DBA 解释，它的模型表明当前的工作负载与过去某个时间点相似，这个时间点使用这样的索引是有好处的。

还必须支持来自 DBA 的提示，说明系统是否应该更多地关注工作负载的 OLTP 或 OLAP 部分。类似的，对于多租户部署，系统需要知道是否应该对每个数据库进行相同的调优，或者一个数据库是否比其他数据库更重要。

最后，可能需要为 DBA 提供一个覆盖机制。人类发起的改变被当作其他一样的行动，Peloton 记录操作历史来决定该行动是否有益。唯一的区别是系统不允许逆转。为了防止 DBA 做出的错误决策被永久保留，DBMS 可以要求 DBA 手动设置生命周期。

初步结果

作者在 Peloton 中集成了 Tensorflow，使用从一个在线讨论网站一个月的流量数据中提取 5200 万个查询来训练两个 RNN。使用 75% 的数据去训练模型，25% 数据去验证模型。在输入上应用了两个堆叠的 LSTM 层，然后连接到一个线形回归层，对这些层使用 10% 的 Drop 以避免过拟合。

第一个模型以分钟为粒度去预测下一小时将到达的查询数量。该模型收入是一个向量，表示过去两小时内每分钟的工作负载，而输出是一个标量，表示一小时后预测的工作负载。第二个模型使用 24 小时时域，粒度为 1 小时。

两个RNN的训练时间分别为 11 和 18 分钟，从下图可看出，模型能够以 11.3% 的错误率预测 1 小时后的工作负载，以 13.2% 的错误率预测一天后的。对于计算开销，前者大约是 2MB，DBMS 探测每个模型以获得新预测需要 2ms，向其添加一个新的数据点需要 5ms。

使用这些模型，可以在 Peloton 中实现数据优化操作。根据访问这些表的查询类型，将表迁移到不同布局中。每个表的“热”元组存储在行布局中，已经针对 OLTP 优化，而同一张表中“冷”元组存储在列布局中，已经针对 OLAP 优化。使用 HTAP 工作负载，白天执行 OLTP 操作，晚上执行 OLAP 查询。当启动自动布局时，在 Peloton 中执行查询序列，并将其与静态的行和列布局进行比较。

从上图可看出，Peloton 随着时间推移收敛到一种适合工作负载的布局。在第一段后，DBMS 将行元组迁移到列布局，适应 OLAP。接下来，当工作负载转移到 OLTP 查询时，自治 DBMS 比静态系统更好，因为它执行的内存写操作更少。

总结

随着大数据运动兴起，对自治 DBMS 的需求越来越大。这类系统将降低人力成本在部署任何规模数据库上的浪费，并使各组织更容易享受数据驱动决策带来的便利。论文概述了 Peloton DBMS 的自治架构。作者认为，由于深度神经网络、新硬件和高性能数据库架构，自治 DBMS 系统是可以实现的。