孔再华
作者孔再华2020-12-29 14:43
数据库运维工程师, 中国民生银行

民生银行数据库开源可控实践

字数 4284阅读 3050评论 3赞 4

民生银行分布式核心开源实践

民生银行在 2018 年就上线了直销银行分布式核心系统。这套分布式核心架构也成为了金融行业的一个标杆。整个分布式技术平台包括的功能有分布式数据库访问、分布式事务、分布式服务框架与服务管控以及第四分布式批量作业调度,还有分布式配置管理、消息中心、分布式缓存,交易幂等性、统一冲正,全局系列的核心功能,这些所有的核心因素集在一起,构建了分布式的技术核心平台。


在这套分布式核心系统里通过分库分表和读写分离实现资源水平扩展,从容应对高并发加海量数据的 OLTP 应用场景。其中分布式数据访问( CDAL )层实现分库分表和数据访问,而底层采用了开源数据库。这是开源数据库在银行核心重要系统应用的经典案例,也是开源数据库在企业级应用的最佳实践。

民生银行的开源策略

为什么民生银行有信心在核心系统使用开源数据库?其实自 2015 年起,民生银行就已经在开始使用开源数据库 MySQL ,并在使用开源数据库的过程中总结出使用开源数据库作为企业级应用的经验,同时也收获了使用开源的信心。


民生银行不仅仅是在使用开源数据库,事实上民生银行的开源策略是全面拥抱开源技术,当前已经使用的开源产品覆盖所有基础软件领域。民生银行也不仅仅是作为开源的使用者,系统管理中心专门设置了开源软件支持组研究开源软件源码,分析和解决开源软件使用中的问题,同时和开源社区积极保持互动,不仅提交发现的问题,同时也提交问题修复代码贡献和回馈社区,参与开源软件生态建设良性发展。

数据库选型思考

民生银行当前存量的数据库系统大多数是运行在国外厂商的商业数据库上。因为一些众所周知的原因,数据库的可控性也成为当前最重要的课题。民生银行也一直在做新的数据库选型工作。我们认为可控性其实不仅仅体现在选型的产品是国产或者开源,可以避免使用当前商用数据库的政治不确定性,而且还要体现在我们最终选择的数据库产品使用可控性,也就是迁移和使用所造成的风险是否可控。

开源 VS 国产

作为可控数据库选型,我们把目光看向了国产数据库和开源数据库,并且考虑到选型的产品对国产系统和服务器的支持。当前国产芯片主要有国产 X86 芯片和国产 ARM 芯片, 而国产操作系统有麒麟,国产开源操作系统有 openEuler 等。因为暂时并不确定最终的硬件和系统方案,所以当前选择可控数据库,也是要求数据库支持这些国产平台。从民生银行的解读思路,开源数据库和国产数据库都是可选的。

作为国产数据库,为了使用风险的可控,我们需要考察产品的成熟度和厂商能力两个方面。产品成熟度包括产品功能,性能,周边工具支持等能力,而厂商的能力主要体现在研发能力、交付能力、支持能力和发展预期等。

作为开源数据库,为了使用风险的可控,我们需要考察产品的掌控力和开源生态这两个方面。产品掌控力包括自身的代码研究能力和开源贡献者的参与支持能力。开源生态包括产品成熟度、活跃度和周边厂商支持力。

如果上述的思考点满足我们的需求,那么这个数据库产品就具备使用可控性。

集中式 VS 分布式

在可控数据库的选型过程中,我们遇到了另外一个可能性。当前国内数据库在分布式领域实现了弯道超车,出现了很多不错的分布式数据库产品,并且性能和可用性超出了国外的商业数据库。这些分布式数据库的厂商也为国内企业提出了使用数据库更新的理念,那就是采用分布式数据库作为资源池,通过整合数据库资源和多租户的方式实现新的数据库使用方案。到底选择集中式数据库还是分布式数据库作为可控数据库的选型呢?我们需要分析下这两种数据库的特点和当前的实际需求痛点。

集中式 分布式
部署特点 部署场景简单,当前两地三中心部署方案比较成熟。 技术复杂,组件较多,多中心部署方案不成熟。
技术特点 产品性能足以应付大多数应用需求。存在资源纵向扩展上限。 通过资源横向扩展,应对高并发和海量数据场景。
运维特点 周边工具丰富,易于融入当前运维体系。 集群运维复杂性高,与当前运维体系需要改造。
需求 存量多,迁移需求更为迫切。 当前需要通过横向扩展解决瓶颈的系统少。

在这个总结的表格里,我们还是将分布式数据库的初衷作为是否需要分布式数据库的理由,那就是应用是否存在高并发和海量数据,需要通过横向扩展资源来解决性能瓶颈。而当前大量的集中式数据库需要做迁移,从迁移风险和运维风险的角度来说,我们还是偏向于传统的运维模式,采用集中式数据库。这是当前民生银行对于数据库选型的定位。民生银行不仅在考察可控的集中式数据库,也在考察当前的分布式数据库产品以应对性能扩展需求。

OLTP VS OLAP VS HTAP

为什么要单独列出来这个思考点,是因为我们认为这个真的很重要。可能大多数人会觉得银行的系统应该大多数是 OLTP ,少部分是 OLAP 系统。甚至而这些 OLAP 的系统也是可用性需求较低,可以通过 MPP 数据库实现分析场景。 OLAP 系统和 OLTP 系统可以选择不同特点的数据库来分别应对。那么现在的可控数据库选型,是不是可以侧重于 TP 场景的处理能力就可以了呢?

