腾讯云在数据库自治中的探索与实践？云数据库Redis多少钱？

　　腾讯在数据库自治中的探索与实践

　　腾讯在数据库自治中的探索跟整个行业的历史发展一样，同样是从简单的运维系统雏形，到后面随着业务体量越来越大，包括微信、腾讯视频、红包业务、腾讯游戏产业、腾讯体育这些大业务不断的扩张，使得人工操作遇到了瓶颈，成本也到了需要转型的阶段，因此数据库自治平台从内部开始逐渐孵化。

　　因为腾讯自身业务的行业属性非常多，有内容线的行业属性，有社交类的、有文体类的等等，根据不同的使用场景不断打磨后，去年开始对外发布 —— 数据库智能管家DBbrain，这是腾讯对外发布的一款强大的数据库自治产品。

　　1. DBbrain 产品能力解读

　　DBbrain 服务在云上是免费的，大家可以进行免费的试用。DBbrain 提供的自治服务涵盖三个方面：

　　性能优化：利用机器学习、大数据手段快速复制资深数据库管理员的成熟经验，将大 量数据库问题的诊断优化工作自动化，服务于云上和云下企业。

　　安全防护：提供从用户行为安全、SQL 安全到数据存储加密安全等多项数据安全服务， 公安部认证的等保合规性安全产品。

　　数据库管理：提供免安装、免运维、即开即用、多种数据库类型与多种环境统一的 web 数据库管理终端。

　　数据库智能管家 DBbrain 与传统数据库管理工具的区别在于，它不仅仅作为辅助运维工具供 DBA 使用，而是面向所有用户，包括运维团队、开发团队、运营团队。其核心思想是通过智能运维平台为应用部门提供标准化和自动化的数据库运维服务。

　　2.  DBbrain系统架构解读

　　数据库智能管家 DBbrain 提供的自治服务是跨数据库引擎的，是通过多数据库引擎插件式方式提供的，不仅支持 MySQL，也支持 NoSQL、Redis等。

　　之前大家在网上听过Oracle有自治数据库、微软也有自治服务，但他们的服务是在特有引擎上进行数据库自治，并不是多引擎的的服务平台。

　　我们认为数据库自治既然是为了帮助数据库运维同学减轻工作的压力、提高运维的效率，应该是具备涵盖数据库运维所涉及的尽可能多的数据库引擎，因为一个业务可能不止会用到单一的数据库，比如常见的 MySQL + Redis 组合等。

　　在数据的采集层，以 MySQL 为例，我们会根据不同数据采集监控指标、比如主机监控指标、网络监控指标、数据库监控指标，通过秒级监控的指标以及采集的日志信息，帮助用户发现更广的问题面，不仅仅是数据库层面的故障、主机层面和管控任务的故障都可以有丰富的源数据的记录。

　　在数据的计算和加工层的模块，模块通过流式计算平台提取出特征数据。这个地方并不需要人工进行分类，而是通过特征提取和加工来识别出异常信息、异常的数据，再进行异常指标和异常趋势的预测。

　　这个模型我们自身已经训练出了涵盖比较多指标和比较多情况的通用引擎，另一方面，也通过了现网用户对数据库使用情况和对于问题的反馈来进行监督式学习，不断增强模型训练，做到模型对业务是千人千面，而不是一套通用模型面对所有的数据库业务。

　　在实时诊断模块中，通过计算模块给出的结果、识别出的异常信息，以及内置的专家智能服务来为大家提供诊断优化的建议，同时会调用一些运维工具类处理的模块，比如慢日志分析模块、延迟主备切换分析等等，以工具类的模块进行辅助诊断，给到用户非常精准的数据库问题的诊断结果和对应分析以及优化定义。

　　在功能和输出交互层面也提供了多终端的访问，不仅仅是PC端的访问，也提供了小程序、移动端、公众号、订阅号一体化的输出，帮助用户有各种各样的体验，在任何地方都可以享受数据库自治服务带来的红利和便利。

　　3. 用户级监控告警全链路

　　接下来和大家分享这几年我们做了哪些工作，有了哪些沉淀积累。

　　数据库自治服务首先关注的是故障，故障具体关注的是告警和监控，DBbrain 提供了宏观用户级别的监控和告警，让用户第一时间内能够发现故障、发现异常，可以了解整个自己负责的所有数据库的情况。

