luxh08
作者luxh082021-05-06 14:47
科技部门副总, 某互联网银行

银行核心系统场景使用分布式数据库选型及应用难点探讨总结

字数 8819阅读 3237评论 1赞 6

银行传统业务模式受限,面对业务转型,发展互联网业务来实现突破,但是互联网业务特征是海量用户、大量数据和大并发的交易,这种潮汐业务特性对数据库带来了性能和容量方面的挑战,这就需要采用技术先进性的分布式数据库来应付互联网业务带来的一系列的挑战。价值不在数据库本身,不能为了技术使用分布式数据库,银行采用分布式数据库的价值有三点,首先是驱动互联网业务的快速稳定的发展,通过分布式数据库的强大的数据处理能力,来加强风控能力和业务决策能力建设。第二是通过数据库的标准化和轻量来解耦应用和数据库架构,让应用不依赖底层数据库技术,实现真正意义上的自主可控,为数据库国产化在技术实现上扫清了道路。三是降低科技投入,在预算投入方面,减少了高端小型机和存储的采购成本。在人力运维方面,减少分库分表对开发工作的成本,减少了节点扩容成本,全局一致性维护成本等。

银行在选型分布式数据库的难点探讨:
一是复杂业务逻辑问题,包括数据库技术基因匹配性,包括数据库本身锁机制、隔离级别问题,包括技术兼任性,比如存储过程、视图的兼容性。
二是应用的适配度问题,银行应用大部分都是基于单机关系型数据库机制设计的,例如大部分场景都是串行机制,发挥不出来分布式数据库的强大并发处理技术,反而分布式数据库本身的二阶段提交机制,对简单事务的延时增加问题,造成串行事务执行性能低下。
三是人员能力的匹配性,需要根据人员技术能力进行选型考虑,例如基于Spanner体系,基于Aurora体系,基于国内互联网公司自研的产品等,要考虑现有人员对数据库技术的了解程度,更要关注数据库技术本身的开放度和社区热度,让人员可以很快的学习和提升数据库技术能力。

以下内容重点是本场分布式数据库选型沟通的交流总结:

1、传统关系型数据库、中间件+数据库、原生分布式数据库使用原则?

1、随着newsql数据库发展,数据库可以说是百花齐放,对于银行业应用系统来说,传统关系型数据库、中间件+关系型数据库、原生分布式数据库使用原则从几个维度考虑?
2、对于某些OLAP应用来说,基于中间件+关系型数据库、原生分布式数据库、或者nosql数据库(hadoop、mpp)都可以实现时,是从几个维度考虑使用什么数据库的?

回复:fanyqing 系统架构师 , 厦门银行
问题1。
传统关系型数据库,如Oracle、MySQL、DB2等,支持SQL操作,具备ACID属性,通常用于处理业务数据较小的OLTP。随着业务数据的增长,传统关系型数据库已慢慢无法满足业务需求,于是,应用系统开始考虑分库分表的方式,即将一个业务系统的数据按照一定的规则,分布到多个数据库上,这样每个数据库需要处理的数据可以更少,以此满足业务系统不断增加的数据处理需求。中间件+分布式数据库模式就是属于此种情形。其中中间件主要用于数据的分片与分布式事务的处理,对应用来说是透明的。因此,中间件+分布式数据库主要用于数据量大的OLTP业务。而原生分布式数据库需重构数据库系统,原生支持分布式事务处理与数据切分,原生分布式数据库根据其数据处理引擎,有些适用于OLTP场景,有些适用于OLAP场景,还有些适用于离线分析场景。因此,我们在选择数据库时,首先要考虑是应用于哪类业务场景,其次要考虑该业务所要处理的数据量、数据增长的速度,业务的并发量等。如果选择的是中间件+关系型数据库,在数据库设计时,需要特别注意分区键和分区策略的选择,合理布局数据,尽量避免跨节点的分布式事务处理,以提高数据库的效率。
问题2:
对于OLAP应用,虽然各类数据库都可以实现业务数据的处理需求,但实现的成本和实现的效果大不不同。比如,关系型数据库(包括中间件+关系型数据库),大都采用行存,适用于OLTP场景,如果用于OLAP,虽然可实现业务能力,但效率较差。即使是原生分布式数据库,因重构数据库系统,也要根据数据处理引擎,选择合适的原生分布式数据库来处理OLAP业务。至于NoSQL,因SQL支持能力有限,如果要用于OLAP,会增加应用的开发难度。故在实际应用时,需要根据业务场景,以及自身发技术储备,选择合适的数据库。

2、银行的核心系统数据是强一致性,那么分布式数据库的数据强一致性如何保证?安全性如何保证?

