银行业核心系统分布式数据库改造问题求解?

正如此前社区里其他老师所说:”目前金融行业绝大多数核心系统的数据库依旧采用传统的集中式架构(高端小型机+集中式关系型数据库+集中式SAN存储)为主的实现方式。”随着互联网金融产品种类的爆发式增长,银行业为了突破传统盈利模式,增强客户黏性,纷纷推出了互联网类的产品、营销活动,如工行、建行自营商城的名酒定时促销。这些产品和活动给传统的集中式关系型数据库带来极大挑战,硬件扩容、分库分表的传统应对手段效果不尽人意,无法适应营销期间海量数据存取及高并发请求响应的场景。为此,各大银行纷纷开始了核心系统分布式数据库改造的前期探索,部分银行已宣称完成核心系统分布式数据库的切换上线(张家港农商行,中信信用卡核心),但是整体效果和改造、使用过程中的问题未见详细描述且有待时间验证。
因此,想请教各位IT同仁,中型商业银行在准备核心分布式数据库选型时,除了必须要考虑的强一致性、高可用性的原则,还应考虑哪些问题?在CAP定律的限制下如何取得最优解?整个改造大致需要历经几个阶段?望各位同仁指点,非常感谢!

参与18

5同行回答

匿名用户匿名用户
以下纯属个人观点:1)中型商业银行在准备核心分布式数据库选型时,除了必须要考虑的强一致性、高可用性的原则,还应考虑哪些问题?业务系统改造成本:需要考虑sql兼容性(mysql or oracle),事务采用悲观锁模型还是乐观锁模型,数据分片是否对业务透明等产品可靠性和自主可控能力:产品是否...显示全部

以下纯属个人观点:
1)中型商业银行在准备核心分布式数据库选型时,除了必须要考虑的强一致性、高可用性的原则,还应考虑哪些问题?
业务系统改造成本:需要考虑sql兼容性(mysql or oracle),事务采用悲观锁模型还是乐观锁模型,数据分片是否对业务透明等

产品可靠性和自主可控能力:产品是否真正在金融交易场景尤其是账务系统经过长期验证,核心功能是否基于开源开发还是从零写起

高可用及容灾解决方案:方案是否满足公司实际硬件设施条件

2)在CAP定律的限制下如何取得最优解?
CAP定律适用于多副本之间,实际上现在的分布式数据库多副本更多使用的BASE定律,实现的都还不错

3)整个改造大致需要历经几个阶段?
改造过程还是老套路:先外围系统后核心系统,可以先作为从库,后逐渐切流量上去,最后的形态应该是和专有云融合,提升运维管理效率

收起
证券 · 2019-11-26
浏览3454
wanglayewanglaye  信息技术经理 , 某大型金融机构
Q: 除了必须要考虑的强一致性、高可用性的原则,还应考虑哪些问题?市面上主流的分布式数据库,如OceanBase、Tdsql、TiDB、华为的高斯数据库,或者基于mysql+mycat改造的中间件型数据库,从特性上来说都可算作分布式数据库的选型范围,区别在于自主研发和自主可控能力,有的企业比较看...显示全部

Q: 除了必须要考虑的强一致性、高可用性的原则,还应考虑哪些问题?
市面上主流的分布式数据库,如OceanBase、Tdsql、TiDB、华为的高斯数据库,或者基于mysql+mycat改造的中间件型数据库,从特性上来说都可算作分布式数据库的选型范围,区别在于自主研发和自主可控能力,有的企业比较看重自主可控。
此外,还需考虑迁移改造成本。在选型时一定要考虑原数据库迁移至分布式数据库的改造成本,包括sql语句、数据迁移等方面的改造难度和改造工作量,也包括与分布式数据库匹配的硬件投入(某些分布式数据库对于硬件的要求比较高,硬件会影响数据库性能。)
以上是本人从可行性角度给出的建议。至于 强一致性、高可用性等特性,大部分分布式数据库都是具备的。
Q:在CAP定律的限制下如何取得最优解?
CAP定律的P是必然存在的,不同分布式数据库厂商对于C和A的权重比例不同,没有理论上的最优解,只有基于特定业务才能制定出更加适合该业务的解。
Q:整个改造大致需要历经几个阶段?
首先,要进行数据库的迁移改造测试,评估工作量和工作难度;然后,选择外围小型事务型系统做试点迁移,分布式数据库和原数据库做好数据同步,分布式数据库作为从,逐渐过渡至主;最后,制定规范再推广。

