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

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

3回答

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

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

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

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

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

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

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

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

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

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

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

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

收起
 2019-11-28
浏览572

提问者

我爱大锅饭系统运维工程师, 银行

问题状态

  • 发布时间:2019-11-26
  • 关注会员:4 人
  • 问题浏览:4755
  • 最近回答:2019-11-28
  • 关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
    © 2020  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30