本文是《Self-Driving Database Management Systems》论文的笔记。
笔者注：本篇论文是学术界对Self-Driving DBMS概念进行详尽定义的一篇论文，对Self-Driving DBMS概念边界进行了限定，并用Peloton框架的功能实现进行了试验验证。
背景
在过去几十年，DBA人员和数据库研究人员都为更好的调优数据性能和物理设计开发了各式各样的工具，但仍不能脱离人工的干预。随云数据库的发展，不需要人工干预的DBMS就变成了一个迫切的需求，于是Self-Driving DBMS就成了必然选择。
Self-Driving DBMS与早期各种DBMS的不同之处在于：该系统的所有特性都是由计划组件构成，不仅可以对系统当前的workload进行调优，同时对未来的workload进行预测，以相应的调整系统。因此，自动驾驶的DBMS可以在不需要人工介入的情况下，完成以前所有的优化工作，并且在合适的时机去执行这些操作。它甚至可以支持一些目前人工所不能完成的、更高级的优化操作。
Self-Driving DBMS面临的几个问题
Self-Driving DBMS是一个新的研究问题，面对Self-Driving这个要求，对DBMS提出了诸多挑战，主要有如下三点：
理解业务应用的workload。从业务应用的角度来看，数据库的使用情况可以分为OLAP、OLTP和HTAP。几种模式对应了不同的使用场景和底层的存储方式，OLAP以数据分析场景为主，数据采用列存储，便于对某一列数据进行统计分析；OLTP以交易型场景为主，数据采用行存储，便于快速的对一条记录进行增删改查；HATP则是混合型场景，不仅有频繁的条目增删改查，也有大量的单列分析应用。
DBMS还需要能够预测资源使用的趋势。这有助于系统根据未来资源需求进行动态资源调配以确保对性能的影响保持最低。由于很多应用的运行模式与人的作息时间密切相关，DBA通常会在业务低峰期进行一些优化操作，避免影响服务质量。相应的，总会存在一些业务workload的异常状况是DBMS无法避免的。但是，这些模型是可以提供一些更早期的预警使得DBMS尽早完成相应操作。有了预测模型之后，DBMS可以通过一些调优操作使数据库在预期workload上工作的更好。自动驾驶的DBMS可以支持的操作主要有如下几种：（1） 数据库的物理设计；（2）数据组织形式的变更；（3）DBMS运行时的行为。这三类操作的详细内容如Table 1所示。
DBMS需要一个灵活的、内存级的架构，便于快速应用优化操作。如果不能够灵活、及时的生效相应的优化措施，优化的意义就大打折扣，同时也不能算是自动驾驶。
此外，Self-Driving的DBMS还存在两个限制条件：
DBMS不能要求开发人员通过特定的API去重写他们的应用程序或提供关于其行为的补充说明。
它不能依赖于特定环境的分析工具。这是为了确保该DBMS工具后续可扩展。
同样，也存在自动驾驶的DBMS并不能完成的工作，主要是指依赖外部信息的DBA日常工作，例如权限控制、数据清洗、版本控制等。
Peloton的架构
现有的DBMS对于自动化操作都比较不友好，通常都需要重启DB来使得配置生效。因此，一个全新的DBMS架构是必须的，整合了自动驾驶组件的DBMS需要对系统有更加全面和细粒度的控制。
Peloton采用了多版本并发控制的形式，它可以在不阻塞OLAP查询的情况下，提供OLTP事务和交互。Peloton采用了无锁数据结构的内存存储管理器，允许快速的执行HTAP。
在Peloton的设计中，系统能够在不依赖人为操作的情况下自主学习如何提升系统性能，降低响应时间是目前最主要的优化目标。
在Peloton中内置了监控工具，用于收集系统内部的各种监控数据，包括资源开销、DBMS性能数据、各类优化操作的事件信息等。通过这些数据，DBMS进行预测模型的训练，并以此来识别性能瓶颈和其他需优化的问题（例如，索引缺失、过载节点等）。
Workload 聚类
聚类workload的目的是为了降低DBMS管理的预测模型数量，并且降低预测应用行为的复杂度。Peloton采用了DBSCAN聚类算法，该方法已经在静态OLTP workload上被证实可行。
聚类面临的问题是如何选择query的特征。传统对查询做聚类时，通常采用如下两种特征：查询的运行时指标和查询的逻辑语义特征。而Peloton采用的是访问频率做特征，这三类特征各有优劣，对比如下：
* 运行时指标（rt、逻辑读、物理读等）
优点：从观测角度去聚类，不需要理解query的语义。
缺点：对数据库物理设计和数据分布比较敏感。
* 逻辑语义（查询计划、使用索引）
优点：语义与物理设计以及数据分布均无关，只表示query的语义。
缺点：它的聚类结果与workload关系不大，主要是语义上的聚类。
在实际应用时，如何判断模型是否依然适用是一个现实问题。Peloton采用了交叉验证的方式，当误差超过阈值时，重新训练聚类模型。
Workload预测
预测模块使得系统可以识别周期性的workload和数据增长的趋势，以提供更好的服务性能。每当DBMS执行完一个query，系统将对该query的聚类中心做标识，并按照固定的统计区间去记录该类查询的请求次数。Peloton使用这些数据来训练预测模型并估计未来请求的数量，同时也会为其他DBMS或OS的指标构建类似的模型。
在预测方面较为常用的方法为ARMA模型和RNN模型，优缺点对比如下：
* ARMA模型：
优点：可以刻画线性关系，计算不复杂。
缺点：通常依赖人工调参，并且线性关系的假设不太符合workload的场景。
* RNN模型（LSTM）：
优点：能保存一些时序数据中的特性，不依赖线性假设。
缺点：对训练数据集要求较高，计算量大。
Peloton通过将多个RNN进行组合的方式，让DBMS具备了快速处理问题的能力。
Action计划与执行
Peloton的控制框架可以提供对系统的持续监控并选择相应的优化措施去提升应用的服务性能。未来可以用强化学习来提升并发控制和查询优化。
1. Action生成
Peloton系统会收集潜在可能提升性能的操作，并把这些操作应用前后的系统状态一并存储。Peloton系统后续会根据预测到的workload从这些历史操作记录搜索相似的场景，并得到潜在的优化操作。
每个优化操作具备标识了CPU核数的开销，便于Peloton在执行这些优化操作是可以合理分配cpu核数。影响DBMS资源分配的那些修改配置信息的操作，被表示为幅度变更而不是绝对值的变更。部分操作需要有逆操作，例如添加索引的逆操作是删除索引。
2. Action计划
DBMS需要根据预测到的workload选择出相应的优化措施，然后在实例上真正执行这些操作。这个步骤由控制理论提供保障。基础的控制理论：在每个时间点上，系统估计出workload，然后找到可以优化当前性能的一系列操作。从这一组操作中选择第一个操作执行，然后等待该操作完全生效后，再执行下一个操作。而这个控制理论的实现，也对DBMS提出了高性能的要求，如果一个操作需要执行数分钟，那么DBMS就不容易监控性能是否变好，以及是否需要执行逆操作。
在Peloton中，这些操作以树状结构存储，树的每一层表示DBMS可以执行相应操作的时间。系统根据不同操作的代价-收益信息选择执行顺序。
代价：指执行该操作所需要的时间，以及执行操作期间DBMS性能下降的程度。
收益：指执行该操作后相应查询在时延上的提升。
同时，系统会评估不同操作对系统资源的开销，如果操作会导致资源开销超过阈值，那么该操作就不会被执行。
3. 操作执行
Peloton执行非阻塞式的优化操作。例如，重组一个数据表的布局或者将该表的存放位置进行变更，这都不影响相应查询的处理。DBMS同样可以通过内部集成的机器学习组件处理资源调度类问题。可以采用一个额外的处理器或者GPU以避免额外的计算开销拖慢DBMS的性能，或者在额外的机器上处理这些预测和计划内容，但是这将增加系统设计的复杂性和额外的开销。
4. 补充考虑
Self-Driving的DBMS需要能够用人类可读的形式解释其决策过程。DBA可以输入更多的补充信息，例如哪些库的优先级更高。为了避免DBA人工决策出现失误，DBA也需要提供出相应决策的解释，便于DBMS后续能够记录并使用。
Peloton的运行效果
Peloton中集成了TensorFlow模块，并采用2个RNN对跨度为一个月&总量为52m的查询workload进行模型训练，为了避免过拟合，应用了10%的Dropout策略，用交叉验证的方式进行了试验。
两个RNN的作用如下：
1. 第一个RNN
输入：过去两小时的查询次数（分钟粒度，向量表示）
输出：未来一小时的查询次数（分钟粒度）
2. 第二个RNN
输入：前一天的查询次数（小时粒度，向量表示）
输出：后一天的查询次数（小时粒度）
实验一：对workload的不同粒度和跨度进行预测
两个RNN的预测效果如上图所示，较近时间段的看着还可以，长时间的预测效果看着一般，不过这也是预料之中的。
实验二：对不同workload类型进行实验
该实验主要是来看DBMS对不同类型OLAP、OLTP和HTAP的数据优化能力，与固定的静态行存储、列存储进行对比。实验是HATP环境，白天执行OLTP，夜间OLAP。
可以看出来，Peloton会随着时间的推移而收敛到一个适合于工作负载的布局。在第一个OLAP之后，DBMS将行存储的元组迁移到列存储的布局，这是OLAP查询的理想选择，延迟下降，并与纯列存储的系统相匹配。其他阶段同理。
总结
本篇论文最主要的贡献是界定了Self-Driving DBMS，并用Peloton DBMS作为示例进行了架构介绍。作者认为，之所以现在可以做Self-Driving DBMS，完全是深度神经网络、硬件加速和高性能数据库架构的福利。