解DBA之惑:数据库承载能力评估及优化手段

  • 时间:
  • 浏览:5

作为DBA,有一定会被挑战类似曾经的什么的问题:

  • 导致 分析分析现有业务规模增加10倍、1000倍,数据库是否我太大 都还能能支撑?
  • 下个月大家搞大促,数据库这边没什么的问题吧?
  • 计划进行去O工作,代码逻辑不变,数据库从Oracle切换到MySQL,MySQL能支撑业务吗?
  • 服务器采购选型,到底哪款服务器更适合大家呢?

面对诸如中间的哪些地方地方质疑,DBA应该怎么面对?

身为DBA该怎么评估现有资源使用情况?

导致 分析分析现有数据库资源我我其实无法支撑,又该本着哪些地方原则进行改造呢?

本文是针对中间什么的问题的许多经验总结,供大家参考。

一、评估工作

面对曾经的什么的问题,首这么进行评估工作,可遵循下面的步骤:

1、建立性能基线

针对系统运行现状,建立性能基线。将业务指标与性能指标建立起对应关系。这里所说的性能指标包括CPU、MEM、DISK、NET等。在诸多资源中,肯定发生不均衡的情况,短板的资源最有导致 分析分析成为业务增长后的瓶颈。在具体操作上,可首先选取另一另另一个多 多业务高峰时间段,通过监控平台或监控工具埋点系统各资源的使用情况。但会 妙招埋点的信息,分析导致 分析分析的性能短板在哪里。  

对于DBA来说,对大家掌管系统的性能使用情况要了然于胸。通过对业务的了解,将业务指标映射到性能指标上,就还时要很容易地推断再次出现有系统可承载的最大业务量。此外,对于导致 分析分析影响承载业务增长的短板,也会有比较清晰的认识。  

一般来说,数据库类的应用是重资源消耗类的应用。对CPU、MEM、DISK、NET等,均有较大的消耗。但导致 分析分析不同硬件发展水平不均衡,各数据库资源消耗特点全都 同,但会 时要具体什么的问题具体分析。  

下面谈谈我对硬件发展及与数据库关系的许多大家观点:

  • CPU

相对于许多硬件而言,CPU技术发展较快。随着CPU主频提高及多核CPU技术的发展,CPU提供的计算能力往往我太大 成为系统的性能瓶颈。但大家时要注意的是,许多数据库是无法完整性利用CPU的能力(类似MySQL全都 曾经)。此时,为了充分利用CPU的资源,还时要考虑诸如”多实例混跑”的方案,提高CPU利用率。

  • MEM

随着内存技术的发挥,内存的价格这么便宜。现在大家在生产环境中,还时要见到128、256GB,甚至TB级的内存全都 罕见。一般来说,数据库通常会利用内存作为缓冲区,大内存的配置对数据库的性能有着比较明显的提升。此外,数据库自身技术也在适应着大内存的场景,通常采用的策略是划分子池。将管理的单位进一步细分,类似Oracle中的Sub Pool、MySQL中的多instance buffer pool。

  • NET

随着GigE、10GbE、InfiniBand技术的飞速发展,低延迟、高高度的服务品质给数据库乃至整个IT系统带来了全都变化。常见的应用领域有:

  • 加速分布式数据库,类似Oracle RAC。
  • 加速大数据处置,类似提升Hadoop MapReduce处置。
  • 存储架构的变革,从Scale-Up向Scale-Out演变。
  • 容灾方案,主备策略…
  • DISK

相对于许多硬件技术发展而言,传统的机械式磁盘是相对而言发展最慢的,其往往也是最容易成为数据库的性能瓶颈。随着闪存技术的横空出世,为存储技术带来的一种变革。下面大家来看看主要性能指标的对比:

从上述指标来看,使用闪存技术后,存储能力大大提高,消除了系统最大的瓶颈。这也是为哪些地方全都DBA有的是不同场合,大力推荐使用闪存,其对于数据库性能的提升会带来质的飞跃。但与此共同,大家也应该注意到,传统关系型数据库是按照磁盘IO模型设计的,这么考虑到闪存技术,现在属于软件落后于硬件的阶段;相对而言,闪存技术对于非关系型模型更有优势。

全都基于传统设计的优化理论发生了变化,类似: 索引聚簇因子的什么的问题。这名 点是时要大家在考虑数据库优化时,主要注意的。此外,NoSQL的性能优势导致 分析分析传统数据库结合闪存技术,而变得不明显。时要在架构选取时加以分析。

2、建立业务压力模型

根据业务型态,建立业务压力模型。简单理解全都 将业务模拟抽象出来,便于中间进行压力放大测试。要做到这名 步,时要对业务有着充分的了解和评估。

下面通过另一另另一个多 多小例子说明一下:

