Make Your Database System Dream of Electric Sheep: Towards Self-Driving Operation

论文地址

ABSTRACT

        众所周知，数据库管理系统（DBMS）难以部署和管理。自动驱动DBMS通过自动管理自身来消除这些干扰。尽管对DBMS自动调优进行了数十年的研究，但真正自主、自动驱动的DBMS尚未出现。但是最近在人工智能和机器学习（ML）方面的进展已经使这一目标接近。
        有鉴于此，我们提出了一个实现自动驱动DBMS的系统实现论文。我们首先概述了NoisePage自驱动DBMS，该DBMS使用ML预测DBMS的行为并在没有人的支持或指导的情况下进行自我优化。
该系统的架构有三个主要的基于ML的组件：（1） 工作量预测，（2）行为建模，（3）行动计划。然后，我们描述了促进整体自主操作的系统设计原则。这样的规定减少了问题的复杂性，从而使DBMS能够更快地收敛到更好、更稳定的配置。

1 INTRODUCTION

        以前关于自动DBMS的大部分工作都集中在针对单个问题的独立调优工具上。例如，一些工具选择数据库的最佳逻辑或物理设计，例如索引、分区方案、数据组织或物化视图。其他工具为应用程序选择调整参数。这些工具大多以相同的方式运行：DBA提供了一个示例数据库和工作负载跟踪，用于指导工具的搜索过程，以找到优化系统单个方面的配置（例如，要构建的索引）。主要供应商的工具，包括Oracle、Microsoft和IBM，都是以这种方式运行的。最近出现了一种趋势，即支持自适应架构的集成组件，但这些组件一次只能解决一个问题。云数据库供应商在服务级别使用自动资源管理工具，或提供其先前推荐工具的托管版本。
        尽管之前的这些努力很有影响力，但它们对于完全自治的DBMS来说是不够的，因为它们只解决了部分问题。也就是说，它们只能识别可能提高DBMS性能的潜在操作（例如，添加哪个索引）。然而，他们无法推断应用哪些以及何时应用，因为他们无法预测工作量趋势或考虑部署成本。因此，他们依赖知识渊博的DBA在对应用程序影响最小的时间窗口内更新DBMS。他们也无法了解哪些行动在什么条件下提供了最大的利益，然后将这些知识应用到新的情况。这种对人类专家的需求导致了DBMS软件的高拥有成本和支持复杂应用程序的困难。
        需要的是一个自动驱动的DBMS，它可以预测应用程序的需求，然后自动选择全面修改所有系统方面的操作。DBMS学习如何响应其应用的每个动作，并在不同场景中重用这些知识。有了这些知识，自动驱动DBMS可以支持大多数管理任务，而无需人工确定正确的部署方式和时间。
        自动驱动DBMS的目标是随着数据库及其工作负载随时间的推移而自动配置、管理和优化自身。指导DBMS决策的核心思想是人类选择的目标函数。目标函数可以是性能指标（例如吞吐量、延迟、可用性）或部署成本（例如硬件、云资源）。这类似于一个人告诉自动驾驶汽车他们想要的目的地。DBMS还必须在人为指定的约束条件下运行，例如成本预算或服务级别目标（SLO）。
        自驱动DBMS改进其目标功能的方式是部署其认为有助于应用程序工作负载执行的操作。这些动作控制系统的三个方面：（1）物理设计，（2）旋钮配置（3）硬件资源。第一个是对数据库的物理表示和数据结构（例如索引）的更改。第二种操作类型是通过配置旋钮影响DBMS运行时行为的优化。这些旋钮可以针对单个客户端或整个系统。最后，资源操作改变了DBMS的硬件资源（例如，实例类型、机器数量）；这些假设DBMS部署在弹性/云环境中，在该环境中可以随时获得额外的资源。
        在本文中，我们概述了我们正在进行的研究，以实现真正的自驱动DBMS。我们首先讨论了DBMS可以支持的不同自动化级别。然后，我们描述了NoisePage DBMS的自驱动架构。NoisePage规划组件的设计灵感来自自动驾驶车辆，以促进自动操作。该系统是我们探索新ML方法以解决复杂动作规划问题的研究工具。
        但是，即使是最复杂的ML方法，在设计DBMS以支持自主操作时也无能为力。因此，我们还提出了我们认为在自动驱动DBMS中必要的软件工程设计原则。这些来自我们为现有系统和新的自主架构开发基于ML的调优工具的经验。这些原则适用于正在开发现有DBMS或从头开始构建DBMS的开发人员。此外，它们独立于ML方法或系统实现。后者包括存储组织（磁盘与内存）、系统架构（单节点与分布式）或工作负载（OLTP与OLAP）。

2 SELF-DRIVING DATABASES

        对于DBMS“自动驾驶”的含义，目前没有标准定义。此外，对于自驱动系统如何与自适应、自调优和自管理DBMS相关，存在困惑。在数据库管理系统中实现完全自治还有几年的时间。然而，在一些中间级别上，DBMS从人身上移除控制，并自行承担更多的管理责任。自动驱动DBMS的自主性在其设计和用户体验中起着核心作用。因此，我们在DBMS可以提供的自治级别上提出了以下分类法。我们通过减少用户交互和控制来提高自主性。这些级别的概述如表1所示。

