从被动到主动，换个角度看DB

近期做了次分享，主题是从被动到主动，换个角度看DB。之所以讲这个题目，是我个人经历多年对数据库的管理，也是经历了这个过程。随着自己对数据库的理解逐步深入，看待数据库的角度也逐步发生变化。走过了从被动式管理，到主动式预防的过程。希望这次的内容，能开阔大家对数据库的思考角度。

在开始之前，我们先看下DBA的三种状态，相信大家都会同感。第一种状态，是“救火队员”类型。这个时期的DBA，主要是忙于处理系统的各种故障问题，处于一种疲于奔命的状态。在这个阶段，DBA对数据库是不了解的，各种问题隐患无法了然于胸，只能等到问题暴露后，才能解决处理。当然，大家都不喜欢这个阶段，个人疲于解决问题，压力很大；业务也会因为服务降级而遭受损失。随着我们对数据库的问题的了解，各种故障类的隐患问题被消除，此时就进入了第二个类型，我称之为“海量事务”。这个时期，DBA往往会陷入大量事务性的工作。这些工作日常繁琐，如果及时处理就影响系统的稳定性，甚至会酿成故障。因此，DBA会日复一日地处理此类问题，枯燥而且繁琐。例如：处理上线异常SQL性能低下问题，处理方法很简单。往往就是杀掉SQL，前端限流屏蔽入口，分析问题提出优化建议，推动研发修改再次上线。这个阶段的问题在于，我们对数据库本身有了更多的了解，知道问题本身，但不知其所以然，进而无法在前期给予解决。如果我们能更深入地了解数据库，变换看待问题的角度，进而从被动处理到主动预防阶段，也就达到了第三种状态“高枕无忧”类型的。我相信大家都是希望达到这个状态的，那如何才能达到这个阶段呢？下面谈谈我的理解。

要达到第三种状态，首先要做的就是了解你的DB。这里所谈的了解，是分为不同层次的。比较简单的，就例如左侧的状态。就像每个人的做的体检一样，对你的数据库是有个详细的报告。针对数据库的系统、实例、对象直到语句级，都会做到信息的完全掌握。这是我们对数据库了解的基础，也是最基本的信息获取。帮我们解决的是“过去发生了什么？”、“正在发生什么？”的问题。数据库自身一般提供了一些能力，获取这方面的信息，但不同数据库之间这方面的能力差异还是比较大的。有些商业数据库提供了非常完善的工具或手段来获取；而某些数据库（特别是开源产品），这方面做到是比较差的，这时就需要人工或自研工具来弥补。随着我们对数据库了解程度的加深，在左侧体检报告的基础之上，将技术指标能做到特征提取、抽象进而关联到业务上，就会形成类似右侧的结果，我称之为“画像”。其实，大家经常说的某某数据库有什么脾气，其实就是再说这个问题。所谓脾气，就是数据库行为的的一些规律描述。这时就可以帮助我们来解决预测类的问题，即“将要发生什么”。只有能做到上述两个层次的了解，才能说对数据库有了比较全面的掌控。这也是我们后面做很多架构、优化的基础所在。

