民生银行十位数据库专家谈如何透过性能优化看系统架构的合理性（中）

接上篇“民生银行十位数据库专家谈如何透过性能优化看系统架构的合理性（上） ”

4 案例分享

为了更好地理解架构设计中的性能问题这一主题，我们尝试例举几个我们在实际工作中有着深刻体会的案例，期望读者能够在这些实例的基础上举一反三，在自己的场景中找到这种问题的解决办法。

4.1应用模型不清导致的性能问题

随着金融体制改革日益深入，中外银行间的竞争将更加激烈。与此同时，客户的金融需求也呈现出多元化倾向。目前竞争的关键就在于，怎样发现优质客户、避免优质客户流失。就银行业务而言，一方面要推出个人理财服务、私人银行业务等业务来争夺高、中端客户。这就需要业务系统要能够及时响应客户的需求，做到快捷、便利的服务。另一方面，银行的客户经理必须对客户信息进行收集整理和分析挖掘，利用现有的客户资源优势，把零散无序的数据集中起来，挖掘出为银行创造利润的客户，并为这些客户提供更优质的服务，这是业务系统的又一个重要目标。这样就提出一个很现实的问题：业务系统的数据库是OLTP的还是OLAP的？

4.1.1什么是OLTP和OLAP

当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

On-Line Transaction Processing联机事务处理系统(OLTP)，也称为面向交易的处理系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，OLTP 系统旨在处理同时输入的成百上千的事务，其基本特征是满足在大并发的情况下针对事务的实时响应，所以也称为实时系统(Real time System)。衡量联机事务处理系统的一个重要性能指标是系统性能，具体体现为实时响应时间(Response Time)，评估其系统的时候，一般看其每秒执行的事务数以及sql的数量。典型的OLTP系统如电子商务系统，银行，证卷等等。

On-Line Analytical Processing联机分析处理系统(OLAP)，有的时候也叫DSS决策支持系统，联机分析处理的用户是企业中的专业分析人员及管理决策人员，他们在分析业务经营的数据时，从不同的角度来审视业务的衡量指标。例如分析销售数据，可能会综合时间周期、产品类别、分销渠道、地理分布、客户群类等多种因素来考量，OLAP中其实还有一类使用人员，比如银行中的客户经理，营销人员，业务人员等，他们不需要报表，而是实时的查询，并且该类查询一般都是关联很多表的复杂查询，进行数据分析和信息综合，提供营销支持，对实时性要求也比较高。下表列出了OLTP与OLAP之间的比较。

4.1.2具体案例

4.1.2.1项目背景及概述

比如行内以前的某系统，该系统主要负责银行卡的积分礼品兑换，但是由于该系统的应用特点，它数据库里面同时也存放着大量的用户相关信息，可以用来支持客户经理、业务人员等进行信息的查询和分析，支持多维度的市场营销行为，基于该特点，在项目设计之初，开发人员将过多的精力放在了功能需求的满足上，在该系统上开发实现积分兑换和业务数据分析两个功能，但是从数据库的角度看，这两个功能其实对应到数据库访问行为上一个是OLTP，一个是OLAP，从而在设计之初就埋下了性能问题的隐患。

4.1.2.2投产后的性能问题

1）数据库锁现象严重投产后关于性能方面一个比较突出的问题就是锁冲突的问题，由于OLTP和OLAP对数据库访问模式的不同，对数据库锁的要求也不同，两种不同类型的应用同时运行，造成大量的锁升级、死锁和锁等待，虽然按照标准的数据库调优步骤，增大了locklist和maxlocks的值，仍然无法完全解决锁冲突的问题。

2）磁盘I/O出现瓶颈实际运行过程中，磁盘I/O也出现了瓶颈，为了提高数据库的性能，尝试了对数据库服务器数据的条带化分布，将数据文件对应的文件系统分布在不同的磁盘上来提高性能，虽然个别的单个事务的执行效率会提高，但是总体对数据库的性能提升有限。

