解DBA之惑：数据库承载能力评估及优化手段
|
要想考察现有数据库能否承载增长后的业务压力,最好的方式就是模拟压力测试.观察在近似真实的压力下,数据库的表现.重点观察,数据库的承载力变化、主要性能瓶颈等.通常可以有两种方式,一种是从真实环境导流(并可根据需要放大流量,可利用类似TCPCOPY等工具);一种是根据前面整理的业务压力模型,通过压力工具模拟压力.前者适用于已有项目的扩容评估、系统改造评估等,后者适用于新上项目原型方案评估、性能基准测试等场景. 上述模拟压力测试结果中,暴露出的性能瓶颈点,就是我们后面需要着重改进、优化的方向. 二、优化层次及步骤针对上面的评估结果,来确定后面的改进、优化方案.可遵循如下一些步骤： 1.?分析瓶颈点根据上面的评测结果,分析性能瓶颈点.针对不同瓶颈点,可采取不同的一些策略.有时候性能测试时全流程的,对于一个复杂系统来说,要明确定位到性能瓶颈点比较困难.此时,可借助一些APM工具,量化整个访问路径,协助找到瓶颈.也可以类似上面的做法,做好抽象工作,只对数据库端施加压力,观察数据库行为,判读数据库是否为瓶颈.如判断就是数据库的承载能力不够,可按照不同层次进行考虑. 在整个评估数据库承载能力中,这一步骤是最复杂的、也是最难的一部分.要区分清楚是否是数据库承载能力不足,还是其他组件的问题.即使明确是数据库的问题,也要分清楚是整体or局部的问题；是单一业务功能慢,还是整体都比较慢；是偶尔会慢,还是一直都很慢等等.这些问题的界定有助于后面明确问题层次,采取不同的策略进行解决. 针对数据库承载能力不足,我将常见出现问题进行了层次划分,可简单分为语句级、对象级、数据库级、数据库架构级、应用架构级、业务架构级.不同层次采取的方式也有所不同,下面分别描述一下. 2.?层次-语句级如性能核心问题,只是某条SQL语句的问题,可有针对性地进行优化.这种方式是侵入性比较小的一种优化方式,其影响范围也比较小.下面对比常见的语句级优化方法.说明一下,下面方法已经排除了诸如统计信息不准确等其他因素,仅从SQL语句本身优化方式考虑.
通过改写语句,达到调整执行计划,提高运行效率的目的.这种方式的缺点是需要研发人员修改原代码,然后再进行部署上线的过程.此外,有些使用O/R Mapping工具产生的SQL,无法直接修改语句,也无法使用此方法.
很多种数据库都提供了提示(Hint)的功能.通过这种方式来指定语句的执行过程.这种方式同样需要修改源代码,经历部署上线的过程.此外,这种修改方式还存在适应性较差的问题.因为其指定了特有的执行过程,随着数据规模、数据特征的变化,固化的执行过程可能不是最佳方式了.这种方式实际上是放弃了优化器可能产生的最优路径.
在Oracle中还内置了一些功能,它们可以固化某一条语句的执行方式,从本质上来讲,其原理和上面使用Hint差不多.其缺点也类似上面.
有时也可通过调整某些参数,进而改变语句的执行计划.但是这种方式要注意适用范围,不要在全局使用,避免影响较多的语句.在会话级使用也要控制范围,避免产生较大影响. 3.?层次-对象级如性能核心问题,在SQL层面无法解决,需要考虑对象层面的调整.这种情况要比较慎重,需要充分评估可能带来的风险及收益.一个对象的结构修改,可以涉及到数百条、甚至数千条和此相关语句的执行计划变更.如不做充分测试的情况下,很难保证不出问题.如果是Oracle数据库,可考虑使用SPA评估一下.其他数据库的话,可提前手工收集一下相关语句,模拟修改后重放上述语句,评估性能变化. 1)影响因素在对象级进行调整,除了考虑对其他语句的性能影响外,还需要考虑其他因素.常见的以下这些：
2)全生命周期管理这里还有另外一个很重要的概念——“对象全生命周期管理”,简单来说就是对象的生老病死.在很多系统中,对象从新建开始,数据不断增加、膨胀,当数据规模达到一定量级后,各种性能问题就出现了.对一个百万级的表和亿万级的表,其查询性能肯定不能同日而语.因此,在对象设计初期,就要考虑相关的归档、清理、转储、压缩策略,将存储空间的评估与生命周期管理一起考虑. 很多性能问题,在做了数据清理后都迎刃而解.但数据清理往往是需要代价的,必须在设计之初就考虑这个问题.在做数据库评审的时候,除了常规的结构评审、语句评审外,也要考虑这部分因素. 4.?层次-数据库级（编辑：厦门网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