收起
银行 · 2019-11-27
浏览3226
  • 分布式数据库场景中,p一定存在这个也不是肯定的。
    以oceanbase举例,纵向三分片的典型配置,在读写不分离(默认)的时候,读和写都是通过主节点来进行的,2个从节点只是看做是备份节点,此时我认为是没有p的。

    我们goldendb也是类似的实现原理。

    2020-03-15
  • 节点故障或者网络分区故障是无法避免的,不管是最简单的单机房3副本配置,还是两地三中心多机房多副本配置,必然要面对节点故障或机房故障的情况,分布式数据库如果不支持p,怎么承担这种常见故障场景呢?如果是经典的三副本配置,当一个从节点故障后,为了继续对外提供服务保障a,只能牺牲c了。
    2020-03-23
GoldenDBGoldenDB  产品经理 , 中兴通讯
感谢楼主对我司数据库的关注(中信)实际上我们在中信已经实施了靠50只业务,除了信用卡核心8000万用户,对私渠道(网银,微信银行短信银行等)也有6000万用户,此外,总行核心也已经并网一年多,预计今年上半年正式上线,对于银行的考量以及迁移过程,我们都有自己的理解和总结,希望有机会能...显示全部

感谢楼主对我司数据库的关注(中信)
实际上我们在中信已经实施了靠50只业务,
除了信用卡核心8000万用户,对私渠道(网银,微信银行短信银行等)也有6000万用户,
此外,总行核心也已经并网一年多,预计今年上半年正式上线,
对于银行的考量以及迁移过程,我们都有自己的理解和总结,希望有机会能进行交流。

收起
电信设备制造商 · 2020-03-15
浏览2060
AmygoAmygo  DBA , 分布式事务数据库
这些产品和活动给传统的集中式关系型数据库带来极大挑战,硬件扩容、分库分表的传统应对手段效果不尽人意,无法适应营销期间海量数据存取及高并发请求响应的场景。为此,各大银行纷纷开始了核心系统分布式数据库改造的前期探索,部分银行已宣称完成核心系统分布式数据库的切换上...显示全部

这些产品和活动给传统的集中式关系型数据库带来极大挑战,硬件扩容、分库分表的传统应对手段效果不尽人意,无法适应营销期间海量数据存取及高并发请求响应的场景。为此,各大银行纷纷开始了核心系统分布式数据库改造的前期探索,部分银行已宣称完成核心系统分布式数据库的切换上线(张家港农商行,中信信用卡核心),但是整体效果和改造、使用过程中的问题未见详细描述且有待时间验证。
因此,想请教各位IT同仁,中型商业银行在准备核心分布式数据库选型时,除了必须要考虑的强一致性、高可用性的原则,还应考虑哪些问题?在CAP定律的限制下如何取得最优解?整个改造大致需要历经几个阶段?

从上述的描述内容可以提炼出来核心话题

(1)集中式数据库在互联网+业务场景下,遇到海量数据存取及高并发请求响应的场景挑战

(2)分布式事务数据库关注哪些关键点

(3)CAP 定律的限制下如何取得最优解

(4)业务系统从集中式数据库 改造为分布式事务数据库 会遇到那些问题,及经历那几个阶段

详细解答如下:

(1)集中式数据库在互联网+业务场景下,遇到海量数据存取及高并发请求响应的场景挑战

解答:

分布式事务数据库设计初衷就是要解决业务系统的 数据存储容量 和数据服务处理的两个维度能力做到水平弹性伸缩,并且不丢失集中式数据库带给业务系统访问数据库的操作体验。

从吞吐量的角度基本上要求达到: 常规数据(每行 1KB 字节)入库的 TPS 可达 1000000 及以上、数据访问的 QPS 可达 1000000 及以上,并发连接数可达 100000 及以上,集群线性扩容系数 0.8 及以上,集群数据容量可达到 TB 级至 PB 级

