cs.cmu.edu/~pavlo/blog/2018/04/what-is-a-self-driving-database-management-system.html#footnote-cidr
一些组织和个人错误地将他们的系统标记为“自动驾驶”。真正的自动驾驶数据库管理系统（DBMS）会自动
（1）决定使用什么样(what) actions 来优化自己
（2）决定何时(when)部署这些行动
（3）从这些actions中学习(强化学习？)——所有这些都无需任何人为干预。
自 1970 年代开始，使用 DBMS 来减轻应用程序开发人员的数据管理负担是关系模型和声明式编程语言（例如，SQL）的最初卖点之一。采用这种方法，开发人员只需编写一个查询，指定他们想要访问的数据。然后由 DBMS 找到执行该查询的最有效方法；开发人员不需要担心使用什么算法，如何存储和检索数据，或如何安全地交错更新数据的操作。DBMS 最了解数据库及其访问方式，因此始终处于做出这些决策的最佳位置。
同时，一些组织希望 DBMS 能够为其应用程序选择一个整体策略，以处理管理和优化其数据库的所有方面。这些在 1970 年代被称为自适应系统。这些早期系统的设计思想和现代的tools的工作方式基本一样：（1）系统收集有关应用程序如何访问数据的指标，然后（2）它根据代价模型来搜索要进行哪些更改以提高性能。
早期的自适应DBMS侧重于物理数据库设计，特别是索引选择。事实上，Andy的导师的导师在1976年写了第一篇关于自动索引选择的论文。党史研究此问题的其他公司包括 IBM、Berkeley 和 CMU。这种趋势一直持续到 1980 年代（IBM 的 System R 的 DBDSGN 项目）。
除了索引选择之外，另一个被广泛研究的数据库设计问题是数据分区。在 1990 年代，随着分布式/并行 DBMS 的兴起，对自动数据库分区和数据放置方法的需求变得更加流行。关于这个主题的主要论文来自(1) DeWitt’s group at?Wisconsin?and (2)?Toronto/IBM.
1990 年代末和 2000 年代是自动 DBMS 的“黄金时代”。这是对所谓的“自调优”（也称为“自动调优”）数据库系统的第二波研究。最前沿的是 Microsoft Research 的 AutoAdmin 项目的开创性工作。他们构建了advisor tools来针对workloads帮助DBA选择最优的indexes、物化视图以及分区schemes。AutoAdmin 的主要贡献是开发what-if API(能够在假设条件下计算cost)。这样，优化工具就可以为潜在的设计决策（例如，要添加的索引）创建虚拟catalog entries，然后使用查询优化器的成本模型来确定该决策的好坏。换言之，你可以告诉optimizer数据库具有一个索引，即使实际上没有这个索引。然后查看optimizer是否为每个查询选择了该索引，以确定添加该索引是否是一个好主意。这允许tools使用现有 DBMS 的代价模型估算，而不必创建第二个外部（可能因此不够准确）代价模型来做出设计决策。其他主要的数据库供应商也有类似的自调优物理设计项目（例如，IBM 的 DB2 Designer），但 Microsoft 是最多产的。
2000 年代还开始了对自动旋钮配置(automating knob configuration)的研究。这些旋钮允许 DBA 控制 DBMS 运行时行为的各个方面。例如可以借此来设置系统给data caching 分配多大内存，以及txn log buffer的内存大小。与物理设计工具不同，配置工具不能使用查询优化器的内置成本模型。这是因为这些模型会生成执行特定查询的工作量的估计值，并旨在比较固定执行环境中的替代查询执行策略。
所有主要的 DBMS 供应商都有自己专有的旋钮调整工具，这些工具支持的自动化程度各不相同。在 2000 年代初期，IBM 发布了 DB2 Performance Wizard，它向 DBA 询问有关其应用程序的问题（例如，它是 OLTP 还是 OLAP），然后根据他们的回答提供旋钮设置。IBM 后来发布了一个带有自调优内存管理器的 DB2 版本，该管理器使用启发式方法来确定如何将 DBMS 的内存分配给其内部组件。Oracle 开发了一个类似的系统来识别由于配置错误而导致的瓶颈。更高版本的 Oracle 包括一个 SQL 分析器工具，用于估计配置修改的影响。此方法也已用于 Microsoft SQL Server。
使用上述所有工具仍然是一个手动过程：DBA 提供示例工作负载，然后该工具建议一个或多个操作以提高性能。仍然由 DBA 来决定这些建议是否正确以及何时部署它们。IBM 认识到需要人类专家来做出这些最终决策是有问题的，因此他们发起了一项为 DB2 构建自主组件的计划。其中最著名的是 LEarning Optimizer （LEO） 和自适应直方图集 （SASH）。基本思想很简单：DBMS 的成本模型在选择查询计划时会根据它收集的统计信息进行估算。然后，当系统执行查询时，它会检查这些估计值是否与实际数据匹配。如果没有，则系统具有反馈循环机制，可为成本模型提供校正。这似乎正是人们在系统中想要的，但我还没有遇到任何 DB2 DBA 说它像宣传的那样工作。至少有三个 DBA 告诉我，每当他们第一次部署新的 DB2 数据库?[3]?时，他们总是关闭此功能。
在消除人类依赖方面，对物理设计的某些方面也进行了探索。最值得一提的是 Stratos Ideros 的出色**database cracking**工作。
随着云计算的兴起，自治系统的新篇章随之而来。由于其规模和复杂性，在此类云平台中更需要自动化。所有的云数据库提供商都使用自定义工具来控制操作员级别的部署（例如，租户放置）。Microsoft似乎再次引领了这一领域的研究。其 Azure 服务根据内部遥测数据对 DBMS 容器的资源利用率进行建模，并自动调整分配以满足 QoS 和预算限制。我还没有看到或听说过其他云数据库供应商提供过任何具有相同复杂程度的产品。
还有一些controllers来供应用程序在云中执行黑盒配置。其他人则采用了与自动驾驶汽车相同的**receding-horizon controller model**?，但它们只对集群中使用的机器数量进行修改。
云上是之前研究没有考虑过的研究场景：由于计算和存储资源现在是“无限的”，因此从理论上讲，DBMS几乎可以立即向上/向下扩展和向内/向外扩展。与此形成鲜明对比的是，传统的本地部署可能需要数周甚至数月的时间。我认为未来分布式DBMS设计的主导趋势将是shared-disk architectures.将计算节点与存储分离允许有趣的设计选择，这在无共享架构中并不容易完成。亚马逊、谷歌、Microsoft 和 Snowflake 将成为以新的和有趣的方式?[4]?推动云 DBMS 模型的领导者。云提供商将处于这一领域的最前沿，因为他们控制着整个stack。这意味着他们可以将特定于DBMS的逻辑向上推送到网络层，并在存储层中向下推送，而供应商只是在其平台内部运行是无法做到的。例如，Amazon Aurora 将有关事务写入的逻辑嵌入到 EBS 存储层中。
自动驾驶汽车是一个热门领域。人们开始将“自动驾驶”这个词用于其他事物上。我也是在数据库领域这么做的人之一。然而，尽管对于自动驾驶汽车的定义已经确立，但对于数据库管理系统（DBMS）来说却没有相应的定义。
在我看来，DBMS要被认为是完全自动驾驶的，必须支持以下三个方面：
Action是对DBMS的三个类别之一的更改：（1）对数据库的物理设计的更改（例如，增加/删除索引），（2）对DBMS的旋钮配置的更改（例如，为DBMS的日志缓冲区分配更多/更少内存），或（3）对DBMS的物理资源的更改（例如，在集群中增加/移除一个节点）。选择如何应用action的问题是action选择过程的一部分。例如，如果资源有限，DBMS 可以选择使用一个线程生成新索引，或者如果需要更快地生成该索引，则可以选择使用四个线程。
你现在应该明白为什么我会从自治数据库研究的历史开始谈起。除了少数例外，所有之前的工作都集中在解决第一个问题。有一些工具试图解决第二个问题的一部分，据我所知，没有人解决了最后一个问题。但这些正是使自驱动DBMS困难的原因。DBMS必须知道何时when部署一个action以及该action是否有帮助。这不仅仅是确定周日早上是需求低的时候，因此系统可以更积极地进行自我优化。系统必须了解工作负载将来的样子，并做出相应的计划。如果没有这种预测，DBMS就相当于一辆自动驾驶汽车，只能看到它后面的道路。汽车可以看到过去碾过的所有孩子，但它无法预测未来可能出现的孩子，也无法在前方的道路上避开他们。
这些预测之所以成为一个具有挑战性的问题，是因为环境总是在变化。硬件可以根据操作进行更改。工作负载可以根据一天中的时间、一周中的某一天或一年中的月份而变化。查询的资源使用情况可能会根据物理数据库设计而变化。**Lin Ma 在SIGMOD’18 paper**介绍了如何在自动驾驶 DBMS 中独立于这些问题预测工作负载。他的新预测框架称为 QueryBot 5000，它根据查询的arrival rates（而不是物理资源或逻辑 SQL 功能）对查询进行聚类。然后，它使用RNN、线性回归和核回归来生成不同范围（例如，10 分钟、1 小时、1 天）和不同间隔（例如，每分钟、每 10 分钟）的预测。
我们的下一步是构建强化学习 （RL） 模型，该模型可以使用 QueryBot 5000 的预测来选择有用的操作。研究的难题是如何观察一个action的好坏。同样，环境总是在变化，因此我们必须弄清楚如何将这种变化与我们的观察隔离开来。
Oracle在2017年9月宣布他们拥有世界上第一个自驱动DBMS，oracle似乎使用了他们在过去二十年中开发的现有部署和调优工具，换句话说，他们正在使用现有的云DBMS和自调优工具托管数据库;最终用户不必手动运行这些工具。例如，它们通过横向扩展 DBMS 来自动进行预配。当系统无法满足 SLA 时，就会触发此操作，因此可能是基于规则和启发式方法（即“如果性能低于某个阈值，则添加新节点”）。
Oracle 在 2018 年的“自动驾驶”DBMS 类似于 IBM 在 2008 年对 DB2 的概念验证。与我认为 Oracle 系统的工作方式类似，IBM 的系统在外部控制器和监视器中使用了 DB2 的现有工具，每当超过资源阈值（例如，死锁数量）时，这些工具就会触发更改。这个原型仍然需要一个人类DBA来选择调优优化，并偶尔重新启动DBMS。因此，Oracle 的 DBMS 在这方面更加复杂，但这两个系统仍然只在问题发生后做出反应，因为它们缺乏预测。
Oracle 吹嘘他们的自治数据仓库能够执行自动查询调优和优化。这是 Oracle 新增的自适应查询优化功能。其工作原理的要点是，如果 DBMS 注意到实际数据与其估计值不匹配，则在执行期间会生成新的查询计划。这种方法是 （1） IBM 的 LEO 的组合，其中 DBMS 可以在查询执行期间使用观察到的统计信息更新优化器，以及 （2） 1970 年代的 INGRES’?adaptive query processing 自适应查询处理技术。Oracle 并不是唯一支持此功能的系统;Microsoft 将其添加到 SQL Server 2017。
我还怀疑 Oracle 的autonomous DBMS可以自动为慢查询构建索引，因为你无法手动创建索引。同样，这可能是使用 Oracle 现有的数据库设计工具，而不是新的 ML 技术。使用ML和/或RL进行查询优化是Andy的研究小组正在研究的事情。Microsoft研究和伯克利都有单独的项目来研究这个问题。
有鉴于此，我认为甲骨文所谓的“自主数据仓库”并不是一个完整的自动驾驶DBMS。他只是一个reactionary DBMS。也就是说，它只关注现在正在发生的事情或过去发生的事情，而无法进行长期规划。Oracle 可能会使用预测模型为整个数据中心配置资源，但它不会根据特定应用程序的预期工作负载模式和变化来调整数据库。
这就提出了一个问题，即是否有可能拥有一个完全自主的 DBMS，该 DBMS 能够实现与人工手动维护的 DBMS 一样好或更好的性能，以应对所有可能的工作负载。我认为答案是“是”，就像自动驾驶汽车足以满足日常驾驶需求，但不足以应对更复杂的驾驶场景（例如拉力赛）一样，我认为自动驾驶DBMS对于大多数应用场景来说已经足够了。对于最复杂的情况，您可能仍然需要一个人。但是，自动驾驶DBMS将使人类能够部署一些原本不可能实现的优化。可以把它想象成数据库的**TAS。**
还有一个问题，如果像Oracle的自主DBMS这样的系统足够快，可以在不预测的情况下对任何变化做出反应，那么这是否可以被视为与自动驾驶DBMS相同？也就是说，如果系统能够对不断变化的工作负载做出足够快的反应，那么它就不需要具备我所说的自动驾驶所必需的预测预测功能。从人类的角度来看，它看起来好像能够自己处理所有事情，就好像它有预测一样。对于 Oracle 在其第一个版本中针对的优化类型，这可能是真的。但是，预测最重要的地方，以及真正的自动驾驶DBMS的优势在于容量规划(capacity planning)。
对于自动驾驶 DBMS 来说，“无服务器”部署的出现也是一个有趣的话题。
除了主要供应商之外，还有一些其他学术团体正在积极研究自主DBMS。