　　这部分采用的是二八原则，产品基本上为80% 以上的”小白”设计，涵盖80% 常见的数据库异常问题和监控指标，所以门槛非常低。

　　监控页面给用户呈现出来的易读性非常高，不需要从几百个监控指标中找出哪个有问题，我们会帮助用户筛选、聚合出相同问题触发的监控指标。

　　最后是过程+结果的导向，DBbrain 的全景视图是联动的，所有都是结果导向，不仅仅让用户看得到实际上出现什么问题，也可以在监控告警层面给大家展示故障发生过程中的变化，性能变更趋势、其他指标变化趋势等等。不仅是在结果侧方面给出反馈，在过程方面也会给用户清晰的呈现。

　　4. 7*24小时异常诊断

　　7x24 小时异常诊断，就相当于不间断的 DBA 值班一样，只不过是通过数据库自治服务来提供。

　　在之前的专家时代、工具时代，没有办法做到 7x24 小时的异常诊断，主要有三个原因：

　　信息分析难

　　信息获取难

　　性能优化难

　　数据库自治服务可以帮助大家克服掉这三座大山，提供自治的闭环服务，帮助大家识别各种各样的数据库问题。这里我们可以举几个例子：

　　比如在线教育行业由于疫情的原因，在晚上八点到十点会是一个业务高峰；而交易类、金融类的业务在早上和下午会是高峰，在某一个点可能会出现峰值，所以具备一个周期性的变化。

　　变更是指原来的业务变化是有规律的，但是突然有一天出现业务的变更，这很可能是业务进行了功能上的发布或者调整。

　　通过这些特征提取以及采集到的多维度秒级监控进行相互的配合，能够帮助识别出每一类业务自有、特有的规律，使得在做归因分析和自我优化过程中，可以屏蔽掉由于自身业务特性带来的并非是故障的高峰点，帮助用户识别“伪高峰”。

　　5. 异常框架诊断

　　数据库自治服务诊断的框架分三部分 —— 假说生成、证据评分、决策计算。

　　在假说生成时，我们会把各种关系模型进行1-N个关联，取到非常多的相关指标和异常，通过决策候选集的筛选，利用证据模型通过证据链进行筛选。最后通过决策支持度向量，进入决策计算模块。

　　决策计算模块会进行判断，决策是否为最优，如果不是最优会重新进行证据评分。

　　6.  SQL 优化

　　相信 SQL 优化是绝大多数 DBA 或者研发同学都很感兴趣的话题，也是大家用的最频繁的功能之一。

　　DBbrain 提供的 SQL 优化，特点在于代价和成本。不仅提供索引的建议，还会提供语句的改写和排序字段的选择。

　　DBbrain 在索引分析方面考虑的更为全面。比如在增加索引时，会考虑是否有冗余索引，是否有现成的索引可以使用或者修改。其次在索引更新后，还会评估对于用户已有的SQL是否会有影响，从而使得数据库性能下降等？

　　此外像大家比较关注的 SQL模板聚合统计、耗时区间统计等多维度的信息统计，DBbrain也会提供相应的能力。

　　7. 基于cost的分析引擎

　　基于 cost 的分析引擎也是我们今年的重点之一。首先的出发点是增加用户对于 DBbrain 提供的索引建议的可信度。

　　往往我们要判断一个索引、一个优化建议好不好，最简单的方法是理论上一定是可行的，二是实践，如果加上去真的变快了，我们就认为这个处理得好。如果加上去没改变就不行。

　　但是通过基于 cost 的分析引擎，我们能够在用户没有执行优化建议之前就把优化的结果告诉大家，从而在优化前就可以清楚的看到预期的优化效果。

　　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层面的优化，数据库自治服务在宏观上对整个数据库也有一套健康评估策略，主要通过五个方面进行评估，如下图所示：

　　首先是可用性，可用性是指服务正常还是不正常。业务最明显的感知就是业务是不是挂了，是不是可以正常的使用。

　　第二是数据可靠性。什么情况下会影响数据可靠性？除了故障数据、丢数据、人为的操作导致数据的不一致以外，有时候正常的业务逻辑中也会出现数据可靠性的问题。比如数据延迟增加，一旦出现故障如果主库的数据无法找回、起不来，备库的数据就会出现数据丢失的情况，很可能是由于binlog还没有传输过去、或者主库事务没有结束的情况。