(2)分布式事务数据库关注哪些关键点

解答:

关注分布式事务是否实时一致、分布式事务吞吐量及响应时间、分布式事务对应业务系统的透明度、实时死锁检测和死锁接触、跨数据分片JOIN、跨数据分片的排序合并集合计算等、数据分片设计是依靠人力还是智能算法(默认主键或隐含健,也即非业务健)、排错分析运维管理能力。

(3)CAP 定律的限制下如何取得最优解
解答:

分布式事务数据库产品必须支持水平数据分片能力;在金融行业必须追求数据一致、数据完整、数据正确、数据持久化的大原则;最后考虑可用性,也即满足CP的前提下保证A

(4)业务系统从集中式数据库 改造为分布式事务数据库 会遇到那些问题,及经历那几个阶段

解答:

业务系统 从集中式数据库 改造为分布式事务数据库 必须要做项POC测试:挑选经典业务场景做功能测试和性能测试以初步判断是否满足要求、做每个组件的高可用测试和集群灾难测试、做业务系统集成的功能测试和性能测试、做业务系统集成的灾难测试。

业务系统 从集中式数据库 改造为分布式事务数据库 :一定会碰到数据分片设计,也即每张表是按水平分片、垂直分片、全局分片中的哪一种,其次是 每张表数据分片的健选择哪个字段。要是依赖人工收集数据和分析设计,则很难保障业务系统的性能最佳 和 耗费大量人力(小项目估计技术专家 3人天-5人天;中等项目估计技术专家10人天-20人天,中大型项目估计技术专家:30人天-50人天,大型项目估计技术专家 100人天且前后周期长,总体建议:成本转嫁给分布式事务数据库产品厂商免费完成)

从外部了解的信息是目前只有OceanBase和HotDB实现了智能数据分片,自动会根据数据分布、数据访问等信息,结合AI智能算法计算出来数据分片的类型和业务字段是最佳。

收起
银行 · 2020-03-03
浏览2408
airstukyairstuky  项目经理 , 某金融银行
我们上了已快3个月,目前是比较稳定的,没见问题,但年结还没跑过,具体情况还要看结果。分布式数据库我们就接触了两种,Ob和TD,ob接触的版本较早,和最新版本已经有已较多的差别了,目使使用的td,除存储过程和视图,函数等,其它支持的是比较全的。像序列,死锁检测都支持,td的分布式,建表的sha...显示全部

我们上了已快3个月,目前是比较稳定的,没见问题,但年结还没跑过,具体情况还要看结果。分布式数据库我们就接触了两种,Ob和TD,ob接触的版本较早,和最新版本已经有已较多的差别了,目使使用的td,除存储过程和视图,函数等,其它支持的是比较全的。

像序列,死锁检测都支持,td的分布式,建表的shardkey特别关键,表的关联需要包含key键,否则会有非常大的影响,甚至影响整个服务,要特别注意。所以需要有专门的团队,彻底的测试与改造。复杂语句的执行,从最初版本到上线版本,厂商进行的相当多的配合与改造支持,互联网应用与传统核心应用差别还是很大的。所以实施最重要的是应用厂商,数据库厂商,自有团队,都要有专门团队持续跟进,才能完成改造。

性能没有问题,扩展,自动修复能力,跨机房容灾,都可能比oracle要更好管理,更强。

收起
银行 · 2019-11-28
浏览3305
  • 建表的shardkey特别关键,表的关联需要包含key键,否则会有非常大的影响,甚至影响整个服务,要特别注意。所以需要有专门的团队,彻底的测试与改造----需要拥有智能数据分片算法的分布式事务数据库产品才能满足,也即借助智能算法自动生成业务字段作为分片健和智能判断表对象作为什么数据分批那类型,这个热璞数据库的HotDB产品 和 蚂蚁金服的Oceanbase产品能做到
    2020-03-06

提问者

我爱大锅饭
系统运维工程师银行
擅长领域: 服务器存储灾备

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2019-11-26
  • 关注会员:6 人
  • 问题浏览:8926
  • 最近回答:2020-03-15
  • X社区推广