交行全国大集中IBP项目亲历记

交行全国大集中IBP项目亲历记
责任编辑：晓熊作者：IT168 牛新庄   2009-06-26  


【IT168 评论】
　　交通银行自从2002年开始做全国的数据大集中，其中IBP(国际业务系统)项目，是实现交行国际业务中现有的国际结算、贸易融资，外汇管理、以及外汇资 金管理服务，覆盖现有的进口，出口，汇款、融资及头寸管理等主要功能，提供总分行各种参数管理，公共控制、公共信息管理、公共业务和打印、查询、报表等辅 助服务，同时，IBP系统还提供与大集中核心帐务系统(简称IBS)，大集中信贷管理系统(简称CMIS)、环球同业银行金融电讯协会(简称 SWIFT)，以及外汇管理系统的连接。是整个大集中业务逻辑比较复杂和技术难度比较高的项目，该项目一期由神州数码公司负责程序编码。
　　项目难点与解决方案：
　　交通银行IBP(国际业务系统)是国内首个基于J2EE架构纯java的国际结算系统。后台数据库为DB2数据库，中间件为Websphere,MQ,运 行在IBM AIX操作系统上，IBP系统采用Browser/Server应用系统架构，利用主流的中间件(Websphere,MQ)系统来接管通讯和交易调度， 以达到交易调度的平台化。
　　该项目的难点主要由以下几点：
　　1由于IBP数据库表结构非常复杂(很多表有几百个字段)，而且总行数据大集中后，数据量非常大，所以项目前期合理的数据库的物理设计和后期的性能调优就非常重要。
　　2由于国际业务系统采用报文传输，而且报文的长度非常大，所以数据库中传统的varchar和long varchar数据类型无法满足业务逻辑需求，所以数据库中使用大量大对象(BLOB,CLOB,DBCLOB)数据类型，由于数据库对大对象类型的访问 无法通过内存，所以大对象类型的存在直接对数据访问的性能产生影响。
　　3由于并发用户非常多，所以在压力测试期间，数据库中有大量锁等待(lock wait)和死锁(deadlock)和锁升级现象产生，直接影响交易并发。
　　4 应用中部分SQL语句比较复杂，而且SQL语句的写法和谓词等方面使用不当，直接造成低效率的SQL运行，占用系统I/O和内存。
　　5数据库中索引构建不合理，存在很多冗余的无用索引，很多应该创建的合理的索引没有构建。
　　6 用户希望把个别频繁访问的小表放在内存中长时间运行，如何解决这个技术难题?
　　7如何把应用(J2EE)，中间件(Websphere,MQ),数据库(DB2),操作系统(AIX)能全局的调优，不至于在某个环节造成全局的瓶颈。
　　对于上述问题，分别采用了如下解决方案：
　　1 在数据库的设计中，采用DB2中的DMS表空间，分别把表中的索引(index)，常规数据(data)和大对象 (BLOB,CLOB,DBCLOB)分割存放在不同的DMS表空间中，并且把DMS表空间放在IBM ESS存储的裸设备(raw device)上，这样大大提高了读写(I/O)的并行访问，优化了数据访问的速度;另外在缓冲池的设计上，创建了多个缓冲池，分别为索引表空间，数据表 空间指定各自的缓冲池，这样可以使它们减少对一个大缓冲池的竞争，从而减少交换(swapping)操作，提高从缓冲池命中率(hit ratio)，提高访问速度。下面是部分数据库设计的脚本：
　　缓冲池：
　　IBMDEFAULTBP 1000
　　DATA_DMS_4K_BP 128000
　　INDEX_DMS_4K_BP 76800
　　INDEX_DMS_8K_BP 12800
　　BP_DMS_32K_BP 1000
　　DATA_DMS_8K_BP 25600
　　BIGTAB_DATA_4K_BP 25600
　　BIGTAB_INDEX_4K_BP 25600
　　WFW_DATA_4K_BP 12800
　　WFW_INDEX_4K_BP 12800
　　表空间：
　　Name = SYSCATSPACE
　　Name = TEMPSPACE1
　　Name = USERSPACE1
　　Name = LOB_DMS_8K
　　Name = DATA_DMS_8K
　　Name = LOB_DMS_4K
　　Name = DATA_DMS_4K
　　Name = INDEX_DMS_4K
　　Name = INDEX_DMS_8K
　　Name = BIGTAB_DATA_DMS
　　Name = BIGTAB_INDEX_DMS
　　Name = WFW_DATA_DMS
　　Name = WFW_INDEX_DMS
　　Name = BPBD_DMS_32K
　　Name = BPBD_32K_SYS_TMP
　　Name = BPBD_8K_SYS_TMP
　　同时，由于数据库中存在大量连接(join),分组(group by),排序(sort)操作，所以为了提高这些操作的速度，对系统临时表空间所在的文件系统预留了大量文件系统空间。
　　2在最初的数据库物理设计中，数据库中共有238个大对象的字段，这个大对象类型的存在，对系统的性能和I/O读写直接带来性能的低下，为了减少这些大 字段，和业务人员详细了解了业务需求，避免了无必要的加大大对象的长度，考虑把有些大对象用varchar代替(例如：原来长度为8000字节的大对象用 两个长度为varchar(4000)的字段代替，最后对这两个字段再做concat的字符合并操作)，经过详细了解和间接的采用一些技术替代大对象后， 最后数据库中只有35个对象，大对象的减少直接带来了I/O访问速度的提高。
　　3系统在上线投产前期进行压力测试期间，数据库中有大量死锁和锁等待出现，为了解决上述问题，首先，需要加大相关数据库中有关锁的参数 (locklist,maxlocks,locktimeout和dlchktime)等数据库配置参数;其次，为了让锁的快速释放不至于引起交易阻塞， 就需要我们在表上创建合理的索引。所以，造成引起锁等待的应用程序和SQL语句，对这样应用和SQL进行合理的构建索引。
　　4 应用开发中的很多SQL语句运行效率低下，这些SQL语句在写法和谓词使用存在很多问题，例如：大量使用select *,select count(*),使用not in，not exist，使用函数等，对于这些问题，需要对开发人员详细解释如何高效的使用SQL，所以给相关开发人员专门讲解三天的SQL使用和如何编写高效的 SQL。
　　5应用开发人员往往凭借自己对业务的理解在表上建立了很多索引，结果是这些索引在SQL执行期间根本没有使用，这些冗余索引的存在直接导致了空间存储的 浪费和对插入(insert)操作的影响;所以，正确的做法是我们应该正确的分析该表的读写情况，分析表中SQL语句执行的频率，对每一条SQL语句做解 释(explain)从而来评估为该表创建最合理的索引。
　　6使用缓存(cache)表来解决上述问题，该特性是DB2数据库新增加的一个特性，要能够合理的把数据库最新的最先进的技术运用到我们的数据库设计中。
　　7 调整操作系统交换空间(page space),内核参数;调整数据库配置参数;合理的设置websphere的相关和数据库的接口配置，调整应用性能;最后用压力测试软件来找出引起性能的瓶颈并解决各个层面的瓶颈。
　　项目成功与失败的经验归纳：
　　IBP项目已经在2004.7.14日杭州第一家正式上线，上线近两年来，系统非常稳定和高效的运行，IBP项目的成功经验有以下几点：
　　1 数据库前期的合理的架构设计(物理设计和逻辑设计)是整个项目成败的关键，合理的架构设计为整个项目稳定可靠高效运行打下了良好的基础，同时也起到了事半功倍的作用。
　　2 根据系统的物理资源，对数据库的配置参数做合理的调整，保证系统物理资源(CPU,I/O，内存和网络)和逻辑资源(裸设备，文件系统等)合理的分布和应用。
　　3 在应用层，要保证编程人员编写高效的SQL，通过对相关编程人员专门的进行SQL培训，培养他们养成良好的编写高效SQL的习惯;对编程人员讲解SQL 执行的原理和步骤，教会他们如何使用相关解释工具(explain)来对SQL进行分析解释从而来选择最合理的执行计划(access plan)。
　　4 要学会充分运用数据库中最新的数据库技术运用到实际的编程应用中(例如：DB2 V8中的缓存表等技术)。
　　5 要结合不同的数据库产品，在保证业务逻辑允许的情况下，使用合理的隔离级别(例如：UR隔离级别)来最大程度上提高数据库的并发。
　　6 对数据库创建最合理的索引(太多，影响insert速度，浪费存储;太少，不能显著提高查询速度)，尽量的多创建复合索引和包含(include)索引。
　　我具体在项目中负责的内容有：负责完成交通银行IBP国际业务系统的整体数据库物理设计和逻辑设计;负责完成数据库后期的性能监控，性能调优;负责培训编程人员如何编写高效的SQL， 从而使整体应用运行效率提高;负责构建数据库的索引并删除冗余的索引;负责制定IBP项目的备份和恢复策略;负责制定IBP项目的安全策略;负责培训交通 银行全国各分行技术人员。
点此发表你的看法>>【已有4位网友发表了看法】