Table 1: Levels of Autonomy – A classification of the levels of capabilities of autonomy in DBMSs.

Level #0:
        在最低程度的自主性下，系统为用户提供了一个手动操作界面。换句话说，DBMS只执行人类指示的操作。
Level #1:
        下一个自治级别提供了辅助工具，为一些DBMS子系统向用户推荐改进的配置。用户必须（1）选择要应用的建议，（2）决定何时应用这些建议，以及（3）监视DBMS的之后的行为。这些工具通常需要用户准备样本工作负载和/或部署第二个数据库副本，以评估新的建议。该级别的示例包括基于工作负载跟踪提出旋钮配置或索引选择的自调整工具。
Level #2:
        这种自治级别假设有一个最小的控制系统，与用户协作配置一些DBMS子系统。决策的主动性在DBMS和用户之间混合。这种自主性向用户暴露了复杂的问题，因为用户可能会发布与DBMS控制组件冲突的更改。这种系统的一个例子是2008年推出的IBM DB2原型。该系统使用外部控制器中的现有工具，当超过资源阈值（例如缓冲池命中率）时，触发更改或通知DBA。它仍然需要一个人来选择优化，并偶尔重新启动DBMS。
Level #3:
        下一个层次包括局部自治，其中每个子系统都可以在没有人工指导的情况下进行适应，但它们之间没有更高层次的协调或长期规划。用户决定启用/禁用这些组件的自主性。例如，一些DBMS支持自动内存分配（例如Oracle、IBM DB2）或自动创建/删除索引（例如Microsoft在Azure中的自动索引）。我们还认为，Oracle的自主数据库即服务产品就是这一级别的例子[2]。该服务要求用户选择其应用程序是事务性工作负载还是分析性工作负载。
然后，它使用Oracle现有的辅助工具（级别#1）来处理常见的调优活动，但它们是独立管理的。
Level #4:
        在定向级别，系统管理其所有子系统，用户仅为全局配置问题提供高级指导。该方向包括关于未来工作负载需求的提示，以便DBMS能够为长期决策（例如容量规划）做好准备。例如，用户可以选择操作来开始扩展DBMS的部署，以准备即将到来的流量激增。我们还预计DBMS在这个级别上仍然需要来自人类的特定于会话的提示。DBMS足够智能，能够识别何时向人类寻求帮助。
Level #5:
        最后，在最高的自治级别上，DBMS是完全独立的（即自驱动），因为它在所有子系统之间进行整体协调，而不需要用户的指导。它在决策中考虑未来的工作负载，并支持所有不需要外部价值判断的调优活动。对于每个计划或部署的操作，DBMS还提供了人类可以理解的解释，解释了它为什么决定部署该操作。例如，DBMS报告其对动作完成时间、资源消耗和对系统性能的好处的估计。自动驱动DBMS是否仍应允许人类配置系统的各个方面仍存在争议。DBMS的规划组件如何响应此类人工输入是一个困难且尚未解决的问题。

3 NOISEPAGE ARCHITECTURE

        我们现在描述NoisePage的自驱动架构，该架构旨在实现最高级别的DBMS自治（级别#5）。我们使用自动驾驶汽车的类比来解释我们的系统设计。在高层，自动驾驶汽车由（1）感知系统、（2）移动模型和（3）决策系统组成。感知系统观察道路状况并预测未来状态，例如其他车辆的运动轨迹。机动性模型估计了车辆在相关操作条件下的控制行为。最后，决策系统使用其感知数据和模型估计来选择行动以实现驾驶目标。