回复1:luxh08 科技部门副总 , 某互联网银行
Newsql分布式数据库基本都是通过获取全局时钟时间戳,采用二阶段提交实现一致性,可以实现一致性的保证,分库分表架构对于事务的一致性,需要应用层考虑,比如通过合理的分区键设计来规避。

回复2:
分布式数据库对于跨节点事务目前还是实现的最终一致,对于全局一致性读,一般通过引入类似全局时间戳的组件统一管理全局事务,在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库,对于要依赖分布式事务“中间状态”的业务,优先进行业务改造进行规避,其次通过合理的数据分片设计让其在单节点内完成。

3、如何评估银行分布式数据库项目的整体成本?

如何评估银行分布式数据库项目的整体成本?相比Oracle性价比怎么样?

回复1:顾黄亮 技术总监 , 苏宁消费金融有限公司
成本可以分为开发测试成本、数据库的软硬件成本、运营维护成本等。开发测试成本主要是开发该项目的人力成本,这个因项目而异。分布式数据库的硬件成本主要包括PC服务器加本地SSD盘,软件成本因厂商而异。有其他文章进行过比对,引用如下:

回复2:luxh08 科技部门副总 , 某互联网银行
根据具体的情况不一样,成本表现也不同,根据我行的经验,硬件成本》运维成本》
应用改造成本,我们在数据库规范这块做的比较彻底,很早就执行了统一的标准,不容许采用存储过程,事务大小限制,统一mysql数据库协议等措施,所以应用基本上在mysql数据库和分布式数据库之前迁移应用改造成本很低。
运维成本由于之前数据库方向就是确定mysql,运维人员的技术储备都是满足分布式数据库的要求,mysql和分布式数据库的转换成本很小。
我们采用分布式数据库,最大的成本就是硬件成本,由于分布式数据库对服务器处理器和IO要求较高,并且由于我们采用的分布式数据库的产品对租户隔离性做的不好,造成重要应用都是当个集群,单个集群最小的服务器数量是6台,所以我们分布式数据库的PC服务器投入量很大。
由于我们采用的分布式数据库是开源运营方式,如果不考虑厂商的服务可以不用采购,我们针对重要系统购买了一部分license许可,外围系统都是自主运维,所以在成本上相比oracle要便宜很多。

4、银行核心场景是否适合上分布式数据库?如果要上需要达到什么客观条件才可以?

银行目前大部分使用的都是集中式数据库(oracle DB2等等),如果有想法平滑过度到分布式数据库,银行内部需要做哪些准备工作?银行核心场景是否适合上分布式数据库?如果要上需要达到什么客观条件才可以?否则盲目上就是一个坑

回复1:顾黄亮 技术总监 , 苏宁消费金融有限公司
毋庸置疑,银行的核心系统是可以上分布式数据库的,无论是交易核心还是账务核心。
银行在数据库选型,需要考虑四点,分布式事务、性能、数据备份、高可用。在过程中需要根据不同的场景进行应用的改造和数据库架构的设计,举个简单的例子,账务核心进行跑批,亿级的海量读取的需求,需要采取分布式数据库模式,另外还有分布式访问客户端和分布式中间件模式可以选择。
以笔者的经验,客观条件取决于四点,1、科技是否有足够的能力进行系统的迁移;2、运维是否有能力进行分布式数据库的维护;3、业务是否能够接受数据库换型期间的业务中断时间;4、是否有相对明确的数据量和并发数的指标。

回复2:luxh08 科技部门副总 , 某互联网银行
根据我行的经验,就是通过数据库的技术标准化和轻量化工作,形成统一的数据库使用规范,解耦应用和底层数据库技术架构,在统一的Mysql数据库协议下,可以很轻松的更换数据库架构,通过Mysql和分布式数据库的互相同步机制,可以实现业务的无感切换和迁移回退。
银行核心系统场景是典型的OLTP,有大量的针对数据库的记账类更新操作,单个update或者insert操作的性能,单机库是分布式库的几倍以上,在热点账户场景对分布式数据库带来了严重的性能问题,造成了记账超时带来的客户短款问题,核心系统考虑分布式数据库的条件是,需要做大量的应用改造来弥补数据库的问题,比如热点账户场景子余额改造,比如联机场景改造为批量场景,之后需要经过严格的测试,比如生产流量复制测试,引入混淆测试平台。

5、银行核心的分布式数据库,除了newsql,还有哪些可选?各有什么优缺点?