这里我们先来看看，一份合格的体检报告-Oracle AWR。Oracle中的AWR，是Oracle自动负载信息库的简称。其本质是收集了大量数据库运行态的信息，存储起来，方便DBA做事后或事中的分析、排查、诊断工作。左侧看到的AWR报告，只是其表现形式之一。可以说它为我们提供了一个很好的平台，如上面材料中的比喻部分，就是对AWR的一个很好的描述。迄今为止，Oracle AWR还是我在各个数据库中见过的最好的负载记录平台。可以说有了它之后，针对Oracle数据库问题处理有了强有力的抓手。当然不是说，它做的就十分完美了，其实还是有很大的提升空间。举两个例子，现有的AWR中提供了若干种的报告展示方式，但这些报告一方面对阅读者的要求较高，就如同不同能力的大夫对片子的解读不同；另一方面很多信息还没有直观表现出来，后面也可以看到我也自己开发了一些小工具，通过挖掘AWR的数据提供更为丰富的报告。第二个例子，就是对于信息的分析粒度，还可以进一步增强。比如“top sql”问题，这些SQL语句往往是我们解决问题的入手点。它的收集依据一般是来自于执行特征或某些指标的排期Top来获得。但我们仔细思考下，你去处理一个SQL的初衷是什么，往往不是其执行慢了，而是其执行的行为跟之前不同。也就是说我们要处理的是哪些执行特征发生变化或即将发生变化的语句。我个人之前曾经有个想法，就是从数理统计的角度分析SQL执行特征，进而找出哪些最应该优化的“top sql”。如果一条语句的执行时长方差越来越大，显然后面其出现问题的概率将增大，这要比去单纯比较其执行时长平均值来的有意义。当然我还没有看到有数据库产品可以做到这样的分析，可能某些大厂在其内部有实现，但对外还没有看到。

承接上面，例如针对AWR的数据，就可以进一步挖掘使用。上面材料中的一些图表就是我个人针对AWR数据做的扩展，从更多的角度去看待你的数据库。例如从系统负载维度、从用户对象及SQL维度、从资源使用维度（这里的资源可以包括存储资源、计算资源等）。当然，我们还可以进一步挖掘，将数据库的行为数据与业务数据相结合。举个例子，你负责的是一个订单库，将订单的实时数据与数据库负载相关联，就可以大致评估出现在数据库的承载能力。这对于我们在大促、迁移、升级等评估时，都是非常具有意义的。如果发散起来，不在局限在数据库上，其实是可以做到将业务与整个IT系统基础能力相关联。从前端的网络接入、到应用处理、到缓存、数据库处理、直到后端存储，将整个链路全局管控起来，就可以比较容易发现出当前短板及主要风险点。有很多APM工具，其实就在致力于从这个方面来解决问题。

我们还可以从更细粒度来看待你的数据库。上面材料中是之前笔者在公司做的一个开源数据库审核平台-Themis，其可以从数据结构、SQL等角度更为详细地评估系统的问题。其核心是基于若干种总结的规则，抓取当前系统执行情况，来做分析。后面针对这块，还会有更为详细的说明。

上面我们谈到的是针对现有系统如何去观察，那么针对新建系统或者扩容升级的系统如何来看待呢？也就是说，如何用发展的角度来看待这个问题。上面给出一些思路。例如通过对业务系统的描述，建立业务模型与数据库模型的对象的关联。通过如右上角问题抽象加上左侧的问题实现相结合，从（业务）发展的角度看待你的数据库。在项目评估早期，技术方案评估中，使用这种方式建立数据结构、基础数据，通过对业务抽象描述总结出业务过程，通过测试平台工具完成业务过程的模拟，收集整体性能表现。利用上面的方法，就非常适用。此外，针对迁移、重构、优化等均可以采取类似的方式。

回顾总结一下，上面我们谈到的是从另外角度观察你的数据库。从更多维度、更细粒度、发展角度去观察，所有做这些的一切，是为了满足从被动到主动运维模式转变的基础。只有有足够多的观察结果，才能有明确的目标；有明确目标后，才能有的放矢。后面我将谈谈有了目标之后，如何具体完成目标的一些个人观点。

首先谈到的一点就是，解决问题都是有套路的，所谓套路就是都有一种可规范遵循的方法。以常见的优化来说，当你去解决某个优化问题时，初始是面对一个纷繁复杂的现场，需要从一团乱麻之后找到核心，然后遵循方法论来执行。上述过程，可简单用几个步骤来说明：