Figure 1: NoisePage Architecture – NoisePage’s self-driving architecture consists of an on-line workload forecasting component, an off-line behavior modeling component, and an on-line action planning component.
        如图1所示，NoisePage的自动驱动架构由三个类似的组件组成：（1）工作量预测，（2）行为模型，和（3）行动规划。NoisePage的在线工作负载预测组件根据应用程序过去的到达率预测应用程序在多个时间范围内的未来查询。NoisePage然后使用这些预测及其离线生成的行为模型来预测部署行动的成本和收益，而无需昂贵的探索性测试[。通过这种成本/收益估计，DBMS的在线行动规划组件选择其认为将改善系统目标函数（例如延迟、吞吐量）的行动。NoisePage然后自动应用这些操作，监视其行为，并重复该过程。所有这些都是在没有任何人为干预的情况下发生的。
        我们现在更详细地讨论这三个组成部分：

Workload Forecasting:
        预测允许DBMS为未来的工作负载做好准备，就像自动驾驶汽车使用激光雷达和摄像机预测前方的路况一样。如果DBMS只考虑过去的工作负载，它将无法及时为应用程序工作负载中即将发生的变化做好准备，这些变化需要很长的部署时间。如果DBMS在不合适的时间应用操作，则在不知道未来工作负载的情况下应用操作也会增加资源争用。
        NoisePage使用工作负载跟踪和数据库统计数据生成预测模型。当NoisePage从客户端接收到工作负载时，它将工作负载的查询到达率和参数样本以聚合间隔（例如每分钟）存储在内部表中。它定期将这些数据发送到其训练组件过程，以建立预测模型。这些模型在不同时间段（例如，一小时、一天、一周）的聚合时间间隔内预测每个查询的未来到达率。NoisePage还使用查询模板化、到达率模式聚类和一系列时间序列预测方法来高效地训练这些模型并准确预测各种工作负载模式。

Behavior Modeling:
        与自动驾驶车辆使用模型来估计转动方向盘的效果类似，自动驾驶DBMS也使用行为模型来估计和解释潜在动作如何改变系统性能。这是一个挑战，因为DBMS是一个复杂的软件，可能需要高维模型，这可能需要大量的训练数据，并使调试更加困难。多核环境中的并发操作使DBMS行为建模更加复杂。
        为了解决这些问题，NoisePage将DBMS分解为小型独立操作单元（OU），然后分别对其进行建模。每个OU模型表示系统中的一些内部任务（例如，扫描表、构建索引）。OU分解意味着每个模型都是低维的，只需要适量的训练数据。NoisePage还使用了一个额外的干扰模型来捕获并发OU之间的资源竞争。它使用一组专门的离线训练模型，充分训练每个OU，为OU模型生成训练数据。它通过交叉验证，在广泛流行的ML算法中为每个模型选择最佳ML算法。

Action Planning:
        在给定工作量预测和模型估计的情况下，自驱动DBMS需要决定何时应用哪些操作来优化目标。为了使DBMS完全自动化，该规划步骤必须（1）考虑当前和未来的工作负载，以在问题发生之前解决问题，（2）解决所有系统约束（例如，最大内存消耗），以及（3）解释过去和未来的计划动作，这对检查、调试和审计很重要。NoisePage使用控制理论中的标准方案，称为滚动时域控制（RHC），以确保这些要求。虽然RHC允许系统执行多阶段规划，但求解RHC的连续、离散和约束优化问题的计算成本很高。因此，NoisePage采用蒙特卡洛树搜索（MCTS）规划方法来提高RHC的效率。MCTS探索到规划范围内的许多随机行动序列，并选择最佳序列。它可以潜在地平衡规划成本和质量之间的权衡。先前对人工智能系统的研究已成功使用MCT，如AlphaGo。
        在下一节中，我们将讨论构建这种自驱动DBMS的设计原则。由于这是一个活跃的研究领域，因此存在许多未解决的问题。我们将不讨论求解它们的ML方法。相反，我们的重点是如何构建一个易于自主规划和操作的数据库管理系统。表2总结了我们在第4节至第6节中介绍的这些原则。
        我们的讨论有两个主要主题。首先是关于如何公开有关DBMS的有用信息。这包括应用程序的工作负载和有关DBMS内部的指标，以及如何控制其行为。下一个问题与DBMS如何部署操作有关。理想情况下，每个操作都会快速完成，对性能影响很小，但这并不总是可能的。这两个问题对于使DBMS能够在性能没有剧烈波动的情况下进行自我管理都很重要。实现这一点很困难，因为DBMS部署是不稳定的，而且调优它们的解决方案空间很大。因此，这些设计原则通常是减少DBMS必须考虑的选择数量，以及使其更容易探索配置和了解其环境的方法。

4 ENVIRONMENT OBSERVATIONS

        大多数DBMS善于收集有关其环境的信息，例如工作负载（第4.1节）和内部运行时指标（第4.2节）。问题是数据过多，难以将信号与噪声分离。此外，许多DBMS也不公开有关其硬件的信息，以实现跨操作环境重用训练数据（第4.3节）。自动驱动DBMS必须维护该信息的历史记录，而不是仅保留最新快照；保留较旧的数据可以提供有关其用于学习的系统先前状态的上下文。我们将在本节中讨论如何解决这些问题。

4.1 Workload History

        自动驱动DBMS根据其预测模型预测系统未来需要的内容选择操作。这种预测面临的挑战是环境是动态的（即工作负载、数据库物理设计和旋钮配置随时间变化）。即使这些因素是静态的，数据库的大小也可能增长或收缩。这种可变性意味着，在查询执行期间预测低级指标（例如CPU利用率或读/写元组）将导致不稳定的模型，因为这些模型将随着DBMS配置的演变而变化。
        更好的方法是预测查询的到达率，然后推断它们的预期资源利用率。为此，自动驱动DBMS记录其执行的事务和查询的工作负载历史。历史记录中的每个条目都包含调用的逻辑操作（例如SQL）及其执行控制文本。该上下文包括客户端元数据、查询计划提示和特定于会话的配置旋钮（第5.1节）。系统还跟踪每个查询的完成状态，例如其执行时间以及其父事务是否中止。记录这些附加信息可以确保DBMS能够正确地近似查询在其预测中的执行方式。
        收集此历史的最简单方法是让DBMS跟踪它执行的每个查询。然而，这样的策略将为大型应用程序消耗相当大的存储空间，并产生巨大的运行时开销。此外，历史记录的许多条目将是冗余的（例如，具有不同常数的同一查询），这可能会导致ML模型拟合过度。减少这种开销的两种方法是（1）采样和（2）聚合。对于前者，DBMS应该在事务级别进行采样，以确保事务中的每个查询都包含在历史记录中。
        减少历史记录的另一种方法是聚合轨迹。一种常见的技术是通过删除文字来提取SQL查询的逻辑结构，然后将查询与相同的逻辑结构结合起来。除逻辑结构提取外，还有更先进的技术。例如，Microsoft提出通过使用特定于应用程序的距离函数搜索冗余SQL语句来压缩工作负载。为自驱动DBMS明确设计的另一种方法是使用查询时间模式之间的相似性来压缩工作负载。

4.2 Runtime Metrics

        DBMS的指标是记录其内部运行时组件活动的性能计数器。工程师添加这些指标，使DBA和监视工具能够观察系统的行为并诊断问题。DBMS还在内部使用它们来触发维护操作，例如MVCC系统中的垃圾收集和LSM系统中的压缩。自驱动DBMS根据估计不同条件下行动的成本/效益的指标来训练模型。指标还指导系统提出/删减候选操作。
        有两类指标。第一种是累积指标，计算自某个时间点以来发生的事件数。例如，DBMS可以记录自启动以来从磁盘读取的页面数。另一类是聚合度量，记录一个时间窗口内事件的平均数量。正如我们现在所描述的，需要仔细考虑暴露度量，以便ML算法具有适当的数据：

Meta-Data Tags
        每个指标都应该在结构化元数据标记中记录其收集数据的子系统。它们应该匹配修改这些子系统的动作标记。类似地，如果指标衡量硬件资源的某些方面（例如CPU利用率、磁盘I/O），那么它还应该包括记录此信息的标记。这些标签有两个目的。首先，它们消除了DBMS训练单独模型的需要，以确定哪些指标受哪些操作的影响。DBMS仍然需要了解操作如何影响这些指标，以及它们如何影响目标函数，因为每个工作负载都会有所不同，并且会随着时间的推移而变化。标记的第二个好处是，系统可以使用它们为其决策生成人类可以理解的解释。这些信息对于向DBA灌输自驱动DBMS正常运行的信心非常重要。

Variable Fidelity:
        与元数据标记相关的是DBMS动态调整其收集度量数据的频率的能力。DBMS可能希望暂时为DBMS的一部分启用细粒度度量数据，而不必为整个系统启用。这种保真度的提高并不意味着DBMS能够对通常处于休眠状态的计数器进行数据收集。相反，DBMS收集其固定指标集的更多样本。增加样本数量会为系统中对其模型信心不足或在部署操作时表现出意外行为的部分生成更多数据。

Sub-Components:
        一些DBMS支持单独的子组件配置。这可以是对数据基对象（例如表、索引）的更改，也可以是动态创建新的依赖旋钮的旋钮。对于前者，一些DBMS支持每个表的定制存储策略。作为动态旋钮的一个示例，可以在IBM DB2中创建多个缓冲池，DBA可以分别对每个缓冲池进行调优。必须公开每个单独组件的met RIC。否则，DBMS很难推断一个动作是如何影响该组件的。算法可以推断子组件对DBMS目标函数的影响，但必须保持所有其他变量不变（例如，工作量、硬件资源）。

4.3 Hardware Capabilities

        将硬件配置文件与DBMS的指标结合起来，使ML组件能够跨部署重用训练数据。如果没有这一点，即使是同一个应用程序，系统也必须为每个新部署或升级收集新的训练语料库。如果DBMS只有旧的训练数据，而没有硬件上下文，那么其模型无法区分性能的意外变化（即使是积极的）是由于其操作还是由于硬件不同。这在云环境中很重要，因为在云环境中，并非所有资源的实例类型之间的性能差异都是一致的。例如，与其他内存较少但内核较多的新CPU相比，Amazon提供了使用旧CPU且内核较少的大型内存实例。如果在将数据库迁移到这个较大内存实例后查询速度较慢，那么DBMS必须确定这是由于最近应用的操作还是因为CPU较慢。
        硬件配置文件是其规格和测量性能的组合。例如，CPU的规格将包括内核的数量。性能测量是针对每个硬件资源的合成基准测试（例如，磁盘的fio，CPU的bogomips）。一些数据库管理系统已经使用微基准来增强查询优化器的内部成本模型。由于性能随时间而变化，特别是在云环境中，系统将希望定期运行这些。它还将使用与上述指标相同的标签对每个硬件组件的测量进行分类。
        另一个挑战是如何在新机器的能力未知的弹性环境中支持资源扩展。例如，如果DBMS想要将数据库迁移到更快的机器上，那么在决定是否移动之前，需要估计它对目标函数的影响程度。为此，系统的规划组件需要有关可用硬件的训练数据。这也是指标元数据标记有用的地方：由于硬件更改是多维的（例如内存、CPU、磁盘），这些标记使系统能够识别哪些资源利用不足/过度，以便选择适当的资源进行收缩/扩展。这是一个很好的例子，说明了基于云的DBaaS供应商如何比自己运行自驱动DBMS的组织具有优势，因为供应商可以在各种配置上进行更多部署。

5 ACTION META-DATA

        在本节中，我们讨论了公开有关操作的元数据的重要性。可以通过将元数据硬编码到调优算法中来实现此信息。然而，我们认为，更好的软件工程是将这些信息作为一级概念与DBMS内部的操作一起维护。这可以确保元数据（更准确地）反映DBMS的内部，因为执行操作的开发人员也将提供元数据。

5.1 Configuration Knobs

        DBMS的配置旋钮控制其运行时操作的各个方面。这三类旋钮是（1）资源、（2）政策和（3）位置。第一类中的旋钮指定系统用于任务的资源量。这些可以是固定组件（例如垃圾收集线程的数量）或动态活动（例如每个查询使用的内存量）。策略配置旋钮控制DBMS在某些任务中的行为。例如，当事务提交时，旋钮可以控制DBMS是否将写前日志刷新到磁盘。最后，位置旋钮指定DBMS在何处找到其需要的资源（例如，文件路径）以及如何与外部世界交互（例如，网络端口号）。
        我们现在描述了DBMS为其ML算法必须公开的元数据。

Untunable Knobs:
        任何需要人类知识才能对正确决策作出价值判断的旋钮都不应暴露于自主组件。它们应该清楚地标记为不可修改，以便系统不会修改它们。有一些明显的情况，例如定义文件路径的位置旋钮，如果设置不正确，系统将无法运行。
        错误设置其他策略旋钮可能不会导致系统无法运行，但会更微妙地影响数据库的正确性或安全性。我们发现的最常见的例子是，是否需要DBMS在提交事务之前将事务的日志记录刷新到持久磁盘。如果ML算法发现改变这个旋钮可以改善目标函数，那么他们很可能会做出改变。但这意味着，如果发生崩溃，DBMS可能会丢失最近提交的事务的数据。这种权衡可能适用于某些应用程序，其中损失最后几毫秒的交易不是问题（例如，记录网站点击），但对于其他应用程序，这种损失是不允许的（例如，金融交易）。DBMS无法知道应用程序的正确选择是什么，因为它需要一个人来决定其组织中允许的内容。

**Value Ranges: **
        旋钮的约束值范围（数值的最小值/最大值或分类值的枚举）对于安全的自动化工具至关重要。如果没有这些信息，该算法可能会通过错误的值彻底崩溃系统。更糟糕的是，系统可能会在假设之前的操作成功并对当前数据库状态负责的情况下继续运行，从而导致拜占庭式故障。让DBMS公开这些信息可以避免开发人员将这些信息硬编码到ML算法中。

Scope:
        当DBMS更改旋钮时，每个客户机都应该立即或很快看到该更改（例如，下一个查询）。我们不知道所有会话都不应立即观察到任何旋钮变化，即使该客户端正在执行事务。据我们所知，这对系统收集的训练数据没有不利影响。
        一些DBMS还允许客户端覆盖旋钮的全局值，并为其会话配置它们。对于这些旋钮，DBMS应在其目录中表示旋钮是否支持每会话更改。支持每会话旋钮的自动调优增加了问题的复杂性，因为它需要DBMS构建额外的模型（1）预测客户端的执行模式，以及（2）根据其行为对新连接进行分类。因此，我们认为第一个自驱动DBMS不太可能提供每会话调优。

Tuning Deltas:
        系统开发人员设计的大多数旋钮允许DBA将其设置为任意值。例如，可以将控制DBMS缓冲池大小的旋钮的值设置为机器上某个下限和内存总量之间的任意字节数。这种灵活性是有代价的，因为它增加了每个旋钮的解决方案空间。当单个旋钮有如此多的选择时，将有一个很大的值范围，其对目标函数的影响未知。这意味着ML组件在能够收敛到良好配置之前需要更多的训练数据。在控制缓冲池内存大小的旋钮的情况下，当大小为1.0 GB时，DBMS可能已经有关于系统行为的数据，但当其设置为1.01 GB时，可能没有。这两种设置之间的性能不太可能有差异。
        为了帮助降低该解决方案空间的复杂性，自驱动DBMS应该提供关于如何在给定范围内增加旋钮的提示。也就是说，与DBMS部署为旋钮设置精确值的操作不同，该操作以固定的量递增或递减旋钮。使用增量的另一个优点是，它们可能在配置之间提供更平滑的过渡，并避免较大的性能波动。
        为了进一步减少DBMS潜在配置状态的数量，这些增量动作还应根据旋钮的当前值改变变化幅度。例如，对于大小小于1 GB的缓冲池，增量量为10 MB，而对于大小小于1 TB的缓冲池，增量量为1 GB。这里的见解是，较小的增量之间的差异在具有少量RAM的机器上更大，而对大型内存机器的影响很小。

**Meta-Data Tags: **
        每个旋钮都应该包含有关其影响系统哪个部分的元数据。规划组件可以将这些标记与度量标记（第4.2节）配对，以提供关于在给定系统当前状态下优先考虑哪些操作的提示。

5.2 Dependencies

        DBMS还应该跟踪动作之间的交互方式。当一个操作启用/禁用系统中的某个功能，而另一个操作控制该功能的行为时，就会存在这种依赖关系。除非DBMS部署第一个操作，否则第二个操作将无效。此依赖关系信息使DBMS能够避免选择修改依赖组件的操作，除非设置了其父组件。同样，这减少了DBMS必须考虑的操作数量。正如我们在下面所描述的那样，存在一些依赖关系，这使得很难对系统对更改的反应进行建模。

No Special Knob Values:
        跟踪依赖项消除了对使用特殊值（例如，0，-1）执行与旋钮正常操作不同的操作（例如禁用功能）的旋钮的特殊处理的需要。相反，DBMS应该提供一个单独的布尔旋钮来控制它。该旋钮标记为不可开启，然后系统仅在第一个旋钮启用时检查从属旋钮。
        还有其他具有特殊值的旋钮，这些旋钮不影响正确性，但会使DBMS的行为建模更加困难。例如，特殊值“0”可能允许DBMS将其自身的旋钮值分配给某个默认值或预期最佳值。规划组件可能永远不会探索该旋钮的此类设置（即使它可能是最优的），因为其模型将预测性能会随着旋钮值收敛到零而下降。或者他们会认为值越低越好，即使相反的情况成立，这会导致优化搜索朝着错误的方向发展。我们再次主张，自动驱动DBMS不应使用此类旋钮。

No Hidden Dependencies:
        与特殊值类似，操作不应具有隐藏的依赖项。也就是说，DBMS的一部分的行为不应取决于另一个子系统的配置。Postgres提供了这个问题的示例。DBMS提供了一个旋钮，用于控制系统垃圾收集器允许使用的最大内存量¹。如果操作将此旋钮设置为特殊值（即-1），则运行时实际旋钮值为另一个旋钮²的值。只有通过阅读文档才能发现它们的隐含依赖性。
        除了删除本例中旋钮的特殊值外，最好将两个旋钮解耦。同样，这种依赖性大大增加了在不同条件下建模系统行为的复杂性，因为规划组件必须考虑两种操作模式（即一种是链接的，另一种是分离的）。如果确实存在两个旋钮应该相等的场景，那么系统将在拥有足够训练数据的情况下发现这一点。

Dynamic Actions:
        更复杂的依赖关系是（1）启用其他操作的操作或（2）DBMS仅在创建对象时公开的操作（例如，表特定的旋钮）。DBMS必须提供元数据，指示动作部署创建或启用了哪些旋钮。
        在自动驱动DBMS中支持的最简单的动态操作是“反转”操作，它撤消对先前部署的操作的修改。除旋钮和资源操作外的所有操作都需要反转操作。例如，创建索引的物理设计操作的反转就是删除该索引。如果将旋钮配置和资源缩放操作的更改定义为增量而不是离散值，则不需要它们。
        要了解非反转动态操作的问题，请考虑向表中添加索引的操作示例。DBMS部署此操作后，将公开（1）修改该索引旋钮的操作和（2）在查询计划中安装提示以强制其使用该索引的操作。可以将后一种操作重构为通用形式，以删除这种依赖关系。也就是说，它不是为特定索引安装提示的操作，而是选择最近创建的索引。这可能是更好的方法，因为目标查询计划将随着时间的推移而变化。但是，处理调整新系统组件或数据库对象的第一组操作更具挑战性。

5.3 Deployment History

        DBMS需要维护每个动作部署的历史记录。该记录大于DBMS启动/完成操作的时间戳。它还包括来自DBMS子系统的内部指标，以及部署时DBMS状态的表示。该状态是DBMS的旋钮、物理设计、硬件、查询计划提示，以及当前工作负载和数据库内容的简洁编码。
        部署历史提供了几个好处。最重要的是，它提供了一个日志，以帮助规划算法推断系统如何达到其当前状态。这对于启动行动以应对性能下降或SLO违规非常重要。最后，规划组件可以推断出一个可读的解释，解释为什么从这种编码中选择动作。这通过允许DBA检查系统的推理和行为来提高透明度。

6 ACTION ENGINEERING

        自动驱动DBMS使用前几节中讨论的环境数据和动作元数据来选择动作。部署操作时，DBMS必须确保两个要求。首先是最小化在目标函数上部署操作的成本。这意味着没有停机时间，也没有性能上的剧烈波动。最后，除了DBMS目标函数的变化外，操作不应导致应用程序观察到操作部署的任何影响。这些影响包括错误的查询结果、丢失/损坏的数据和客户端断开连接。
        我们现在讨论DBMS如何支持高效且信息丰富的动作部署

6.1 No Downtime

        对于自动驱动DBMS来说，最重要的是能够在没有不可用期的情况下应用更改。这种停机可能是在操作完成之前阻止查询执行（例如，在DBMS构建索引时停止查询访问表），也可能是在更改生效之前必须重新启动DBMS。使系统脱机以应用更改使规划更加困难，因为当允许DBMS重新启动时，必须由人指示DBMS。
        我们不知道任何允许自动驱动DBMS自动调优的系统修改需要这样的停机时间。我们认为，这一限制完全是由于工程因素，而不是一些基本的科学原因。当然，在部署期间会有大量修改降低性能（例如压缩），但系统可以在其估计中考虑到这一点。
        如果DBMS无法在没有停机的情况下部署操作，则必须在其成本估算中包括预期停机时间。它还需要区分阻止停机和重启。重新启动DBMS尤其有害，因为某些操作可能需要额外的重新启动工作，这使得DBMS在更长的时间内不可用。这些重启时间也可能取决于当前DBMS的配置。例如，假设将MySQL日志文件大小³更改为5GB。如果此旋钮的先前设置为10 GB，则DBMS将在重新启动时压缩日志文件。但是，如果之前的设置是1 GB，那么DBMS不需要做任何事情。如果无法避免重新启动，则DBMS可以根据需要执行的工作及其硬件功能，提供有关其预期恢复时间的提示。
        停机的另一个问题是，DBMS可能还必须请求人员允许重新启动系统，以避免高峰时间出现停机。这使规划变得复杂，因为算法必须在估计中包含日期和时间，以决定是否允许选择需要重新启动的操作。

6.2 No Self-Managing Components

        近年来，一些商业DBMS供应商推出了“自我管理”子系统，这些子系统在运行时不需要人工对其进行调优。例如，Oracle提供了一个内存分配器，它使用启发式自动确定其组件（例如缓冲池、查询缓存）的内存分配。一些基于云的DBaaS供应商，如Microsoft SQL Azure，提供了自动安装表索引的工具。每个子系统都维护自己的模型，然后独立决定何时部署动作。
        独立的自我管理子系统的问题是，如果系统试图进行整体规划，它们会引入难以在ML模型中捕捉的外部性。考虑一下Oracle自我管理内存功能的场景。假设分配器最初为查询结果缓存分配少量内存，并为缓冲池分配大量内存。然后，DBMS选择构建索引，因为缓冲池中的内存压力很低。但是，分配器自己决定增加结果缓存大小并减少缓冲池大小。通过这种更改，现在可用于存储索引和数据页的内存更少，从而增加了查询执行期间的磁盘I/O量。因此，DBMS刚刚添加的索引现在是一个糟糕的选择，因为它无法控制系统中的另一个更改。
为了避免这个问题，DBMS必须在其模型中包括分配器配置更改的可能性，这会增加其维数和复杂性

6.3 Observable Deployment Costs

        除了估计一个动作在部署时如何改进目标函数外，DBMS的行为模型还估计部署每个动作的成本。该成本包括（1）DBMS在部署期间使用的资源量（例如CPU、内存），（2）目标函数的更改，以及（3）部署的估计耗时。系统为每个动作调用分配一个唯一标识符，使其能够跟踪导致其配置更改的原因。参与部署操作的每个子系统都会记录其在操作期间使用的物理资源量。然后，DBMS在操作完成后将这些信息聚合在一起，并将其存储在其历史记录中。累积资源使用量是DBMS（例如，保持的锁存）或OS（例如，CPU等待时间）测量值的组合。由于DBMS执行操作的频率不如查询，因此为每个操作收集这些数据的开销可以忽略不计。
        DBMS一次只能部署一个操作，以便训练数据准确反映其执行成本。然而，不知道如何自动确定DBMS在部署下一个操作之前应该等待的最佳时间。等待时间越长，对当前配置就越有信心。等待时间越短，就越难确定是什么操作导致了问题。
        DBMS还必须为规划组件提供通知API，以识别动作部署何时开始和完成。如果没有这一点，则更难确定性能下降是由于部署操作的成本（例如，调整磁盘上日志文件的大小）还是因为这是一个错误的选择。

6.4 Aborted Actions

        处理中止动作的两个首要原则是DBMS（1）不允许部分动作，（2）不能保留部署中的观察数据。前者的一个例子是将分配给子系统的内存量减少100 MB，但无论出于何种原因，系统只能将其减少50 MB。DBMS不允许这样做，因为这样内部模型将无法准确反映系统的状态。部分动作也可能等效于另一个动作，但系统会将收集的训练数据错误地归因于原始动作。类似地，DBMS必须丢弃在拒绝和失败操作期间收集的数据。这是因为很难跟踪DBMS的子系统在失败之前的部署中可能会走多远。
        接下来，我们将讨论DBMS应该如何处理导致其在部署期间中止操作的场景。

Rejections:
        DBMS可能会尝试部署无法完成的操作。例如，假设DBMS的配置将一个线程分配给其后台维护池（例如垃圾收集）。然后，系统选择一个减少该池中线程数的操作。此操作无效，因为池必须至少有一个线程。因此，DBMS应拒绝该操作，并记录其无法完成请求。理想情况下，DBMS还应提供附加信息，例如是否由于短期问题（例如，没有空闲线程）而拒绝了操作，或者是否是更持久的问题（例如，内存不足）。

Failures
        未能完成的操作不同于被拒绝的操作，因为否则该操作将完全成功完成。但同样，DBMS在部署期间收集的训练数据是“受污染的”，因此必须丢弃。此类故障可能是由于逻辑问题（例如，在DBMS尝试删除索引之前，一个人删除了索引）或硬件故障引起的。当出现瞬态故障时（例如，网络在动作期间短暂停机），后者更难处理。

6.5 Adjustable Deployment Resources

        最后，DBMS必须支持在不同的资源使用水平下执行相同的操作。这些资源基于系统的硬件组件：（1）CPU线程数，（2）内存量，（3）磁盘带宽和（4）网络带宽。这允许DBMS根据截止日期或当前负载选择更积极的部署策略。例如，DBMS可以在需求较高的时候仅使用一个线程构建索引，以避免对应用程序的查询造成过多干扰。但在夜间，当DBMS有更多空闲周期时，它可以使用八个线程更快地构造索引。该指数可以针对当前工作量或系统为第二天工作量做准备的一部分。在后一种情况下，DBMS还可以运行模拟，以确定添加该索引是否是正确的决策。
        选择让动作使用多少资源是困难的，因为DBMS必须小心，不要违反SLO约束。另一个复杂因素是，这些资源分配有时是DBMS允许使用的数量的上限，而不是它实际使用的内容。例如，即使一个操作可以在四个线程上运行，也不意味着DBMS在部署期间使用四个线程。这使得准确预测总资源使用量变得困难。因此，我们预计第一个自动驱动DBMS将使用固定分配来简化这个问题。

7 RELATED WORK

        据我们所知，从来没有一个完全自治的DBMS。在21世纪初，有几个突破性的解决方案朝着这个目标前进，最著名的是微软的SQL Server AutoAdmin和IBM的DB2 Database Advisor。其他人提出了RISC风格的DBMS架构，该架构由可互操作的组件组成，使其更容易推理，从而控制整个系统。Teradata的主动系统管理为DBA编写自动许可控制规则提供了工具。但十多年后，所有这些研究都被降级为独立的工具，以帮助DBA，而不是取代他们。
        最接近全自动DBMS的尝试是IBM从2008年开始的DB2概念验证。该系统使用外部控制器和监视器中的现有工具，每当超过资源阈值（例如死锁数）时，这些工具就会触发更改。这个原型仍然需要人工DBA来选择调优优化，并偶尔重新启动DBMS。与自动驱动DBMS不同，它只能在问题发生后做出反应，因为系统缺乏预测。
        由于其规模和复杂性，自动化在云计算平台中更为常见。微软似乎再次引领了这一领域的研究。他们的Azure服务根据内部遥测数据模拟DBMS容器的资源利用率，并自动调整分配以满足QoS和预算约束。还有一些控制器用于应用程序在云中执行黑盒配置。2017年，甲骨文宣布推出自己的“自动驾驶”DBaaS；虽然很少有关于其实现的公开信息，但我们从他们的开发人员那里了解到，他们正在托管环境中运行以前的调优工具。
        最近，有人尝试将深度学习与强化学习（RL）相结合，以帮助处理DBMS运行时架构的特定部分。例如，研究人员提出了用于查询优化、索引调优、基数估计、分区和一般调优选择的RL模型。其他形式的深度学习也被应用于基数估计和查询性能预测。替代模型包括图嵌入和分析模型。这些方法都局限于静态操作环境中的单个决策问题，并且在其模型中不考虑长期预测。
        软件工程界的一系列研究旨在开发通用框架，在任意软件中实现自适应能力。这些框架通过使用探测器收集的信息执行操作，充当目标系统的外部控制器。最有影响力的项目之一是彩虹框架。它通过将通用适应基础设施与系统特定知识分离，支持跨系统重用适应策略和基础设施。软件开发人员使用一种称为Stitch的语言来表示适应性策略并表达业务目标。然后，该框架选择在给定上下文中具有最佳效用的策略。也有关于主动自适应、对抗环境中的自我保护和保持鲁棒性的工作。这种框架的目标是跨不同的软件系统重用自适应基础设施。然而，人类仍然使用其领域知识为其系统指定策略。这包括系统在什么条件下可以采取哪些行动，以及这些行动在多个维度上的预期成本/收益。

8 CONCLUSION

        自驱动DBMS将使组织能够部署比今天更复杂的数据库应用程序，并以更低的硬件和人员成本进行部署。实现完全自治（即第2节中的第5级）有两个研究领域：（1）用于价值和策略功能的新型ML方法和（2）适于自主控制的新型DBMS体系结构。这些努力是共生的；一个人如果不了解另一个人，就无法在一个人身上取得进步。因此，本文根据我们在NoisePage数据库管理系统中的经验提出了设计原则。
        最后一点是，我们相信自驱动DBMS不会取代DBA。相反，我们设想自治系统将减轻它们繁重的低级调优负担，并允许它们从事更高层次的任务，如数据库设计和开发。

ACKNOWLEDGMENTS

        这项工作得到了国家科学基金会（IIS-1846158、III-1423210、DGE-1252522）、谷歌研究基金和阿尔弗雷德·P·斯隆研究奖学金项目（部分）的支持。

VGltIEtyYXNrYSBCZXRyYXllZCBNZQo=