一、数据库自治的演进
上图所示是一张关于数据库自治的宏观视图。业内普遍定义的石器时代大概是在十几、二十年前，刚刚进入数据库发展的快速轨道，当时的技术方案和对于数据库的认知都处于一个初级的阶段。经历了后续的工具时代、专家时代，现在数据库自治已经到达了智能时代。在智能时代中，我们享受到了数据库自治在数据库性能优化、管理、服务等红利。很多人都有疑惑，这条时代发展的时间线到底是怎么演进的？其实这个问题不难理解，大家在日常工作中也能体会到，时代的更替、技术的诞生，往往跟业务的需求有关，也跟现有的技术能力有关。无论是业务驱动还是技术驱动，最终的结果就是使得数据库自治从石器时代到工具时代、专家时代、智能时代，这样一个井然有序的发展过程。我们所谓的石器时代、工具时代、专家时代、智能时代其实不仅仅是指代时间的迭代，更多的是指技术的发展和趋势的迭代。所以有些公司现在可能依然处于石器时代，有些公司可能很早就进入了专家或者智能时代。1. 石器时代
当工具时代的积累达到了一定的程度，就到达了专家时代。在这个时期，大家发现之前的脚本虽然很多但很杂乱，用了各种各样的编程语言、运行在各种不同的环境中，没有统一的管理平台，也没有统一的归类整理。数据库运维的水平往往取决于写这个脚本的运维工程师的个人能力，很难很好继承下去。所以专家时代更多的是想把脚本标准化，用服务平台代替杂乱无章的脚本，从而将脚本规范化、标准化，变成一个可以实现自动化运维的平台。通过这个平台，无论是有资历的工程师还是刚刚入门的研发同学，都可以井然有序的根据平台化的服务进行数据库管理。把专家的经验转变为可复制的能力工具，是专家时代运维最显著的特点。4. 云数据库时代
随着近几年云数据库时代的到来，很多企业从自建DB迁移到了云上，也开始认知到云带给大家的好处。数据库从本地部署到云上，可以自建云服务器，也可以直接使用云上提供的PaaS服务。这部分无论是关系型数据库还是非关系型数据库或者是NewSQL，大家都开始逐渐享受到云数据库时代的红利。在数据库上云后，很多人会问云厂商提供的服务是不是可以保证数据库的运维没有任何的问题了？就不再需要去思考、不需要拥有之前一代代继承下来的经验？其实并不是这样。数据库上云解决的只是基础的管控服务，比如备份、监控、故障切换等等，云上提供的是相应的PaaS能力、高可用能力和数据可靠性的能力。但其实云服务的到来，对数据库的运维服务反而提出了更多的挑战。这里我们可以举几个例子。首先是资源的评估，这是在上云、多云的使用中会经常遇到的问题。本地使用的是4核16G的物理机，那么在云上要购买哪种型号的服务器？购买哪种规格的PaaS数据库服务？绝大多数没有经历过云迁移的同学在这个阶段会认为最好的方法是平移，这样一定不会出现问题。其实不然，在某些环节出现的问题有可能会导致业务性能出现故障。其次在上云之后，大家会认为云的弹性伸缩促使了业务的快速发展。近两年来很多的电商业务量、访问流量都呈几何倍数增长，各种各样的大促节日让业务部门、数据库运维部门面临更重的数据库保障任务。这时要如何保障资源评估的准确率，以及快速处理突发事件就成了要解决的问题。同样对于云上的数据库，最大的变化就是上云之后变成了黑盒。这种黑盒现象使得在故障诊断、分析和恢复数据库问题时不能快速的定位问题、发现问题、解决问题。所以云上数据库时代到来以后，对数据库运维同学其实是提出了更高的要求。对于非专业的运维同学，如何通过云上成千上百的异常指标来发现问题、找出规律，是面临的一个大问题。最后，云时代还对性能提出了新的考验。如何利用经验帮助提高数据库的性能，并且持续不断的进行优化？随着数据量的积累和业务的增长，甚至一些数据的变化导致的数据分布不均衡，都会导致数据库出现问题，所以数据库性能的优化在云上有着更大的挑战。5. 智能时代
类比自动驾驶的等级，我们把数据库自治运维也切分成 Level 0 ~ Level 4 这几个阶段。最开始所有操作都需要人工部署、人工干预，而后期人只是作为辅助，一些简单的工作、没有成长、重复的劳动都可以交给数据库自治服务统一完成。经常有人会问，数据库自治服务是否会取代人工？取代数据库运维？取代DBA？我可以很明确的告诉大家，数据库自治目的是为了提高处理问题的效率、提高业务的稳定性、降低业务的故障导致的损失，而并不是为了取代DBA。DBA在数据库各个发展时代的核心价值，从会写自动命令到会编写脚本，处理线上的故障、会排查日志，再到会做一些监控和管控平台。到了数据库自治时代，数据库运维核心价值应该是能够贴近业务，在业务层面发挥更多的价值。能够通过积累、通过对业务的理解和数据库的理解，帮助业务在架构设计、附表设计、整体的业务架构上面做更多的工作。所以数据库自治服务是放大了数据库运维的核心价值，而不是取代了数据库运维。
二、腾讯在数据库自治中的探索与实践
DBbrain 服务在云上是免费的，大家可以进行免费的试用。DBbrain 提供的自治服务涵盖三个方面：
性能优化：利用机器学习、大数据手段快速复制资深数据库管理员的成熟经验，将大 量数据库问题的诊断优化工作自动化，服务于云上和云下企业。
安全防护：提供从用户行为安全、SQL 安全到数据存储加密安全等多项数据安全服务， 公安部认证的等保合规性安全产品。
数据库管理：提供免安装、免运维、即开即用、多种数据库类型与多种环境统一的 web 数据库管理终端。数据库智能管家 DBbrain 与传统数据库管理工具的区别在于，它不仅仅作为辅助运维工具供 DBA 使用，而是面向所有用户，包括运维团队、开发团队、运营团队。其核心思想是通过智能运维平台为应用部门提供标准化和自动化的数据库运维服务。2. DBbrain系统架构解读
信息分析难
信息获取难
性能优化难
数据库自治服务可以帮助大家克服掉这三座大山，提供自治的闭环服务，帮助大家识别各种各样的数据库问题。这里我们可以举几个例子：比如在线教育行业由于疫情的原因，在晚上八点到十点会是一个业务高峰；而交易类、金融类的业务在早上和下午会是高峰，在某一个点可能会出现峰值，所以具备一个周期性的变化。变更是指原来的业务变化是有规律的，但是突然有一天出现业务的变更，这很可能是业务进行了功能上的发布或者调整。通过这些特征提取以及采集到的多维度秒级监控进行相互的配合，能够帮助识别出每一类业务自有、特有的规律，使得在做归因分析和自我优化过程中，可以屏蔽掉由于自身业务特性带来的并非是故障的高峰点，帮助用户识别“伪高峰”。5. 异常框架诊断
数据库自治服务诊断的框架分三部分 —— 假说生成、证据评分、决策计算。在假说生成时，我们会把各种关系模型进行1-N个关联，取到非常多的相关指标和异常，通过决策候选集的筛选，利用证据模型通过证据链进行筛选。最后通过决策支持度向量，进入决策计算模块。决策计算模块会进行判断，决策是否为最优，如果不是最优会重新进行证据评分。6. SQL 优化
cost 值不等同于耗时，减少的 cost 不能等比例的计算耗时。这里我们会考虑三个方面：
在Server层中主要的开销是计算符合条件的行的代价
在engine层中主要的开销是从磁盘读数据的代价
在Jion计算时不仅要考虑condition,还要考虑condition上的filter
我们会将这些综合到 cost 引擎中，帮助用户更好的在优化之前看到优化的预期效果。8. 数据库审计与分析
这个功能也是 DBbrain 提供的非常前沿的功能，也是非常实用的功能。具体就是我们之前有些操作很可能是瞬间的操作，在回溯问题时发现不了；有些SQL由于记录的原因记录不全，导致分析问题时没有参考。通过SQL审计与分析服务，可以帮助用户记录所有在数据库层面执行的 SQL，不仅仅是变更的操作，查询操作也可以被记录下来。可以理解为类似于原生的 log。首先对性能消耗做了严格的测试，每条SQL执行完以后会进行审计规则的识别和过滤，将命中审计规则的 SQL 写入到内存中，批量的进行刷盘，它的性能整体损耗在做压缩以后，得出数据是低于5%。各个厂商都在做审计类的服务，评测报告也是网上可以查询到的，5% 的消耗是业内很领先的水平。针对审计全量SQL能够做的事非常多，能够贡献所有SQL任意时刻的快照以及执行的趋势。很多时候一条SQL可能就执行十秒，但其中等了20秒，所以SQL执行时间很短，但是这条SQL结束的时间跨度非常长。对于这种SQL如果没有全量时间的快照就很难发现这样的问题，这帮助我们在排除疑难杂症的时候有更多的支持，能够帮助我们把整个数据库执行轨迹更加精确的梳理出来。9. 数据库健康评估策略解读除了精确到SQL层面的优化，数据库自治服务在宏观上对整个数据库也有一套健康评估策略，主要通过五个方面进行评估，如下图所示：
刚刚我们提到，我们结合了一些算法进行了一些预测，预测模型是采用前几年Facebook开源的Porphet算法，应用累加回归的模型，通过时间、趋势以及循环变更的规律来帮助业务预测资源的使用情况。最简单的是根据历史使用趋势预测磁盘使用量，能够帮助用户提早知道什么时候该扩容、什么时候缩容、什么时候需要购买更多的设备、什么时候需要清理数据，同样也可以帮助用户预测CPU、内存性能指标在后续趋势中的变动，帮助用户在大促前、一些活动之前、一些重要敏感操作之前，知道业务什么时候是低峰、什么时候需要拓展多少资源，这种预测模型对用户和云厂商有非常大的价值。对于云厂商而言，对于资源调度、资源的管理以及帮助用户进行资源合理的分配，有非常大的价值。对于客户而言，云上的资源评估、资源的管理工作，借助预测模型可以预先启动这些工作，不用每次都措手不及。想要扩容的时候马上申请资源是来不及的，虽然云上是弹性的伸缩，但是特殊情况下，比如出现大促的时候，电商客户都在这一天发起扩容，很可能就会出现资源洪峰，用户可能不能够按时拿到想要的资源。11. 自动性能优化系统 CDBTune
CDBTune 是一个新的前沿技术，去年我们在 SIGMOD 以论文的形式进行了发布。产品化的过程也在进行逐步的完善。大家都知道数据库参数很多，那么要如何调参？很多人表示网上有很多万能模板，但到底适不适合你的业务，其实是不知道的，可能无法发挥数据库最大的性能。如果对这些参数进行手动调参，有经验的DBA可能对其中的某些参数有自己的经验，但对于各种不同特征业务或者不断变更的业务，CDBTune 就可以帮助很好的解决这个问题。我们可以通过深度学习算法通过自调优的方式，得到与自身业务相匹配的参数配置。调优的时间也比其他的要快，调优的结果经过测试，已经达到了很高的水平。12. 容易被忽略的数据库安全防护
三、DBbrain行业典型案例分享
下面我们结合一个行业用户的案例，来给大家进一步分享数据库自治在实际的生产过程中如何应用。
电商大促大家都不陌生，腾讯云自身也支撑了非常多的大规模电商。那么电商在每次的大促过程中，如何利用数据库的自治服务，来保障自身的数据库安全？在备战阶段需要进行故障梳理、资源评估等工作，在没有数据库自治之前，这些工作都必须由DBA来进行。一旦在某个环节出现了问题，或者业务出现了问题，往往DBA就变成了“背锅侠”，总能找出DBA的问题。而使用数据库自治服务就可以有效解决上述问题。1. 数据库巡检，评估风险首先，我们可以通过数据库巡检全量的实例，评估相应的风险。因为电商行业的实例很多，如果让DBA手动巡检，工作量是非常巨大的，所以常规DBA会进行核心实例的巡检，或者只对经常出故障的实例进行巡检，但这样就会有很多潜藏的风险。所以全量巡检、多维度巡检是非常必要的。为什么说在这个地方可以发现问题？因为在备战阶段业务侧一般会封网，一旦封网，业务逻辑不到必要的bug修复时是不会调整的。所以在封网后进行全量巡检、排查问题，只要修复了那么在之后大促的过程中，就可以尽可能的减少问题。
数据库自治的巡检报告，包含从基本信息到资源状况、任务状态的巡检，以及日常的访问行为等非常全面的信息。热点访问是非常关键的，很可能业务没有出问题，但冷热数据一旦没有进行区分，那么在并发量高的情况下一定会出问题。所以我们可以在用户封网后提供全链路的检查。2. 助力业务优化改造
在排查之后，我们还需要助力客户进行业务的优化。如图所示，我们把优化大致分为五层。其中，SQL优化是大家非常容易上手、操作起来非常方便的一个优化，比如索引优化、改写优化等。其次还有更深入的配置优化、数据优化、架构优化和业务优化等。之所以排为1-5，是因为在第一层的优化中，业务的配合度会比较高、改动比较小，随着逐渐深入，可能就需要业务侧更改代码逻辑。我们会根据业务不同的需求提供相应的优化建议。3. 业务场景的故障自愈
最后，我们发现还有一些问题。比如大促中临时的变更发布，导致因为数据库层面没有相应的应对措施，数据库被击穿或者压力很大。还有可能是低质量的SQL，在压力和数据量激增的情况下数据库出现问题。面对这种情况，传统的方法一般是直接kill掉对话，持续kill或者定时kill进行降级。如果无法降级则进行重启或者HA切换，或者进行业务侧的应用回滚或者临时降级，但相对来说实践起来比较困难。数据库资质DBbrain在这个时候就可以发挥作用。首先7×24小异常诊断与优化，可以在还未发生问题时就发现隐患，并提出优质的解决方案。此外，还提供了高并发场景的解决方案，并且可以自动持续的kill掉阻塞的SQL。4. 高并发场景解决方案
刚才我们提到，DBbrain在高并发场景提供了数据库性能优化以及降级止损的解决方案。方案具体有三项：（1）热点更新保护在高并发场景中，经常出现对同一行数据的更新，在没有缓存的情况下，都会打到底层的数据库。为了保护和减小开销，针对语句的排队机制，尽可能把具有相同冲突的语句放在内存队列排队，通过开启热点更新保护来减少锁冲突的开销，提高高并发场景的数据库性能。（2）SQL限流顾名思义，就是帮助用户进行业务降级。限流的操作类似于改写，但技术方案不同。可以通过创建 SQL 限流任务，自主设置 SQL 类型、最大并发数、限流时间、SQL 关键词，来控制数据库的请求访问量和 SQL 并发量，进而达到服务的可用性，不同的任务之间不会发生冲突。（3）空闲事务自结束自动结束(Kill)空闲事务，避免大事务未提交导致大量资源争抢。会自动识别开启的事务，如果开启事务后在一定时间内没有进行提交，会自动结束该事务。
四、数据库自治的未来展望
数据库自治在未来应该会朝着自愈、自优化的方向发展，不仅能自主调节索引建议，还可以自主创建索引，自动进行识别、添加和删除。并且在未来还应该可以自动对执行计划进行回归修正，优化策略下沉与引擎融合，让用户需要干预的越来越少，提供的优化服务越来越多。最后是能够自动识别并杀掉失控SQL，并阻止进行至优化完成，帮助数据库层面做更多业务层面的代码实现。这些都是未来将要实现的功能，或者是数据库自治在未来能让大家看到的迭代或者技术点。
Q&A
文章推荐
千亿级金融场景下，基于Pulsar的云原生消息队列有怎样的表现？