3）创建索引无法改善总体性能由于OLTP系统查询相对简单，依靠建立适当的索引保证查询速度，但是索引只能解决那些预先定义好的问题，对OLAP的应用性能提升有限。

4.1.2.3最终的解决办法和效果

临时解决办法：应用开发人员对应用的并发进行限制，主要是限制OLAP的访问的并发数，并针对此开发了应用队列的管理，一旦OLAP的并发数超过阈值，便进入应用队列进行排队，以此来保证OLTP数据库访问的及时响应，最大限度的保护实时业务的响应时间。

最终解决办法：经过应用开发人员和DBA多方努力无效后，最终还是达成统一共识：导致性能问题的主要原因是应用模型不清，对业务的行为及其对数据库的访问模式的区别进行了认真的总结，最终决定将应用和数据库进行拆分，实现OLAP和OLTP业务访问的分离，形成交易库+查询库的架构，同时为了及时的给交易库瘦身，又搭建了归档库，最终形成了交易库+查询库+归档库的数据库架构，分拆后，锁的问题，磁盘读写问题，应用的并发都得到了很大的改善，取得了良好的效果。

4.1.2.4其他可以参考的技术

为了更好的支持OLTP或OLAP的业务处理，各个厂商也都推出了不同的技术，目前的主要方向有两个：一是利用数据库本身开发的技术，比如DB2的DPF，PureScale，ORACLE的RAC等，另外一种是专门针对OLAP系统的一体机比如Netezza，TeraData, Greenplum,ExaData等。下面简单介绍一下其中几种技术的工作原理和设计理念。

DPF：即Database partitioning feature, 是 DB2 企业版 DPF(Data Partitioning Feature)选件提供的，它主要用来为大规模数据处理、高并发数据访问提供支持。分区数据库功能采用非共享的架构，也就是前面描述的Sharing Nothing架构，数据库被分为多个分区，每个分区运行在不同的服务器节点上，各分区拥有独立的引擎、日志管理、锁管理、缓存管理等资源，实现并发多处理机制，适用于大型数据仓库（OLAP），提供强大的扩展性和性能。在DPF架构中，数据通过 Hash 算法均匀地散列到不同的分区内，每个分区只负责处理自己的数据。当用户发出 SQL 操作后，被连接的分区被称为 Coordinate Node，它负责处理用户的请求，并根据 Partition key 将用户的请求分解成多个子任务交由不同分区并行处理，最后将不同分区的执行结果经过汇总返回给用户，分区对应用来说是透明的。

pureScale是DB2基于活跃-活跃式共享磁盘的数据库集群技术，也就是前面描述的share disk（共享磁盘）的架构，它是继承IBM主机的Sysplex技术而来，用来提供高可用性，在一个节点失效的情况下，可以提供不间断服务（切换时挂起时间在20秒内）。

每个节点拥有不同的CPU和内存资源，共享同样的数据库磁盘，这些节点在形式上是对等的，可以通过网络磁盘技术同时操作一个数据库文件或者日志文件，不同节点之间通过InfiniBand网络的直接内存读写（RDMA）技术实现数据在内存的直接读写，最大限度的避免了网络延时。

由于各个节点是对等关系并且没有任何持久化的资源，因此添加节点实现线性扩展将变的非常容易，通过其扩展特性可以支持更大的在线并发处理，同时它相对于应用时透明的，运行在 DB2 pureScale 环境中的一个应用并不需要知道集群或者分区数据的不同成员。DB2 pureScale Feature 会自动地将应用转发给它认为最合适的成员。该技术比较适合OLTP，ORACLE的RAC跟purescale原理类似。purescale架构概览如下：Netezza:数据仓库软硬件一体机的提供者，该公司于2010年被IBM收购，这种一体机适合数据仓库类高性能运算，它采用大规模并行处理（MPP）架构，同时在每个MPP节点内部的FPGA进行加速运算，针对庞大的数据量能够以“流水线”的方式进行分析处理，该架构下的各个组件已经进行了优化，不需要进行索引或对系统做调整或优化。属于Sharing Nothing 架构，适用于大型数据仓库（OLAP）。架构如下：4.1.3小结

