解DBA之惑：数据库承载能力评估及优化手段
|
副标题[/!--empirenews.page--]
《解DBA之惑：数据库承载能力评估及优化手段》要点： 作者介绍 作为DBA,有时会被挑战类似这样的问题： 2、下个月我们搞大促,数据库这边没问题吧? 3、计划进行去O工作,代码逻辑不变,数据库从Oracle切换到MySQL,MySQL能支撑业务吗? 4、服务器采购选型,到底哪款服务器更适合我们呢? 面对诸如上面的这些质疑,DBA应该如何面对? 身为DBA该如何评估现有资源使用情况? 如果现有数据库资源确实无法支撑,又该本着什么原则进行改造呢? 下面是我针对上面问题的一些经验总结,供大家参考. 一、评估工作面对这样的问题,首先要进行评估工作,可遵循下面的步骤： 1.?建立性能基线针对系统运行现状,建立性能基线.将业务指标与性能指标建立起对应关系.这里所说的性能指标包括CPU、MEM、DISK、NET等.在诸多资源中,肯定存在不均衡的情况,短板的资源最有可能成为业务增长后的瓶颈.在具体操作上,可首先确定一个业务高峰时间段,通过监控平台或监控工具收集系统各资源的使用情况.然后依据收集的信息,分析可能的性能短板在哪里. 对于DBA来说,对自己掌管系统的性能使用情况要了然于胸.通过对业务的了解,将业务指标映射到性能指标上,就可以很容易地推断出现有系统可承载的最大业务量.此外,对于可能影响承载业务增长的短板,也会有比较清晰的认识. 一般来说,数据库类的应用是重资源消耗类的应用.对CPU、MEM、DISK、NET等,均有较大的消耗.但由于不同硬件发展水平不均衡,各数据库资源消耗特点也不同,因此需要具体问题具体分析. 下面谈谈我对硬件发展及与数据库关系的一点个人观点:
相对于其他硬件而言,CPU技术发展较快.随着CPU主频提高及多核CPU技术的发展,CPU提供的计算能力往往不会成为系统的性能瓶颈.但我们需要注意的是,有些数据库是无法完全利用CPU的能力(例如MySQL就是这样).此时,为了充分利用CPU的资源,可以考虑诸如”多实例混跑”的方案,提高CPU利用率.
随着内存技术的发挥,内存的价格越来越便宜.现在我们在生产环境中,可以见到128、256GB,甚至TB级的内存也不罕见.一般来说,数据库通常会利用内存作为缓冲区,大内存的配置对数据库的性能有着比较明显的提升.此外,数据库自身技术也在适应着大内存的场景,通常采用的策略是划分子池.将管理的单位进一步细分,例如Oracle中的Sub Pool、MySQL中的多instance buffer pool.
随着GigE、10GbE、InfiniBand技术的飞速发展,低延迟、高带宽的服务品质给数据库乃至整个IT系统带来了很多变化.常见的应用领域有：
相对于其他硬件技术发展而言,传统的机械式磁盘是相对而言发展最慢的,其往往也是最容易成为数据库的性能瓶颈.随着闪存技术的横空出世,为存储技术带来的一种变革.下面我们来看看主要性能指标的对比： 从上述指标来看,使用闪存技术后,存储能力大大提高,消除了系统最大的瓶颈.这也是为什么很多DBA都在不同场合,大力推荐使用闪存,其对于数据库性能的提升会带来质的飞跃.但与此同时,我们也应该注意到,传统关系型数据库是按照磁盘IO模型设计的,没有考虑到闪存技术,现在属于软件落后于硬件的阶段；相对而言,闪存技术对于非关系型模型更有优势. 很多基于传统设计的优化理论发生了变化,例如: 索引聚簇因子的问题.这一点是需要我们在考虑数据库优化时,主要注意的.此外,NoSQL的性能优势因为传统数据库结合闪存技术,而变得不明显.需要在架构选择时加以分析. 2.?建立业务压力模型根据业务特征,建立业务压力模型.简单理解就是将业务模拟抽象出来,便于后面进行压力放大测试.要做到这一步,需要对业务有着充分的了解和评估. 下面通过一个小例子说明一下: 这个表格模拟了某个类电商的业务,其包含的主要模块及模块中的主要操作.针对不同的操作其交易复杂度不同 (交易复杂度可理解为执行SQL语句的个数).根据不同的读写情况,区分是数据读还是数据写.在估算了业务总量(交易量)的情况下,很容易推算出数据操作的量.通过这种方式将业务压力模型转化为数据压力模型.此处的难点在于对业务逻辑的抽象能力及对模块业务量的比例评估. 有了上述概览的表格后,针对每一种业务操作,可细化其操作.最终将其抽象成SQL语句及对应的访问特征.其伪代码可描述为 可依据上述伪代码,编制压力测试代码.通过一些工具调用测试代码,产生模拟测试的压力.例如我经常使用的oradbtest/mydbtest(原阿里楼方鑫的一个测试工具)或sysbench等,都是不错的压力测试工具. （编辑：厦门网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