• 收集报告 收集报告，其实就是对应前面的过程，即从多角度去观察数据库。
• 分析问题 分析问题的阶段，玩玩是最难的。面对同样的信息输入，不同人可能有不同的解读。这也是很多来自于经验积累的结果。现在有很多云厂商，通过提供的智能诊断系统，就是通过积累的海量数据、人工智能模拟了上述过程，将优化的门槛降低。这对于普通用户来说，是很有价值的。分析之后的结果，就是给出问题结论。
• 建立优化模板 为解决提出的问题，需要建立起个优化模板。这个模板可能包含很多，不仅仅局限在数据库层面，可能包括应用、系统、业务等等。
• 提出优化方案 针对上面提出的优化模块，进一步整理优化方案，这是比较细化的输出的，到可具体执行的层面。这里谈的方案，可能是单一技术解法，也可能是多种的组合。还需要考虑成本、影响、风险等因素，有所取舍后的结果。
• 验证优化影响 针对具体的方案，需要仔细评估优化的影响。所有要执行的方案都会是有利也有弊的，需要评估后两者做出选择。例如：有个报表SQL，执行时长1小时，每天执行1次；通过优化后可以将执行时长压缩到半个小时，那会同时影响一定执行100万次的业务SQL，从20毫秒延长到30毫秒；这种优化结果我们应该做吗？答案是No！
• 评估优化结果 实施评估后的方案，并验证执行结果，判断是否达到预期。这里有个关键点在于对“预期”的判断。在我们最开始指定优化模板的时候，就需要给出明确的优化目标，因为优化本身是没有止境的，没有完美的优化方案，只有适合的方案。不要去做无明确目的的优化，要“有的放矢”。
• 重复上面步骤 如仍然不满足优化目标，则重复上述过程。重新收集数据开始整个过程。

在我们具体制定方案的时候，是有个层次问题，即优化层次。要解决一个问题，可能在不同的层次解决，从最底层的语句级、对象级，一直到上面的业务架构级，不同层次的方案的影响范围、成本、风险也各不相同。一般我们可以从瓶颈点的分析，来大致判断出层次。

• 语句级 这个影响范围最小，作为“安全”的一种做法。可精细到某一条SQL，有针对性地进行修改。此时做好必要的测试工作，可对整体的优化效果有个明确的评估，风险、成本等也是比较清楚的。对于上线后的系统，一般建议用这种方式。
• 对象级 如需要修改到对象的属性、结构等部分，其影响范围较前者扩展了。跟对象相关联的语句都可能会受到影响，特别是某些核心对象，其语句可能有数百、数千条，这种情况下是需要做更大范围的测试评估工作。针对主要的语句，最好可实现带有业务负载的端到端测试，来评估可能的性能变化。
• 实例级 到了实例层面，影响的范围更大，例如需要调整数据库的参数等。此时，不仅需要考虑影响范围，还需要考虑可行性。例如是否需要重启实例等。一般不建议在线上系统，做实例级的调整修改。包括对数据库版本的升级、迁移，都是面临此类问题，如需要做往往是个浩大的工程，需要针对方方面面，做全方位的测试。
• 资源层 有的时候，可在考虑在资源层面对优化。其风险较之前反而更小。业务会有一定经济成本的投入，但相较于前面投入的人力成本及面临的风险而言，这种方式我反而比较推荐。例如，从使用HDD到使用SSD，简单的存储介质的更换，往往会取得不错的优化效果，而且风险可控。如果能从这个角度解决，一定不要羞于提出，能达到目的就是好方案。
• 应用架构 到了这个层面，就不在局限于数据库领域。有些问题，是需要上升到应用架构层面去考虑。例如是否可做些前端限流、是否可使用缓存等，都是从减少数据库流量的方式来优化，而不是仅仅从数据库一端去考虑解决问题。一个好的应用架构，往往是可不依赖于底层数据库实现，就可以满足需求并且具有良好的弹性扩展能力的。
• 业务架构 回到优化的本质，是为了解决业务问题。当上述手段仍不能解决问题时，可以考虑从业务架构去优化。一个非常典型的问题，就是业务一定要这么做吗？是否有可降级的方式？所以说，数据库人员和应用人员，了解业务是很有好处的。此时，可以更多从业务角度去考虑这个优化问题。

