As a DBA, sometimes challenging questions like:
- If existing businesses increased 10 times, 100 times, whether the database can support?
- Next month we do big promotion, database here no problem, right?
- O planned to go to work, the code is the same logic, switching from Oracle databases to MySQL, MySQL service can support it?
- Server procurement selection, in the end Which server is more suitable for us?
Such as the face of these questions above, DBA should be how to deal with?
As a DBA how to evaluate the use of existing resources?
If the existing resource database does not support, in line with what principles should we transform it?
This article is a summary of some experience for the above problem, for your reference.
First, the assessment
Faced with this problem, we must first evaluate the work can follow the steps below:
1, performance baselines
Run against the status quo system, establish performance baselines. The business indicators and performance indicators established correspondence. Here the performance indicators include CPU, MEM, DISK, NET and so on. In many resources, there is certainly not balanced, the short-board resources are most likely to become the bottleneck of the business growth. At the operational level, business can first determine a peak time period, or by monitoring platform monitoring tool collects system usage of each resource. Then based on the information collected, analyzed where possible performance short board.
For the DBA, the performance of the system in charge of their own usage to be clear in the chest. By understanding of the business, to map business performance metrics, it can easily infers system maximum traffic bearer. In addition, the board may affect short-bearer traffic growth, there will be a clearer understanding.
In general, the application database application class is heavy resource consumption class. For CPU, MEM, DISK, NET, etc., have a greater consumption. However, due to different hardware development level is not balanced, each database resource consumption characteristics are different, and therefore require specific analysis of specific issues.
Here to talk about my personal view that the development of the hardware and database relationship:
- CPU
Compared to other terms of hardware, CPU technology developed rapidly. With the CPU clock speed and multi-core CPU technology, computing power provided by the CPU system often does not become a performance bottleneck. But we need to note that some database capability (such as MySQL is one such) can not fully utilize the CPU. In this case, in order to make full use of CPU resources, the program can be considered as "mixed multiple instances running", CPU utilization improved.
- MEM
With the play memory technology, the price of memory getting cheaper. Now we are in a production environment, we can see 128,256GB, even TB-level memory is not unusual. In general, the database often use as a buffer memory, large memory configurations on the performance of the database has obviously improved. In addition, the database itself to adapt to the large memory technology is also the scene, the policy usually is divided into sub-pool. The management unit is further broken down, for example, in Oracle Sub Pool, multi-instance buffer pool MySQL in.
- NET
With the rapid development of GigE, 10GbE, InfiniBand technology, low-latency, high-bandwidth service quality to the database and the whole IT system brings many changes. Common applications include:
- Accelerate distributed database, such as Oracle RAC.
- Acceleration large data processing, such as a poppet Hadoop MapReduce process.
- Change storage architecture evolved from the Scale-Up to Scale-Out.
- Disaster recovery solution, standby policy ...
- DISK
Relative to other hardware technology development, the traditional mechanical disk is relatively slow development of most, it is often the most likely to become a performance bottleneck in the database. With Flash technology turned out, an agent of change for the storage technology brings. Let us look at the comparison of key performance indicators:
From the above indicators, the use of Flash technology, greatly improving the storage capacity, the system eliminates the biggest bottleneck. This is why a lot of DBA are on different occasions, strongly recommended the use of flash memory, which is to improve the database performance will bring a qualitative leap. At the same time, we should also note that the traditional relational database model design is based disk IO, without taking into account the Flash technology behind the hardware now belongs to the stage of software; contrast, flash technology for non-relational model is more there are advantages.
Question index clustering factor: for example, a lot has changed traditional design based on optimization theory. This is when we need to consider the database optimization, the main attention. In addition, NoSQL database performance advantages because the combination of traditional flash memory technologies, and become obvious. We need to be analyzed in the framework selection.
2, the pressure build business models
According to business characteristics, the pressure to establish business model. Is to be understood that a simple abstract business simulation, to facilitate later amplification test pressure. To do this step, we need to have a full understanding of the business and evaluate.
By following a small example to explain:
这个表格模拟了某个类电商的业务，其包含的主要模块及模块中的主要操作。针对不同的操作其交易复杂度不同 （交易复杂度可理解为执行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、层次-业务架构级
最后一种情况是从业务角度进行一些调整。这往往是一种妥协，通过做适当的减法保证系统的整体运行。甚至不排除牺牲一部分用户体验等方式，来满足大部分用户的可用性。这就需要我们的架构师对系统能提供的能力要很清楚，对业务也要有充分的了解。对于承载什么样的业务，及为了承载业务所需要花费的代价成本有充分的认知，才可以做出一些取舍。
这里要避免一些误区，认为技术是“万能”的。技术可以解决一定的问题，但不能解决所有问题，或者解决所有问题的成本代价是难以接受的。这个时候，从业务角度稍作调整，就可以达到“退一步海阔天空”的结果。
作者：韩锋
来源：宜信技术学院