本节通过举例，重点强调了应用模型不清可能会导致严重的性能问题，如果项目设计前期不重视应用模型，不仔细分析应用的访问行为的话，一旦生产系统投产，就会将所有的压力压到数据库上面，如果通过数据库性能调优也没有办法很好解决，再进行应用模型的修正和改造是很费时费力的，所谓“磨刀不误砍柴工”，所以设计清晰明了的应用模型对性能是相当重要的。

4.2良好的存储规划对性能的提升

数据库中数据的访问离不开I/O行为，所以I/O的性能对数据库性能有着致命的影响，因此作为I/O行为的具体执行者-存储系统的性能就显得至关重要。而存储系统的特点又决定了事先的规划远远重要于事后的调优。

存储系统作为应用处理的最终数据承接端，存储系统性能直接影响应用系统及关联应用的处理效率和运行可靠性，通过存储系统规划使得存储资源运行方式更加贴近业务运营需要，存储资源保持合理运行状况，最终应用系统获得很好交易处理响应时间和更强业务承载能力。

为了更好提升系统运行可靠性和安全性，结合应用特点采用主机LVM、数据库HADR及存储SRDF等不同层面的保护技术，这些技术的使用都会对系统运行性能带来一定压力，因此更加需要切合实际的存储规划为系统运行性能奠定基础和保障，并且扩展系统运行性能的提升空间。

存储规划以业务的服务要求和应用特征，结合主机、数据库及存储资源配备状况，根据行业特征及技术平台最佳实践，设定明确和切实的服务目标，作为支撑的存储系统及关联环境的规划的基础，基于服务目标确定有效规划原则，进行方案设计和系统部署。

4.2.1良好存储规划的目标

良好存储规划目标从业务服务需求出发，尤其重点关注交易响应时间和交易处理的持续并发能力，存储系统资源规划从部件响应能力为基础，降低存储系统热点、容灾、利用率及维护对服务能力影响。

1）降低主机磁盘响应时间重点分析规划影响主机磁盘响应时间的关键因素涵盖数据处理IO特征、数据保护方式、部件利用率、数据处理并发性。

2）降低资源热点对性能响重点分析规划存储连接端口、缓存、磁盘及磁盘控制卡，以及交换机端口，分析排查IO等待队列、Pending数据、命中率等数据特点。

3）降低容灾保护对性能影响重点分析规划容灾数据高写负载数据卷、容灾数据卷数据量及写数据的均衡能力，以及容灾数据处理的链路响应等。

4）合理存储资源利用率定位重点分析规划存储连接端口、缓存、磁盘、磁盘控制卡及容灾控制卡，以及交换机端口，分析部件利用率运行状态，部件利用率直接影响数据处理响应时间。

5）降低部件故障对系统性能影响重点分析规划存储连接端口、缓存、磁盘及磁盘控制卡，以及交换机端口等系统部署冗余性，分析排查系统冗余部件的耦合性。

4.2.2良好存储规划的原则

依据存储规划目标为基础，确定通用的系统部署原则，指导系统方案的设计实施，同时经过系统测试验证，对相关原则进行补充修订。

1）有效而合理Stripe方式采用存储数据卷的META Stripe作为磁盘基本划分，在此基础可以封装主机或数据库的Double Stripe方式，通常LOG区域的Stripe Size建议保持64K。关键及重要业务系统建议采用Mirrror方式，卷组成员建议8-16的磁盘数量。Clone数据卷为了节省数据空间，可以采用RAID5方式，建议采用RAID7+1方式。

2）全面细致的部署资源平衡存储阵列系统的部署资源包括FACPU、FAPort、Cache、DA、磁盘，以及数据卷Hyper卷在磁盘分布平衡。存储交换系统的部署资源包括交换机之间、ISL通道、Port、ASIC数据通路分布平衡。

