数据库是金融信息系统不可或缺的重要组成部分。银行业务系统在用的主流数据库有DB2和Oracle两种，对于大规模的关键型应用，通常采用IBM主机的DB2，对于规模稍小的业务，通常采用基于小机的Oracle。随着互联网飞速发展和金融行业自身变革，金融业务种类快速增长、业务量更是爆发式增加，对数据库的要求也随之变高。传统集中式的数据库，不论在管理的数据规模、可扩展性及成本方面，都难以满足需要。另一方面，现有方案也存在价格昂贵、技术生态封闭、相关技术人才市场萎缩等问题，不利于支撑行内相关业务的长远发展。因此，国产分布式数据库成为了金融数字化转型的新选择。

分布式数据库硬件上基于x86开放技术栈，通过将数据分布到多个节点上的方式达到管理海量数据的目的。这些数据并不是简单的分散，而是有一定的组织结构，同时还要能对外提供统一的访问接口，使得数据分布方式对应用透明，应用可以像访问集中式数据库一样来访问分布式数据库，从而简化应用的开发，降低迁移成本。国产分布式数据库GoldenDB支持分布式事务、横向扩容、两地三中心高可用等各种关键特性，有大行核心业务的商用案例，是符合金融标准的国产分布式数据库。

作为某国有大行分布式能力建设项目群的重点组成部分，中兴通讯与客户紧密合作，顺利实现零售贷款业务系统从主机技术栈迁移到x86开放技术栈。零售贷款业务原先运行在IBM主机上，业务采用ALS系统，存储采用VSAM系统（一种基于记录的文件存储系统）。迁移后，业务系统改为自研，存储采用中兴分布式数据库GoldenDB。可知，该业务的迁移范围包括了软硬平台、应用和数据库，改变非常之大。尤其是存储方面，从主机文件存储系统改成了分布式数据库，数据的存储结构、访问方式都完全不同。本文主要介绍数据库迁移的相关要点。

在集中式数据库中，由于架构限制，所有的数据在物理上都是集中在一起存储和使用的。但是在分布式数据库中，情况有所变化。首先其所管理的海量数据可能在逻辑上并不都是紧密相关需要统一管理的，而是需要有一定的区分和隔离；其次，分布式数据库的设计原理就是对数据分而治之，充分利用分布式架构的特点，才能达到更好的效果。因此，我们首先需要了解数据库提供了哪些数据存储及隔离的机制，再结合业务访问要求，做好数据的总体组织和管理。

GoldenDB由计算节点、存储节点、GTM节点、MGR节点等多种类型的节点组成。计算节点负责对应用提供服务，存储节点负责保存数据，GTM负责分布式事务的管理，MGR节点负责整个系统的管理和维护。在GoldenDB中，一组相关的计算节点和存储节点组成一个集群，一套数据库可以包含多个集群。集群之间的计算节点和存储节点是独立的，是相互隔离的，事务不能跨越集群。集群内部的多个计算节点和存储节点是一个有机的整体，事务可以跨越集群内的节点。集群相当于数据库内部一个个独立的单元，可用于数据的组织和隔离。

从业务经营的角度上来看，零售贷款业务总体上划分为大陆、海外两大地区。不同地区的监管政策、营业时间、运维计划等都不一样，这就要求在设计时，要为这两个地区预留足够的隔离级别。很自然的，我们可以用集群来隔离不同的地区。 

如图 1集群设计所示，我们为每个地区规划了一个集群，每个集群有独立的计算和存储节点，这两个是数据库最主要的资源。这意味着不同地区的计算和存储是完全隔离的，一个地区的业务繁忙、存储不足，不会影响另一个地区。

另外，这两套集群共享一套管理节点，这代表我们可以在一套GoldenDB系统中统一监控管理这两个集群，简化运维工作。

分布式数据库的一大特点就是将数据分散到多个节点上，这样的分布显然不是随意为之的，需要有相应的规则，一方面能灵活控制数据的存储位置，另一方面能便于应用访问。在GoldenDB中，这样的数据分布称为数据分片。分片类似于集中式数据库的分区，对指定列的值进行某种计算，得出该行数据所属的分区。差别在于，分区式将数据划分到不同的存储文件中，而分片式将数据划分到不同的节点中。GoldenDB支持DUPLICATE、HASH、RANGE、LIST、多级分片等多种分片方式。

前面说过，个贷两个集群的业务模型是完全相同的，因此，在讨论数据分布设计时，我们以国内集群为例。数据分片的设计需要符合业务访问要求，因此先梳理业务特点。零售贷款业务内部包含6个子系统，这些子系统之间相互独立，所操作的数据也相互独立，跨子系统的交互通过内呼进行，不允许直接访问其它子系统的数据。其中，账务核心子系统，涵盖全行联机和批量交易，是最主要的子系统，占据90%以上的数据量和访问量，是数据库设计的重点。其余5个子系统主要负责参数管理、作业管理等内容，数据量较小，访问模型也比较简单。