这名 表格模拟了某个类电商的业务,其涵盖的主要模块及模块中的主要操作。针对不同的操作其交易简化度不同 (交易简化度可理解为执行SQL的话的个数)。根据不同的读写情况,区分是数据读还是数据写。在估算了业务总量(交易量)的情况下,很容易推算出数据操作的量。通过这名 妙招将业务压力模型转化为数据压力模型。此处的难点在于对业务逻辑的抽象能力及对模块业务量的比例评估。

有了上述概览的表格后,针对每一种业务操作,可细化其操作。最终将其抽象成SQL的话及对应的访问型态。其伪代码可描述为

可妙招上述伪代码,编制压力测试代码。通过许多工具调用测试代码,产生模拟测试的压力。类似我无缘无故使用的oradbtest/mydbtest(原阿里楼方鑫的另一另另一个多 多测试工具)或sysbench等,有的是不错的压力测试工具。

建议企业根据自身情况,埋点出大家的业务压力模型。这在系统改造、升级、扩容评估、新硬件选型等多种场合都很有用处。它要比厂商提供的类似TPCC测试报告,更有意义。据我了解,全都规模较大的公司有的是比较性性开花结果的句子的压力模型。

3、模拟压力测试

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

上述模拟压力测试结果中,暴露出的性能瓶颈点,全都 大家中间时要着重改进、优化的方向。

二、优化层次及步骤

针对中间的评估结果,来选取中间的改进、优化方案。可遵循如下许多步骤:

1、分析瓶颈点

根据中间的评测结果,分析性能瓶颈点。针对不同瓶颈点,可采取不同的许多策略。有已经 性能测试时全流程的,对于另一另另一个多 多简化系统来说,要明选取位到性能瓶颈点比较困难。此时,可借助许多APM工具,量化整个访问路径,协助找到瓶颈。也还时要类似中间的做法,做好抽象工作,只对数据库端施加压力,观察数据库行为,判读数据库是否为瓶颈。如判断全都 数据库的承载能力过高 ,可按照不同层次进行考虑。

在整个评估数据库承载能力中,这名 步骤是最简化的、也是最难的一累积。要区分清楚是否数据库承载能力过高 ,还是许多组件的什么的问题。即使明确是数据库的什么的问题,也要分清楚是整体or局部的什么的问题;是单一业务功能慢,还是整体都这么;是偶尔会慢,还是无缘无故都更慢等等。哪些地方地方什么的问题的界定有有利于中间明确什么的问题层次,采取不同的策略进行处置。

针对数据库承载能力过高 ,我将常见再次出现什么的问题进行了层次划分,可简单分为的话级、对象级、数据库级、数据库架构级、应用架构级、业务架构级。不同层次采取的妙招有的是所不同,下面分别描述一下。

2、层次-的话级

如性能核心什么的问题,全都 某条SQL的话的什么的问题,可有针对性地进行优化。这名 妙招是侵入性比较小的一种优化妙招,其影响范围也比较小。下面对比常见的的话级优化妙招。说明一下,下面妙招导致 分析分析排除了诸如统计信息不准确等许多因素,仅从SQL的话一种优化妙招考虑。

  • 改写SQL

通过改写的话,达到调整执行计划,提高运行高度的目的。这名 妙招的缺点是时要研发人员修改原代码,但会 再进行部署上线的过程。此外,许多使用O/R Mapping工具产生的SQL,无法直接修改的话,也无法使用此妙招。

  • 使用Hint

全都种数据库都提供了提示(Hint)的功能。通过这名 妙招来指定的话的执行过程。这名 妙招同样时要修改源代码,经历部署上线的过程。此外,这名 修改妙招还发生适应性较差的什么的问题。导致 分析分析其指定了特有的执行过程,随着数据规模、数据型态的变化,固化的执行过程导致 分析分析有的是最佳妙招了。这名 妙招实际上是放弃了优化器导致 分析分析产生的最优路径。

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

在Oracle中还内置了许多功能,它们还时要固化某十根的话的执行妙招,从本质上来讲,其原理和中间使用Hint差太大。其缺点也类似中间。

  • 调整参数

有时也可通过调整许多参数,进而改变的话的执行计划。但会 这名 妙招要注意适用范围,不须在全局使用,处置影响较多的的话。在会话级使用也要控制范围,处置产生较大影响。

3、层次-对象级

如性能核心什么的问题,在SQL层面无法处置,时要考虑对象层面的调整。这名 情况要比较慎重,时要充分评估导致 分析分析带来的风险及收益。另一另另一个多 多对象的型态修改,还时要涉及到数百条、甚至数千条和此相关的话的执行计划变更。如不做充分测试的情况下,这么保证不再次出什么的问题。导致 分析分析是Oracle数据库,可考虑使用SPA评估一下。许多数据库的话,可提前手工埋点一下相关的话,模拟修改后重装入 述的话,评估性能变化。

1)影响因素

在对象级进行调整,除了考虑对许多的话的性能影响外,还时要考虑许多因素。常见的以下哪些地方地方:

  • 数据库维护成本