回复1:
分布式数据库产品目前市场上流行的有很多,主要是纯自研原生数据库和基于中间件的数据库,这些产品大部分都能满足银行核心需要的相关技术指标,但在选型时还要考虑以下几个实际问题:
1、第一,是否真正经历了互联网海量数据的考验?例如有些数据库功能测试能满足需求,但是没有经过互联网大流量打磨,并发一大,时间一长,其稳定性要打问号,这种风险银行是否愿意承担,承担风险的投入和应对策略怎么样。
2、第二,满足了互联网大流量洗礼,跟实际适配银行传统核心还有较大的距离,业务场景差异较大。如果业务场景在SQL设计的时候能够严格执行小事务和无表关联,那分布式数据库的才能真正具备可扩展,性能才能发挥到极致,互联网公司在使用分布式数据库时基本都是按照这个要求去设计的;但是银行传统核心基本都是大事务,且表关联较为频繁,直接应用分布式数据库会有各种适配问题,一致性问题、大量分布式事务、跨节点数据流动扩展性差等等问题。要银行核心适配分布式数据库,实施团队起到决定性作用,这个实施团队包括分布式数据库厂商、核心应用厂商以及银行方,分布式数据库厂商和应用厂商如果有改造落地经验,行方的压力会小很多或者基本没压力,如果没有经验,大家都是第一次适配,那需要三方都要投入大量的资源,数据库和应用都要适配改造,行方的压力都较大。
3、第三,分布式数据库厂商的情况也要重点考虑:该产品的技术演进路线如何,产品推广策略如何,后端技术支撑能力如何,产品版本迭代情况如何,产品前景如何,有没有成功案例或者成功案例多不多。银行核心不轻易动,动了就是要用五年甚至十年,大量银行核心普及了分布式数据库后,选择“靠谱”的分布式数据库厂商很重要。

所以笔者认为,想明白了这三个问题,自己想要什么样的分布式数据库,再去关注各分布式数据库的具体技术指标和特点,思路会更清晰。

回复2:fanyqing 系统架构师 , 厦门银行
NewSQL是新一代SQL数据库的统称,市场上的分布式数据库大都属于NewSQL范畴。NewSQL的实现有两条技术路线:中间件+传统关系型数据库方式和原生分布式数据库方式。
中间件+传统关系型数据库方式中,中间件不保存数据,负责数据的分片、数据汇总和事务的一致性等功能,后端的关系型数据库负责数据的处理,因此,大都用于数据量大、并发要求高的OLTP场景,在实际使用时,应注意分区键的选择,应用设计时,一个交易尽量不要跨节点使用数据库,以提高分布式数据库的性能。
而原生分布式数据库因重构数据库系统,原生支持分布式事务处理与数据切分。在实际使用时,应根据业务场景,从数据的分片策略、数据的更新方式、数据的存储结构、日志类型、数据的一致性技术等方面进行数据库的选型。如对于写敏感的业务,分片策略可以选择Hash方式,保证数据的平衡分布,数据更新方式可以选择Append-Only方式,提高写性能;分析型业务,在数据库选择时,数据的存储结构可选择列存,数据如需回滚,应支持undo log等。

回复3:luxh08 科技部门副总 , 某互联网银行
分布式数据库分为两种技术架构,中间件+分库分表和NewSQL架构,中间件分库分表架构发展历史较早,技术比较成熟,在大型互联网公司有着大规模的使用经验,但是需要改造应用分区键进行适配,有代码改造成本,而且后期的节点扩展和运维都比较复杂,NewSQL架构是一种全新的数据库架构,架构分为两个部分,计算层有关系型数据库SQL引擎,并且可以保证事务的ACID,存储层是采用Key-Vaule技术实现存储级的分布式引擎,结合了关系型数据库和Nosql的优点,优点是没有应用改造成本,分布式架构对于应用透明,就和使用单机数据库的习惯一致,后期的节点伸缩都非常简单,不需要任何人工的干预,缺点是技术比较新,使用案例较少,并且有一些功能和特性的限制。

回复4:顾黄亮 技术总监 , 苏宁消费金融有限公司
目前市面上分布式数据库产品很多,比较流行的主要有pingcap的tidb,巨杉的sequoiaDB,阿里的OceanBase、polardb,腾讯的Tbase、tdsql,华为的gaussdb,亚信的antdb等。各个产品大致特点如下:

6、现有分布式数据库是否能承载核心下移数据的交易量?

对于分布式系统改造,如对传统金融的如400核心的数据库进行分布式数据库改造,分布式数据库是否能承载核心下移的交易量、稳定性及性能要求。