民生银行正在使用的开源数据库就是典型的面向 OLTP 的场景。然而在使用过程中,因为 MySQL 对分析型复杂 SQL 的处理能力较弱,我们对其使用的应用做了严格控制,不允许复杂 SQL ,严控慢 SQL 。因此一方面对于开发要求较高,另一方面也是应该场景受限。而事实上当前运行在国外商业数据库的这些事务型系统,普遍存在较为复杂的 SQL ,只是比例上比较少而已。然而在以往的运维过程中,但凡这些复杂 SQL 出现性能问题,会影响整个数据库性能,造成严重的后果。因此在本次选型过程里,我们把具备 OLTP 性能,同时具备处理复杂 SQL 能力作为非常重要的考察点,也就是选择具备 HTAP 能力的数据库。

数据库选型测评

确定了数据库选型目标后,民生银行针对国内商业数据库和开源数据库进行了一系列的测试和评估,期望找到适合迁移的产品。首先我们定义了数据库选型的测评维度,综合打分。

数据库测评维度

我们将数据库产品从图中 8 个维度来全面测试和评估。通过对国产众多数据库和一些开源数据库的评测, openGauss 数据库暂时成为我们的首选方案。

数据库测评工具

为了更好的测评数据库,民生银行自主研发了数据库测评工具,集成了很多测试项目,全面评估数据库性能。


在这些测试项目内包含金融行业典型的应用场景,同时也包含我们在过往运维过程中遇到过的典型性能瓶颈。例如其中的高并发小交易性能测试,通过极限压力来验证数据库的性能瓶颈,通常能测到数据库内部实现性能上限。而热点数据性能测试也是基于行内一种普遍业务逻辑实现方式编写。这种实现方式会造成的热点数据问题,经常成为性能瓶颈。这样一个测评工具让我们能够横向同比不同的数据库,也更放心这些经过验证的数据库。

openGauss 测评总结

从 openGauss 数据库的测评结果来看,性能上 openGauss 支持混合型负载,不仅高并发在线短交易性能可以,分析型 SQL 运行也比其他开源数据库强。尤其是 openGauss 还支持列存,并且支持行列混合部署模式。 openGauss 脱胎于 postgres9.2 版本,但是修复了很多 PG 存在的问题,例如 32 位事务 ID 回卷问题,全量检查点导致性能抖动问题等。作为新产品, openGauss 支持的功能还在持续开发扩展中。我们很欣喜的看到从发布至今,几乎每个月都有新版本发布, 并且 加入很多重要功能,这是华为研发能力的体现,也是社区蓬勃发展的结果。 目前 openGauss 在一些国计民生行业中已经规模商用。因此我们觉得 openGauss 是一个已经具备商用能力,并且还在快速成长的数据库产品。

openGauss 在民生银行的发展方向

openGauss 产品优势

openGauss 是一款开源关系型数据库管理系统,采用木兰宽松许可证 v2 发行。 openGauss 官网发布了很多企业级增强特性。我们也在选型的过程中去验证这些特性带来的好处。


•多种存储模式支持复合业务场景。

openGauss 支持向量化执行和行列混合引擎。 openGauss 支持的内存引擎我们并没有去验证。不过列存引擎的查询性能和压缩能力确实非常好。

• NUMA化数据结构支持高性能。

通过 NUMA 化内核数据结构,支持线程亲核性处理,可以支持百万级 tpmC 。华为官方发布的数据是鲲鹏服务器上能达到 150W tpmC 。而我们内部测试环境在鲲鹏服务器硬件配置不一样的情况下也能达到 100W tpmC ,超出其他数据库产品。

•高并发 & 高性能

openGauss 通过服务器端的线程池,可以支持 1W 并发链接。通过增量检查点,避免全页写导致的性能波动,实现业务性能平稳运行。 这几个功能也在民生的测试中得到了验证,也是优先于 PG 的地方。

最后 openGauss 产品的迭代速度快,新功能需求和提交的问题能快速得到修复,这也是我们选择 openGauss 的一大重要因素。

三方合作创新

延续民生银行使用开源软件的策略,我们依旧采用这种稳妥的三方合作模式。华为已经官方发布了 6 家国内合作伙伴公司,同时也在大力建设 openGauss 开源社区。民生银行密切与 openGauss 社区和第三方服务商进行合作创新,在实现 openGauss 在企业应用好的同时,也推进开源社区建设。

民生银行 openGauss 发展方向

openGauss 具备以下优点:

  1. 混合负载表现突出。列存查询效率高,压缩效率高。

  2. 华为开发提供,基于木兰宽松开源协议,自主可控性高。

  3. 对国产化服务器和操作系统支持较好。

但是作为新的开源产品,当前的开源生态还是起步培养阶段,需要成长期。对要求全栈国产化的项目,推荐使用 openGauss 数据库。 对于办公类系统和混合负载类系统,优先采用 openGauss 数据库。等待 openGauss 产品和生态成熟后再评估。

结束语 - 拥抱国产开源

民生银行在越来越多的领域使用开源产品并收获匪浅,甚至现在某些领域开源产品的好用程度还要超出商业产品。我们也欣喜看到国内也在不断涌现优秀的开源产品。好的开源生态离不开用户、开发者和社区建设。希望优秀国产开源产品越来越多,生态建设越来越好。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

4

添加新评论3 条评论

#daocaoren0352副总经理, 大同银行
1天前
谢谢精彩讲解。
#yulu4314系统工程师, 长春
3天前
谢谢精彩分享,
#冯岩数据库管理员, 银行
2020-12-30 10:08
多谢孔老师的国产数据库选型测试经验分享! 希望您多多来社区布道!
Ctrl+Enter 发表

本文隶属于专栏

最佳实践
不同的领域,都有先行者,实践者,用他们的最佳实践来加速更多企业的建设项目落地。