生产数据库架构改造方案样本.doc

生产数据库性能优化方案（草稿）
1. 背景
生产数据库上线一段时间后由于数据量远不不大于预期，导致数据库性能低下而影响正常业务，故需要对数据库进行性能优化。
2. 现状
当前数据库构造如下图所示：

图2-1 系统构造示意图
上游三个数据源通过DI工具以定期任务方式将上游数据抽取到基本数据库中（红色某些），从基本库到下游目的库则是通过顾客操作应用程序将基本数据库中数据调度到目的数据库中。依照当前对数据量记录基本库约为400GB+数据总量。
当前基本数据库性能低下，重要体现于定期抽取任务执行时间过长，任务间时间间隔变短；应用执行数据调度时间过长，导致应用长时间处在无响应状态。
3. 分析
基本数据库获取上游数据时，数据传播量较大，数据库写操作频繁，操作系统层体现于数据文献所在磁盘写IO高，并持续时间长。
由于基本库放数据到下游数据库是人为操作，数据库读操作频繁，操作系统层体现于数据文献所在磁盘读IO高，且经常会与DI定期任务同步执行，通过系统监控发现磁盘浮现大量IO等待状态。

图 3-1 磁盘IO状态

图 3-2 磁盘等待状态

由于基本库保存原始数据并不对数据进行解决，因此CPU消耗很低，从监控看CPU不视为性能瓶颈点。

图 3-3 CPU使用率

从以上分析可以判断数据库操作性能低下重要在高磁盘IO时导致IO挣用较大导致拖慢整体性能。故本次优化将重点放在解决磁盘IO挣用问题和提高磁盘IOPS上。
4. 优化方案
本着应用层变动最小原则，为解决基本库磁盘IO性能低下问题，咱们将从三个方面着手进行，即：优化数据库物理架构、优化DI任务执行时间和优化数据库数据文献所在Path磁盘VG构造。
4.1. 优化数据库物理架构
依照基本库业务特点，这里将对基本库读写操作进行分离（即：读、写分离）。这样做好处在于可以最大限度规避数据库读、写同步操作所带来磁盘IO挣用问题。调节后架构如下图：

数据库采用主/从模式，使用binlog复制方式实现数据同步。由于考虑到大数据量复制也许带来同步延迟问题，实现时需要注意优化复制线程参数。
4.2. 优化DI任务执行时间
为了避免多任务同步写一种数据库产生磁盘写IO过高问题，需要对每一种DI任务执行时间进行估算，并依照磁盘性能合理编排任务并行度。同步还需要考虑数据单位时间内数据增长量对任务执行时间影响，避免由于数据量增长延长任务执行时间而导致任务并行执行。
4.3. 优化磁盘VG
提高磁盘IOPS最有效办法就是增长通过增长物理磁盘数量并实现条带化来提高整体IOPS。但随之带来硬件投资成本也会增长。这里咱们可以通过将既有磁盘更换成等容量小磁盘，目是为了增长磁盘数量从而提高整体磁盘IOPS性能。如：当前一块磁盘容量为600GB，咱们可以将其拆解成6块100GB Raid5磁盘或者12块50GB Raid5磁盘进行VG条带化解决。
5. 实现
5.1. 资源规划
硬件资源：
Ø 服务器2台
Ø 数据磁盘12块50GB Raid5磁盘（每台服务器）
软件资源：
Ø CentOS 7.1 x86_64 (mini installed)
Ø MySQL 5.7 x86_64
5.2. 磁盘配备
Ø 分别将两台服务器各12块Raid5磁盘初始化并创立VG。在创立LV时特别注意要制定LV所跨PV数量从而实现VG条带化。
Ø 指定磁盘文献系统为xfs。
5.3. 数据库布置配备
Ø 安装MySQL数据库并配备两台服务器主从模式，将从库定义为Read_only模式。
Ø 配备binlog复制线程数。
Ø 优化数据库内存模型。
Ø 导入数据
5.4. 应用配备
将用于数据调度应用程序数据源从本来数据库服务器IP地址改为只读数据库服务器IP地址。
6. 测试
实行完毕后为保证最后优化效果，将对系统各个核心环节进行性能测试。测试将分为如下三个阶段。
6.1. 磁盘性能测试
VG创立好后，保证磁盘可写前提下使用dd命令对磁盘读、写分别进行性能测试。读、写测试将各进行5次从而选出最适当磁盘块大小。使用10GB文献大小，每次创立块大小分别为4k、8k、16k、32k和64k，并记录每次测试时间成果。
6.2. 数据库性能测试
数据库性能测试可以使用tpcc-mysql等其她第三方性能测试工具进行，并生成测试报告。
6.3. 业务测试
最后在实际业务中测试DI运营时间和数据调度响应时间，通过模仿真是业务操作对系统性能进行测试评估。