　　性能是指是不是存在慢SQL、是不是存在并发数导致 CPU 资源消耗过于明显，是不是使用率非常高、发挥功能不足或者是 cache 比较低等等导致的性能问题，也是数据库健康评估策略非常关注的一点。

　　还有就是隐患、超大表或者是表数量的不合理，没有及时进行分步、分表，或者是采用分布式底层存储的架构，导致在做大量数据的排序查询时性能会随着数据量逐渐增大，聚合的消耗会越来越大，这也是隐患项。还有一个隐患是权限是否合理、是否有过多的授权，这些都会涉及到数据库的隐患，我们也会在健康评估策略中特别的强调出来。

　　变化我们在7x24小时的异常诊断中提到过，业务趋势的变更、突增、变化，与之前业务消耗和业务资源使用情况不一致的情况，我们都会识别出来告诉用户，帮助大家不仅能够掌握整个业务的使用情况，也可以对业务资源消耗画像有所了解。通过健康评估报告，更能够知道各种业务是否合理。

　　10. 时间序列模型Porphet在资源预测上的应用

　　刚刚我们提到，我们结合了一些算法进行了一些预测，预测模型是采用前几年Facebook开源的Porphet算法，应用累加回归的模型，通过时间、趋势以及循环变更的规律来帮助业务预测资源的使用情况。

　　最简单的是根据历史使用趋势预测磁盘使用量，能够帮助用户提早知道什么时候该扩容、什么时候缩容、什么时候需要购买更多的设备、什么时候需要清理数据，同样也可以帮助用户预测CPU、内存性能指标在后续趋势中的变动，帮助用户在大促前、一些活动之前、一些重要敏感操作之前，知道业务什么时候是低峰、什么时候需要拓展多少资源，这种预测模型对用户和云厂商有非常大的价值。

　　对于云厂商而言，对于资源调度、资源的管理以及帮助用户进行资源合理的分配，有非常大的价值。

　　对于客户而言，云上的资源评估、资源的管理工作，借助预测模型可以预先启动这些工作，不用每次都措手不及。想要扩容的时候马上申请资源是来不及的，虽然云上是弹性的伸缩，但是特殊情况下，比如出现大促的时候，电商客户都在这一天发起扩容，很可能就会出现资源洪峰，用户可能不能够按时拿到想要的资源。

　　11.  自动性能优化系统 CDBTune

　　CDBTune 是一个新的前沿技术，去年我们在 SIGMOD 以论文的形式进行了发布。产品化的过程也在进行逐步的完善。

　　大家都知道数据库参数很多，那么要如何调参？很多人表示网上有很多万能模板，但到底适不适合你的业务，其实是不知道的，可能无法发挥数据库最大的性能。

　　如果对这些参数进行手动调参，有经验的DBA可能对其中的某些参数有自己的经验，但对于各种不同特征业务或者不断变更的业务，CDBTune 就可以帮助很好的解决这个问题。

　　我们可以通过深度学习算法通过自调优的方式，得到与自身业务相匹配的参数配置。调优的时间也比其他的要快，调优的结果经过测试，已经达到了很高的水平。

　　12. 容易被忽略的数据库安全防护

　　绝大多数的数据库运维对于这部分的内容要不然是接触的很少，要不然就是会被忽略掉。大部分的数据库运维往往认为只要保证业务不出性能问题、不出故障就可以，但很少会关注数据库的安全防护。

　　数据库自治服务作为一个全方位的服务，必然要在大家忽略或者没有关注到的地方提供相应的价值，这样才能为客户更好的提供数据库的稳定性和安全性。

　　这里我们主要提供了三个功能：

　　合规审计：提供符合国家等保要求的安全审计，对企业网络中的数据库各类会话信息、访问操作、SQL 语句进行安全审计，可挖掘数据库运行过程中各类潜在风险和隐患，为数据库安全运行保驾护航。

　　安全治理：可对数据资产、数据内容、访问信息进行中心化管理。并依托先进的 AI 引擎与敏感数据发现算法， 将针对企业核心数据的异常操作进行筛选告警，实现企业数据保护。

　　数据脱敏：以处理数据库文件的方式，对数据库中敏感数据进行在线屏蔽、变形、字符替换、随机替换等脱敏操作，达到企业核心数据保密效果。