在针对具体优化问题上，其解决思路可简化为上述两点。也就是说，可以从两个角度去考虑你的优化策略。

• do less or not do 翻译过来就是让数据库尽量做的少或干脆不做。举了例子，如索引优化。索引之所以能加速查询，其本质就是让数据库少做了耗费资源的事情（扫描数据块或排序等）。而尽量不做事情则更为极端，例如架构中引入缓存，让很多需要数据库完成的工作在缓存中完成，这样的优化效果当然更好。
• if must do ,do it fast 承接上面，如果数据库要做的事情必须完成，则尽量让其集中精力完成的快一些。什么时候，数据库是运行最快的，那就是on cpu的时候，如果数据库在执行中大量耗费在上下文切换、资源等待的过程中，其效率是不高的。

在执行的时机上，通常有自顶向下和自底向上两种方式。前者一般是遵循系统设计、优化、上线的流程完成，其比较系统性地解决问题；而后者则是救火式的，针对个案的解决问题。相较于前者，后者方案往往不是最优的，甚至很多时候是妥协的结果。因此，尽量能采用自顶向下的方式是更好的选择。

在具体问题的处理上，可有些更为系统化的解法。上面是我之前在处理数据库审核问题的方法，通过团队经验总结的规则，结合公司实际情况，自研平台的方式，并取得了不错的效果。

在数据库架构上，有个观点就是“没有完美的数据库方案”。在早期的数据库架构中，受限于当时场景、规模及数据库技术发展局限，往往是通过单一数据库技术来解决所有问题。那个时候的选择是比较简单的，就是从几个商业数据库中选择其一即可。后来随着数据使用的深入，其对规模、性能、使用方式等有更高要求，场景化差异也很大，这时就衍生出多种架构的数据库来满足不同的需求。因此，在做架构选择时，先要搞清楚是属于那种架构。

在具体架构上，不同方案在数据规模、使用特点、存储特征等方面各有所长。其核心点是因为数据价值密度的差异。在OLTP为代表的事务型业务上，数据存储规模较小，存储结果采取的结构化方式，其数据价值密度很高、实时性要求也较高。例如典型的在线交易系统就是如此。到了OLAP为代表的分析型业务，其数据规模更大、价值减低、实时性要求也有所减低。到了NoSQL，领域也有其鲜明特点。当然目前有种趋势，就是融合的方式，各架构之间的差异没那么明显。我们在做选择时，对需求有个准确清晰认识就好。

上面谈到的数据价值密度问题，再展开说明下。数据库存储数据，其数据规模会随着时间的推移，数据量增大；而数据活跃程度，则会随着时间推移而下降。这里有个数据分层的概念，就是对价值密度、活跃程度（其本质是业务特征）不同的数据采取分层处理的方式，而不是集中在一个数据库中解决，主动为数据库减负。因为作为IT基础平台的核心部分，数据库仍然较其他组件来说，是扩展性最差的短板，尽量在架构阶段就对数据库做好合理的拆分非常必要。努力给你的数据库做做减法，很有好处。当你在数据库架构设计文档中，包含有数据转储、清理、归档、压缩设计时，就是对这点一个很好的体现。

随着技术的发展，现在也涌现出很多新的技术，这些对我们做架构有很大意义。考虑清楚这些新技术的特点、长处、短板，结合业务找到它们的着力点。不要为了上新技术而使用新技术，也不要因为不了解而忽视了新技术的出现。

除了新技术，对于很多传统的工作，我们可以做更多更精细化的工作。例如上面材料中的SQL优化路径，就是针对SQL优化这一问题总结的方法论；下面则是针对索引修改做的策略收集表格。从上面内容可以发现，将我们日常的工作，做了更为系统化、规范化的梳理，也非常具有意义。将这些工作做到极致，同样可以发挥出很大的价值。