回复:
目前银行传统核心中小行和大行都有成功改造的案例,全国性大行像中信银行的新核心(基于中兴GOLDENDB),平安银行信用卡新核心(基于腾讯TDSQL)都是分布式数据库的,所以通过相应的适配改造,主流分布式数据库能够满足银行OLTP类的业务的交易量、稳定性和性能要求。

7、处理返回数据集很大的并发场景适合用哪种分布式数据库?

哪种分布式数据库适合处理返回的数据集很大(几兆几十兆)的并发场景?有一批实时的时间序列数据,需要按时间来查询,并做聚合及复杂处理(不止是sum、avg、max这种),目前来看分布式数据库是elasticsearch跟redis这两种都不太适合使用。

回复1:luxh08 科技部门副总 , 某互联网银行
elasticsearch是做非关系数据的搜索引擎场景使用的,比如日志查询场景,redis是主要是做零时文件查询cache使用,大数据查询场景,特别是做join,sum等操作,建议使用hive架构、hatp架构还有就是后起之秀ClickHouse数据库在不少大的互联网公司作为实时大数据分析使用,性能非常强,大数据的聚合查询,大数量的复查查询类场景,我理解性能提升关键有下面几点,一是列式存储是提高性能的关键点,二是还有就是分布式节点架构,所有节点都能参与进来,三是节点本身能过滤计算数据集合,减少数据在网络上的传输量,四是可以使用底层的存储级索引,可以在物理存储过滤掉一些成本。

回复2:顾黄亮 技术总监 , 苏宁消费金融有限公司
提供一个思路,返回数据集很大一般在几个场景中遇到,1、jdbc对数据库进行读取不够合理;2、数据分析场景下需要对千万级数据进行快速计算和响应;3、调用存储过程返回庞大的结果集。
在这种情况下,有一些是通过数据库解决,还有一些通过应用的优化进行解决,比如分页或减少结果集传输次数,如果从数据库层面进行选型,很多分布式数据库都适合,关键看是否匹配场景,匹配能力是否覆盖,1、是否具备多维度关联预先计算出结果的能力;2、是否具备高并发场景的能力,其中涉及锁的机制;3、是否具备应对维度过大和枚举值多的能力。

回复3:wanglaye 项目经理 , 某大型金融机构
提供一个思路。influxDB配合kafka和程序, 复杂处理建议放在程序里做,让数据库专注处理时序数据。

8、分布式数据库是否有较完善的备份恢复解决方案?

分布式数据库是否有较完善的备份恢复解决方案

回复1:
分布式数据库基本都具备备份和恢复方案,通常从备节点进行连续备份(全量+日志),恢复的时候制定节点进行恢复到指定时间点,整个过程可配置自动任务自动执行。

回复2:luxh08 科技部门副总 , 某互联网银行
分布式数据库一致性保证通过内部时钟机制,所有节点都会遵循一致的时钟,所以备份恢复的增量也是基于时钟,相当于单机数据,但是分布式数据库的备份解决方案最重要标志是否支持物理级的备份,物理级的备份会比逻辑的备份性能吞吐会大很多,还有就是是否支持一些分布式备份方案,比如S3协议接口,是否支持压缩等功能。

9、对于同城双活数据中心与异地灾备数据中心,如何设计分布式数据库部署方案?

对于同城双活数据中心与异地灾备数据中心,如何设计分布式数据库部署方案

回复1:
建议实例的主备节点设置在同城两个双活数据中心,仲裁节点三机房部署;异地灾备单独启实例与本地实例进行数据库间同步,也可以讲本地备份文件T+1恢复到异地灾备。

回复2:luxh08 科技部门副总 , 某互联网银行
分布式数据库大多都是基于多数派协议,同城双中心不适合多数派的要求,同城数据级多活建议采用三中心部署,如果同城主备可以采用集群级的异步复制。异地建议采用集群级的binlog异步复制。

10、分布式数据库对于复杂数据库事务的性能问题?

对于复杂数据库事务,分布式数据库可能出现需要多个数据库节点同时处理的情况,是否会因为各数据库节点之间多次数据同步或者交互,造成事务处理时间较长

回复1:
对于含有需要节点间数据流动的SQL语句的事务,OLTP类的分布式数据库处理效率一般较差,事务处理时间会较长,事务期间的锁持有时间也会增加,数据库的并发性和扩展性也会很差。建议尽量改造存在跨节点数据流动的SQL语句(主要是多表关联)的事务。

回复2:luxh08 科技部门副总 , 某互联网银行
对,由于二阶段提交和各节点之间的网络交互会有性能影响,分布式数据库优势不是单个简单sql的性能,但是大数据量的sql查询,每个节点会将过滤之后的数据集进行反馈,会提升性能,并且分布式数据库的优势是并发,大量的sql并发也会比单机数据库强大,应用需要做分布式架构的适配,将串行执行机制尽量都改造成并发处理。