3）资源部署单元化降低故障影响面

存储阵列系统的部署资源包括FACPU、FAPort、Cache、DA、磁盘，建议分布在不同控制卡中。存储交换系统的部署资源包括交换机之间、ISL通道、Port,建议分布在不同交换机和控制卡内。

4）降低数据和索引空间对LOG空间影响建议数据库的数据和索引空间与数据库LOG空间进行独立磁盘划分、使用独立的磁盘。

5）磁盘分组规划保护关键业务资源建议对阵列磁盘分组划分，创建独立clone磁盘组作为Clone数据专用，创建两个数据磁盘组和一个LOG磁盘组，同时META数据卷的选择要求遍历不同磁盘。

6）合理有效数据卷数量提供容灾性能保障建议在保证使用容量数据卷的基础上，尽可能多使用Hyper数量，提升容灾性能，建议采用META 8数据划分。

7）关键业务的支撑环境部件性能利用率不超过50%通常支撑部件在利用率40%以下保持良好的数据处理响应时间，存储阵列系统FACPU、FAPort、Cache、DA、磁盘部件利用率，对于关键系统使用部件利用率建议不超过50%。

8）关键业务系统进行支撑部件独享，其他系统业务峰值平摊关键业务系统使用独立的存储阵列系统FACPU、FAPort。其他业务在磁盘系统进行业务系统平摊，对于关键业务影响很大的应用系统建议分布到其他磁盘组中。

4.2.3良好存储规划的过程

良好存储规划以规划目标、规划原则、规划方案及系统部署四个环节进行系统统一规划部署，进行相应数据分析对比，通过多次系统测试验证，提高系统规划质量和平台支撑能力。存储性能规划过程。

4.2.4效果对比

B系统经历多次压力测试，在存储调优之前，集中处理的大任务的执行时间有85% 左右在数据库中，性能的瓶颈出现了数据库层面。而且总的执行时间大幅度的超过了设计目标，某个的大任务的执行时间达到了8小时。

经过多方的深入分析，基本得出了结论：数据库本身的优化空间很小，主要的优化方向应集中在存储层次。

存储系统针对每次测试的特点，深入的分析了存储系统存在问题，有针对性的对规划进行了修订和对部署方案进行了调整，下面是比较重大调整的效果对比分析：

1）Host Stripe调整效果分析4月12日B系统使用LOG空间Pr2log1存储空间使用方式调整成Stripe方式，Stripe Size为64KB，在未启用SRDF情况下，主机使用LOG空间磁盘的写响应时间由15ms降低为0.7ms.

2）FA端口扩充效果分析FA端口经过多次扩充，4月25日B系统主机系统与存储系统使用FA关系为1：1关系，在未启用SRDF情况下，主机使用数据空间磁盘的写响应时间由11ms降低为4.5ms.

3）容灾端口扩充效果分析RF端口经过扩充，5月15日B系统主机系统与存储系统使用RF端口数量由4RF扩充到8RF，在未使用Extanded License和未加BufferCredit情况下，主机使用数据空间磁盘的写响应时间由69ms降低为45ms.

4）存储交换机增加BufferCredit及数据卷Stripe调整效果分析5月31日，存储交换机使用Extanded License和增加BufferCredit=200，同时B系统主机的Data&Index采用HostStripe为64K情况下，主机使用数据空间磁盘的写响应时间由45ms降低为16ms.

4.2.5小结

从上述对比测试中我们可以看到，以上的调整对性能的提升有极大的帮助，随着存储层次的I/O time大幅度的缩小，业务的执行时间也有着非常大的变化，如批处理时间由原来的8小时缩短至不到3小时，这对性能的指标来说有着质的飞跃。数据库部分的所占用的处理时间比例也大幅度的降低，数据库不再成为业务性能的瓶颈。

未完待续

作者：牛新庄,袁春光,朱彬,王健,陈晓峰,胡经伟,曹伟伟,刘星,詹玉林,甘荃

本文节选自：《数据库与信息治理》