常见的类似索引。通过去掉 索引,往往还时要起到加速查询的目的;但会 增加索引,会导致 分析数据DML成本的增加。

  • 运维成本

常见的类似全局分区索引。全局分区索引在进行分区维护动作后,会导致 分析索引失效,时要自动或手动进行维护索引动作。

  • 存储成本

常见的索引,索引型态是数据库中真实发生空间的型态。在以往的许多案例中,甚至再次出现过索引总大小超过表大小的情况,但会 新增时要评估其空间使用。

2)全生命周期管理

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

全都性能什么的问题,在做了数据清理后都迎刃而解。但数据清理往往是时要代价的,时要在设计之初就考虑这名 什么的问题。在做数据库评审的已经 ,除了常规的型态评审、的话评审外,也要考虑这累积因素。

4、层次-数据库级

到了这名 层面,什么的问题往往导致 分析分析比较严重了。一般情况下,数据库的初始配置有的是基于其中间运行系统的负载类型进行专门配置的。导致 分析分析运行一段时间后,再次出现性能什么的问题,经评估是属于全局性什么的问题的,还时要考虑进行数据库级别的调整。但会 这名 配置往往代价也比较大,类似时要专门的停机窗口操作等。但会 这名 操作的风险性也比较大,有导致 分析分析会带来全都不选取因素,但会 要慎而又慎。

5、层次-数据库架构级

如性能核心什么的问题,无法在上述层面处置,导致 分析分析就时要调整数据库架构。常见的类似采取读写分离的访问妙招、分库分表存储妙招等。这名 对应用的侵入性很强了,许多情况下甚至不亚于重构整个系统。

类似,随着业务的发展,系统的数据量或访问量超出了预期,通过单一数据库无法满足空间或性能要求。此时,导致 分析分析就时要考虑采用一种分库分表策略,来满足这累积的需求。但其改造难度,往往比重新开发一套系统时要大。

比如,大家导致 分析分析时要另一另另一个多 多数据中间层,来屏蔽中间的分库分表细节。这名 中间层导致 分析分析时要完成的话解析、访问路由、数据聚合、事务处置等一系列功能。即使使用了中间层产品,对于应用来说,数据库的功能也会相对“弱化”,应用级代码不得不进行全都的调整来适应这名 变化。此外,怎么把另一另另一个多 多线上正在运行的系统,顺利平稳地迁移到新的型态下,这无疑又是另一另另一个多 多给飞驰的跑车换轮胎的什么的问题等等。

导致 分析分析项目在运行中,再次出现了数据库架构级的调整,很有导致 分析分析说明在前期项目设计规划阶段再次出现了失误,导致 分析分析对项目的业务预期再次出现了偏差。但会 ,这两点一定在初始阶段进行充分的评估,并在设计上保留有充分的“弹性”。

6、层次-应用架构级

许多情况下,单纯依靠数据库是无法处置的,时要综合考虑整个应用架构。在整个系统架构中,数据库往往发生系统的最末端,其扩展性是最差的。但会 ,在应用埋点初期,就应该本着尽量不须对数据库产生压力的原则进行设计。导致 分析分析即使有大的压力,系统还时要采取自动降级等妙招保证数据库的平稳运行。

常见的类似增加缓存、通过MQ实现削峰填谷等。通过增加缓存,还时要大幅度减少对数据库的访问压力,提高整体系统的吞吐能力。引入MQ,则还时要将对数据库的压力以“稳态”的形式,向数据库持续施压,而不至于被某个异常高峰压死。

7、层次-业务架构级

最后一种情况是从业务高度进行许多调整。这往往是一种妥协,通过做适当的减法保证系统的整体运行。甚至不排除牺牲一累积用户体验等妙招,来满足大累积用户的可用性。这就时要大家的架构师对系统能提供的能力要很清楚,对业务也要有充分的了解。对于承载哪些地方样的业务,及为了承载业务所需大慨的代价成本有充分的认知,才还时要做出许多选取。

这里要处置许多误区,认为技术是“万能”的。技术还时要处置一定的什么的问题,但不都还能能了处置所有什么的问题,导致 分析分析处置所有什么的问题的成本代价是难以接受的。这名 已经 ,从业务高度稍作调整,就还时要达到“退一步海阔天空”的结果。

拓展阅读: 自制小工具大大加速MySQL SQL的话优化(附源码)

全面解析Oracle等候事件的分类、发现及优化

循序渐进解读Oracle AWR性能分析报告

SQL优化:一篇文章说清楚Oracle Hint的正确使用姿势

作者:韩锋 

来源:宜信技术学院

本文由

宜信技术学院

发布在

ITPUB

,转载此文请保持文章完整性性,并请附上文章来源(ITPUB)及本页链接。

原文链接:http://www.itpub.net/2019/06/28/210001/

宜信技术学院是宜信旗下的金融科技能力展示与输出平台。通过分享在金融科技领域的开源成果、研发实践有利于金融科技生态圈企业创新升级。