11、在分布式数据库项目中,为进行系统规格设计,如何进行定量需求分析?需要收集哪些需求数据信息?

在分布式数据库项目中,为进行系统规格设计,如何进行定量需求分析?需要收集哪些需求数据信息?

回复1:顾黄亮 技术总监 , 苏宁消费金融有限公司
一般情况下, 在分布式数据库项目中,为进行系统规格设计需要考虑下列方面的准备。
1、如何进行服务器选型:一般分布式数据库都会采用廉价x86 pc服务器,搭配本地ssd固态盘、万兆网卡,硬件成本较低。
2、软件规划和部署方案:分布式数据库组件众多,而且每个组件都有高可用备份,所以在有限数量的服务器下进行组件的分配要尽量考虑达到各个服务器负载的均衡,gtm作为分布式数据库的瓶颈尽量和他们组件分开部署。
3、监控方案: 监控一般可以采用开源的zabbix进行定制化开发,当然也可以基grafana+prometheus的方案做监控。
4、如何进行调优:因为不同厂商研发的数据库sql优化器及执行计划都有所不同,所以要根据不同产品进行学习。
5、备份方案:分布式数据库如何做一致性备份也是研发难点,要做到真正意义上的pitr就需要做到分布式环境下每个全局事务的“barrier”操作。
6、应急方案:因为分布式数据库还处于发展阶段,还不成熟,技术比较复杂,所以生产环境下要制定详细的应急方案,让不了解分布式数据库的同事也能够在出现问题时按照手册操作。

此外还需要一些数据的收集,如下:
1、系统的最大并发数:为了节省成本,多套小系统可以共用一套数据库,但是负载很大的高并发场景还是独立搭建。
2、系统的最大数据量:多租户系统下需要考虑各个系统的数据量之和。
3、系统最大可容忍的业务中断时间: 分布式数据库节点宕机并不是对业务没有任何影响,主节点宕机都涉及到一个切换的问题,切换就是影响业务的时间,要充分评估业务能否忍受这么长时间的中断。
4、系统的迁移成本:分布式数据库不可能做到oracle、db2、mysql所有数据库的百分之百兼容,所以不同类型的数据库在迁移上都会或多或少的涉及到应用的改造。

回复2:wanglaye 项目经理 , 某大型金融机构
题主说的“系统规格设计”,具体包括哪些内容可以详细描述一下。
我从分布式数据库规模角度分享一下经验。
业务系统层面,要调研系统数量、各系统业务量(包括总交易量、各种交易TPS等)、每种交易对数据库的sql条数(尤其关注读写频率,查询也要统计),从而大致计算出QPS。
分布式数据库层面,重点关注性能测试数据、服务器配置参数,一般主流3副本,对应3台服务器,以此作为组合,关注可以支持多少QPS,从而计算出服务器数量需求。需要注意的是,分布式数据库厂商提供的性能测试采用的服务器参数,一般是高配服务器,如果实际生产使用服务器配置降低,则要考虑性能数据损耗。

回复3:luxh08 科技部门副总 , 某互联网银行
不是所有系统都适合分布式架构,技术为业务服务,主要考虑成本和收益的平衡,分布式数据库的使用场景,应该是海量数据、海量用户、海量交易数,单机数据库可以处理的场景不建议采用分布式数据库,分布式数据库的使用会有成本的,比如应用适配成本、运维成本、硬件成本,能用单机数据库支撑的业务场景就尽量用单机库,但是还要考虑业务的发展,最好是能判断3年的数据量和交易量。

12、相较于银行核心系统传统架构,分布式架构的系统运维有哪些不同点?

回复:luxh08 科技部门副总 , 某互联网银行
这个分布式架构我理解是数据库分布式架构,目前大部分核心场景上线分布式数据库都是采用分库分表架构,在运维过程中要关注以下几个方面,一是DDL类操作对数据库可用性的影响,二是后期节点扩容的复杂性,三是夸节点负责聚合类查询对性能的影响,四是多节点备份恢复的一致性,总结就是需要解决多节点全局一致性带来的复杂性挑战。

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

6

添加新评论1 条评论

YellowbrickDataYellowbrickData市场发展总监, YellowbrickData
2021-09-20 12:13
去IOE 是为了业务增长的发展,效率的提升,成本的降低。 但是系统整合能力有限,以及硬件本身的性能阻碍了项目的落地。 甚至往往投入了巨大的成本发现效率更低。
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广