民生银行分布式NewSQL数据库实践

作者介绍：周鹏，现就职于中国民生银行信息科技部，负责全行数据库维护及分布式数据库平台建设等工作，具有多年的数据类系统架构设计及调优经验。对于新型分布式数据库、大数据生态系统研究具有浓厚兴趣。

前言

此前，金融信息化建设主要依托原有集中型 IT 架构进行维护扩展，系统规模及复杂程度呈指数级增长，各类瓶颈逐渐暴露，日益增长的数字金融需求同旧式的系统架构缺陷之间的矛盾愈加凸显。中国人民银行、中国银行保险监督管理委员会等金融监管部门逐渐推出分布式转型政策要求，金融企业开始兴起分布式转型浪潮。

民生银行作为中国第一家非国有企业所有的银行以及中国领先的零售银行，管理的总资产为 3.2 万亿人民币，运营 33 家分支和超过 700 家银行网点。在业务创新和技术创新上，民生银行一直走在业界的前列，尤其在人工智能、大数据领域，民生银行做出了很多积极的尝试，取得了不错的成效。

银行分布式转型需求

应用和业务层的压力，给商业银行IT和数据架构带来了新需求和挑战，分布式技术架构转型的需求也就应运而生。商业银行亟需分布式架构转型，主要体现在如下几个方面：

· 提升海量数据系统管理弹性。当商业银行系统内数据量急剧增大时，系统需要弹性地扩容以应对PB级别以上的数据管理，这种弹性容量调整可以实现让所有数据保持在线。

· 提升数据系统管理性能。针对客户的实时需求，商业银行数据系统需要满足高并发业务操作需求，实现海量数据超高性能读写以及实时访问查询。

· 升级数据安全保障。数据安全不仅仅是简单的备份，除了实现数据的持续高可用外，还应支持异地容灾甚至数据中心“双活”，进而保障数据安全。

· 满足多类型数据处理需求，提升系统效率。在跨业务的融合中，亟需实现对多模数据的统一管理，从结构化数据到半结构化数据再到非结构化数据，进而实现不同类型的数据统一融合管理，从而大大提升系统效率。

· 简化开发运维节约成本。随着应用的增多，更需要分布式架构支持，进行数据分区管理，实现业务有效隔离。同时，保持系统的弹性、兼容性，大大简化运维开发。

· 有能力支撑核心业务系统的国产产品。除了数据安全的要求和“技术先进”，对于核心业务，更重要的是对产品代码级具有控制力，这样可以保证产品针对用户共性需求不断进行迭代更新，也带来产品稳定性以及高效强力的技术支持。

民生银行新一代数据库应用情况

目前，在数据库领域，民生银行新一代数据库的应用目前主要分为三个领域。

1）数据库分库分表

针对数据弹性扩容和性能、高可用等要求，我们也针对数据库进行了分库分表改造。目前已经实现Oracle、IBM DB2以及MySQL数据库的分库分表改造，总分库数超过15，分表数超过500张。

2）传统数据库的跨中心分布和双活

我们针对IBM DB2等传统关系型数据库产品进行了跨中心分布和双活的改造。提升总体安全性，提升RTO，RPO，实现“5个9” ，降低风险提高效率，操作过程更简单透明，同时大大提高软硬件资源利用率，节约了建设成本。

3）新型分布式数据库产品使用

除了传统数据库的分布式改造，民生银行也积极尝试新型分布式数据库产品。如国内的分布式数据库SequoiaDB，目前已经在海量数据查询、分布式影像平台和归档数据管理等在线业务系统中规模部署使用。

分布式NewSQL创新实践

当前分布式架构转型的改造已经取得相当成效，但随着我行各类业务负载的不断增大，以及直销银行、互联网金融和人工智能等创新业务的拓展，同时分布式数据库应用也需要向更核心的业务系统推进。当前方案面临新的挑战：

· 开发运维成本： 分库分表方案，在扩展性和性能、并发上仍有瓶颈，且开发投入的各项成本高。分库分表的方案需要预先根据业务对数据库进行切分，这样的方案丧失了较多的弹性，同时在运维层面，也需要投入不小的人力。

