解DBA之惑：数据库承载能力评估及优化手段(2)

建议企业根据自身情况,整理出自己的业务压力模型.这在系统改造、升级、扩容评估、新硬件选型等多种场合都很有用处.它要比厂商提供的类似TPCC测试报告,更有意义.据我了解,很多规模较大的公司都有比较成熟的压力模型.

要想考察现有数据库能否承载增长后的业务压力,最好的方式就是模拟压力测试.观察在近似真实的压力下,数据库的表现.重点观察,数据库的承载力变化、主要性能瓶颈等.通常可以有两种方式,一种是从真实环境导流(并可根据需要放大流量,可利用类似TCPCOPY等工具);一种是根据前面整理的业务压力模型,通过压力工具模拟压力.前者适用于已有项目的扩容评估、系统改造评估等,后者适用于新上项目原型方案评估、性能基准测试等场景.

上述模拟压力测试结果中,暴露出的性能瓶颈点,就是我们后面需要着重改进、优化的方向.

针对上面的评估结果,来确定后面的改进、优化方案.可遵循如下一些步骤：

根据上面的评测结果,分析性能瓶颈点.针对不同瓶颈点,可采取不同的一些策略.有时候性能测试时全流程的,对于一个复杂系统来说,要明确定位到性能瓶颈点比较困难.此时,可借助一些APM工具,量化整个访问路径,协助找到瓶颈.也可以类似上面的做法,做好抽象工作,只对数据库端施加压力,观察数据库行为,判读数据库是否为瓶颈.如判断就是数据库的承载能力不够,可按照不同层次进行考虑.

在整个评估数据库承载能力中,这一步骤是最复杂的、也是最难的一部分.要区分清楚是否是数据库承载能力不足,还是其他组件的问题.即使明确是数据库的问题,也要分清楚是整体or局部的问题；是单一业务功能慢,还是整体都比较慢；是偶尔会慢,还是一直都很慢等等.这些问题的界定有助于后面明确问题层次,采取不同的策略进行解决.

针对数据库承载能力不足,我将常见出现问题进行了层次划分,可简单分为语句级、对象级、数据库级、数据库架构级、应用架构级、业务架构级.不同层次采取的方式也有所不同,下面分别描述一下.

如性能核心问题,只是某条SQL语句的问题,可有针对性地进行优化.这种方式是侵入性比较小的一种优化方式,其影响范围也比较小.下面对比常见的语句级优化方法.说明一下,下面方法已经排除了诸如统计信息不准确等其他因素,仅从SQL语句本身优化方式考虑.

• 改写SQL

通过改写语句,达到调整执行计划,提高运行效率的目的.这种方式的缺点是需要研发人员修改原代码,然后再进行部署上线的过程.此外,有些使用O/R Mapping工具产生的SQL,无法直接修改语句,也无法使用此方法.

• 使用Hint

很多种数据库都提供了提示(Hint)的功能.通过这种方式来指定语句的执行过程.这种方式同样需要修改源代码,经历部署上线的过程.此外,这种修改方式还存在适应性较差的问题.因为其指定了特有的执行过程,随着数据规模、数据特征的变化,固化的执行过程可能不是最佳方式了.这种方式实际上是放弃了优化器可能产生的最优路径.

• 存储概要、SQL概要、计划基线

在Oracle中还内置了一些功能,它们可以固化某一条语句的执行方式,从本质上来讲,其原理和上面使用Hint差不多.其缺点也类似上面.

• 调整参数

有时也可通过调整某些参数,进而改变语句的执行计划.但是这种方式要注意适用范围,不要在全局使用,避免影响较多的语句.在会话级使用也要控制范围,避免产生较大影响.

如性能核心问题,在SQL层面无法解决,需要考虑对象层面的调整.这种情况要比较慎重,需要充分评估可能带来的风险及收益.一个对象的结构修改,可以涉及到数百条、甚至数千条和此相关语句的执行计划变更.如不做充分测试的情况下,很难保证不出问题.如果是Oracle数据库,可考虑使用SPA评估一下.其他数据库的话,可提前手工收集一下相关语句,模拟修改后重放上述语句,评估性能变化.

1)影响因素

在对象级进行调整,除了考虑对其他语句的性能影响外,还需要考虑其他因素.常见的以下这些：

• 数据库维护成本

  常见的例如索引.通过添加索引,往往可以起到加速查询的目的；但是增加索引,会导致数据DML成本的增加.

• 运维成本

  常见的例如全局分区索引.全局分区索引在进行分区维护动作后,会导致索引失效,需要自动或手动进行维护索引动作.

• 存储成本

  常见的索引,索引结构是数据库中真实占据空间的结构.在以往的一些案例中,甚至出现过索引总大小超过表大小的情况,因此新增时要评估其空间使用.

2)全生命周期管理

这里还有另外一个很重要的概念——“对象全生命周期管理”,简单来说就是对象的生老病死.在很多系统中,对象从新建开始,数据不断增加、膨胀,当数据规模达到一定量级后,各种性能问题就出现了.对一个百万级的表和亿万级的表,其查询性能肯定不能同日而语.因此,在对象设计初期,就要考虑相关的归档、清理、转储、压缩策略,将存储空间的评估与生命周期管理一起考虑.

很多性能问题,在做了数据清理后都迎刃而解.但数据清理往往是需要代价的,必须在设计之初就考虑这个问题.在做数据库评审的时候,除了常规的结构评审、语句评审外,也要考虑这部分因素.

（编辑：ASP站长网）