作为DBA,有时会被挑战类似这样的问题:
-
<李>如果现有业务规模增加十倍,100倍,数据库是否能够支撑?李
<李>下个月我们搞大促,数据库这边没问题吧?李
<李>计划进行去哪工作,代码逻辑不变,数据库从Oracle切换到MySQL, MySQL能支撑业务吗?李
<李>服务器采购选型,到底哪款服务器更适合我们呢?李
面对诸如上面的这些质疑,DBA应该如何面对吗?
身为DBA该如何评估现有资源使用情况?
如果现有数据库资源确实无法支撑,又该本着什么原则进行改造呢?
本文是针对上面问题的一些经验总结,供大家参考。
一、评估工作
面对这样的问题,首先要进行评估工作,可遵循下面的步骤:
1,建立性能基线
针对系统运行现状,建立性能基线。将业务指标与性能指标建立起对应关系。这里所说的性能指标包括CPU、内存、磁盘、净等。在诸多资源中,肯定存在不均衡的情况,短板的资源最有可能成为业务增长后的瓶颈。在具体操作上,可首先确定一个业务高峰时间段,通过监控平台或监控工具收集系统各资源的使用情况,然后依据收集的信息,分析可能的性能短板在哪里。
对于DBA来说,对自己掌管系统的性能使用情况要了然于胸。通过对业务的了解,将业务指标映射到性能指标上,就可以很容易地推断出现有系统可承载的最大业务量。此外,对于可能影响承载业务增长的短板,也会有比较清晰的认识。
一般来说,数据库类的应用是重资源消耗类的应用。对CPU、内存、磁盘、网络等,均有较大的消耗。但由于不同硬件发展水平不均衡,各数据库资源消耗特点也不同,因此需要具体问题具体分析。
下面谈谈我对硬件发展及与数据库关系的一点个人观点:
-
<李> CPU李
相对于其他硬件而言,CPU技术发展较快。随着CPU主频提高及多核CPU技术的发展,CPU提供的计算能力往往不会成为系统的性能瓶颈。但我们需要注意的是,有些数据库是无法完全利用CPU的能力(例如MySQL就是这样)。此时,为了充分利用CPU的资源,可以考虑诸如“多实例混跑“的方案,提高CPU利用率。
-
<李> MEM李
随着内存技术的发挥,内存的价格越来越便宜。现在我们在生产环境中,可以见到128256 gb,甚至TB级的内存也不罕见。一般来说,数据库通常会利用内存作为缓冲区,大内存的配置对数据库的性能有着比较明显的提升。此外,数据库自身技术也在适应着大内存的场景,通常采用的策略是划分子池。将管理的单位进一步细分,例如Oracle中的子池,MySQL中的多实例的缓冲池。
-
<李> 净
随着GigE 10 gbe, InfiniBand技术的飞速发展,低延迟,高带宽的服务品质给数据库乃至整个它系统带来了很多变化。常见的应用领域有:
-
<李>
加速分布式数据库,例如Oracle RAC。
李 <李>加速大数据处理,例如提升Hadoop MapReduce处理。
李 <李>存储架构的变革,从扩大向扩展演变。
李 <李>容灾方案,主备策略…-
<李>磁盘李
相对于其他硬件技术发展而言,传统的机械式磁盘是相对而言发展最慢的,其往往也是最容易成为数据库的性能瓶颈。随着闪存技术的横空出世,为存储技术带来的一种变革。下面我们来看看主要性能指标的对比:
从上述指标来看,使用闪存技术后,存储能力大大提高,消除了系统最大的瓶颈。这也是为什么很多DBA都在不同场合,大力推荐使用闪存,其对于数据库性能的提升会带来质的飞跃。但与此同时,我们也应该注意到,传统关系型数据库是按照磁盘IO模型设计的,没有考虑到闪存技术,现在属于软件落后于硬件的阶段;相对而言,闪存技术对于非关系型模型更有优势。
很多基于传统设计的优化理论发生了变化,例如:索引聚簇因子的问题。这一点是需要我们在考虑数据库优化时,主要注意的。此外,NoSQL的性能优势因为传统数据库结合闪存技术,而变得不明显。需要在架构选择时加以分析。