· 降低使用和运维成本： MySQL兼容性。开源数据库MySQL目前在互联网行业应用较广，许多应用也基于MySQL开发，但是目前的分布式数据库很多没有实现完全的MySQL兼容，因此在实际投产后，实际的使用和运维成本更高了。

· 进入核心业务场景： 使用开源数据库、中间件方案，由于没有商业化厂商的支持和行业积累，稳定性没有保证，再进入核心业务系统时存在一定风险。

· 国产化要求：在分布式数据库领域，不能过分依赖海外开源产品，需要着重考察国内自主可控的分布式数据库产品。

针对上述需求，我们在分布式NewSQL的创新实践中，经过测试和对比，我们最终选择巨杉的SequoiaDB。SequoiaDB 3.0 版本，目前已经实现完整协议级别MySQL兼容，可以在数据库层面做到分布式并且对已有业务全兼容。同时，巨杉在金融行业已经有过大规模使用考验，在产品成熟度上更可靠。

分布式NewSQL数据库平台，在使用SequoiaDB 3.0 后，体现了几大业务优势：

· 分布式可扩展性：存储层的分布式数据引擎，可以实现数据量的弹性扩容，灵活应对业务需求的调整。

· 微服务架构：整个平台参考了微服务架构，接入层的SQL实例和存储层的存储节点都可以进行自由的配置，应用可以按需选择SQL实例和存储节点。

· MySQL完全兼容：接入层实现了完全协议级兼容MySQL，应用无缝对接，大大降低使用和运维成本。

业务场景测试结果

为了体现NewSQL平台的优势，我们选取了SequoiaDB在几个主要业务场景下的一些测试数据进行说明，这些业务场景可以代表我行的许多重要交易场景：

·  渠道复杂查询场景

此场景以查询为主，查询语句较复杂，涉及4张表的关联，其中包括2张大的流水表的关联操作，每张表记录数达到数亿条，最终匹配结果达到数百条记录。

在实际测试中系统的业务处理能力仍然可达到平均每分钟3,916.45笔，并且运行过程系统的吞吐量表现非常平稳。

· 高频交易流水查询场景

此场景以高频查询为主，主要针对近期的流水记录，查询频率较高。共涉及3张表，其中小流水表和资料表记录条数分别为3000万条，大流水表为3亿条。

通过测试，在该场景下，每分钟的业务处理能力可达到1,886,184.03笔，如此高的吞吐量仍然能够在整个过程中持续保持平稳。

· 柜台业务办理场景

此业务以查询和更新为主，执行频率高，对响应时间要求高。其中查询业务涉及3张表，其中两张资料表为1000万，3000万条数据，维度表数据为1万条；更新操作则涉及资料表1000万条记录和维度表1万条记录。

混合查询和更新，在执行过程中可能出现不同事务对同一条记录的读写冲突，因此吞吐量表现出现一些小幅度波动，但总体平均每分钟的业务处理仍然可达到51,090.03笔。

· 计费业务场景

此业务场景以插入、更新和查询为主，执行频率高，对响应时间要求高。其中查询涉及两张资料表和两张维度表，资料表记录数分别为1000万与3000万；插入操作涉及两张流水表，记录数分别为3000万与900万；更新则涉及一张维度表与一张流水表，记录数约为1万与1亿。

业务场景较为复杂，每笔业务至少包含50余个数据库操作，混合着插入、更新以及查询等多种操作，平均每分钟的业务处理仍然可达到9,861.57笔。，相对波动也比较小。

小结

SequoiaDB 3.0 的MySQL兼容性较为优秀，扩展能力较好，总体性能满足重要交易系统的要求。后续，我们将会把更多现有分库分表方案难以处理的业务向NewSQL平台迁移。

我们也会持续评估未来大规模使用分布式数据库的可能性，充分发挥NewSQL数据库的优势，帮助我们的业务、技术创新，同时也希望我行在分布式数据库建设过程中的可以分享更多成功经验。