分布式数据库 30 讲
王磊
光大银行首席数据架构师
29144 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 34 讲
结束语 (1讲)
分布式数据库 30 讲
15
15
1.0x
00:00/00:00
登录|注册

28 | 选型案例:银行是怎么选择分布式数据库的?

针对一个新建系统做产品选型时还要考虑哪些因素呢?
云缴费系统使用了自研的分库分表方案,新一代财富管理平台使用了TiDB
使用了双路线策略,同时使用分库分表方案和NewSQL
选择TiDB,面向未来,保持对新技术的感知和掌握
在网联支付系统和网贷系统中应用了TiDB
核心业务系统上线切换到GoldenDB,成为分布式数据库应用最为深入的一家银行
与中兴通讯联合研发了GoldenDB
用于历史库系统的数据存储,逐步实现了复杂SQL语句处理和高并发事务处理能力
采用联合高校研发的方式,研发了分布式数据库CBase
强调整体架构改造,在应用系统层面做了更多的工作
完成了向分布式架构的升级
选择PostgreSQL,减少对数据库的性能和稳定性要求
选择单元化架构,拆分商业数据库成多个小的单体数据库
选择保守的方案,规避风险,逐步脱离对IBM主机和Oracle数据库的依赖
选择分库分表方案转型,选择MySQL和DBLE
评估技术潮流对选型影响
产品选型中的非技术因素
当产品选型可能导致业务流程变更时,请慎重对待
先进的产品可能会延长项目交付时间
产品选型要服从于项目整体目标
思考题
光大银行
北京银行
中信银行
交通银行
民生银行
邮储银行
工商银行
选型建议
分布式数据库选型案例总结

该思维导图由 AI 生成,仅供参考

你好,我是王磊,你也可以叫我 Ivan。
在前面的课程中,我们已经介绍了分布式数据库方方面面的知识。这些知识,我觉得大概会在三个方面帮到你,分别是数据库研发、架构思维提升和产品选型。今天,我会通过几家银行的案例带你了解如何做分布式数据库的选型。
为什么要讲银行的分布式数据库选型呢?
你肯定在想,这是因为王磊老师刚好是在银行工作,更熟悉这个行业。这么说也对,银行业确实是我最熟悉的行业。但是更重要的原因是,数据库作为一款基础软件,稳定性和可靠性就是它的立身之本。而对稳定性要求最严苛的行业,就是金融业,尤其是银行业。所以,只有经过金融场景的考验,一款数据库产品才能真正扬名立万,让其他行业的用户放心使用。
也是因为这个原因,不少厂商都打出了“金融级分布式数据库”的旗号。
分布式数据库的应用场景主要特征是海量并发,所以理论上说,业务规模越大,使用分布式数据库的需求也就越迫切。无论从用户数量还是资产规模,国内最大的银行肯定是工商银行。

工商银行(分布式中间件)

工行之前的数据库主要是 Oracle 和 IBM 的 DB2,这很代表性,过去的 20 年银行业基本上就是在这两种产品中二选一。
Oracle 和 DB2 都是单体数据库,只能采用垂直扩展方式,在碰到技术天花板后就会限制业务的发展。作为业务量最大的“宇宙行”,工行面对这个问题的选择是,从单体数据库向以 MySQL 为基础的分库分表方案转型。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

银行在选择分布式数据库时,需考虑稳定性和可靠性。不同银行采取了不同策略,如工商银行选择了以MySQL为基础的分库分表方案转型,而邮储银行采用了单元化架构,将商业数据库拆分成小的单体数据库。民生银行和交通银行更加强调整体架构改造,在应用系统层面做了更多的工作。交通银行更是采用联合高校研发的方式,与华东师范大学和西北工业大学共同研发了分布式数据库CBase。这些案例展示了银行在选择分布式数据库时的不同路径和策略。 中信银行使用分布式数据库的目标是完成AS400小机下移,将应用程序翻写到开放平台,而北京银行等城市商业银行选择分布式数据库主要出于国产化的诉求、实际收益和技术潮流的影响。光大银行则采用了双路线策略,同时使用NewSQL和分库分表方案,根据业务需求选择不同的方案。 总结建议包括:产品选型要服从于项目整体目标,先进的产品可能会延长项目交付时间,当产品选型可能导致业务流程变更时,请慎重对待,正视非技术因素,评估其合理性,以及评估技术潮流对选型的影响。 这些银行的不同选择和实践为读者提供了丰富的选型案例和技术特点,帮助他们更好地了解分布式数据库的应用和选择策略。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《分布式数据库 30 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(8)

  • 最新
  • 精选
  • 郑泽洲
    在4大银行之一干了十多年开发,又跳到互联网干了5年。提供一下内部的视角和比较的视角:银行对分布式架构升级的路线是保守的。原因之一可能是时间节点刚好不对,分布式数据当时还不成熟;原因之二可能和银行开发人员结构有关,在银行从来没遇到基础技术驱动的项目,都是应用为王,开发团队是盯劳某块业务,基础技术储备不足。所以工行邮储等选择了应用层变动比较大的方案,而没有投入技术力量研发NewSQL。所以,业务不同,技术团队不同,造成了银行和互联网企业选型的不同。 是个遗憾,在分布式数据库成熟并成为技术潮流的今天,银行团队本身也在变化,大概率要二次改造

    作者回复: 说的很中肯

    2022-01-25
    6
  • 扩散性百万咸面包
    此外,利用分布式数据库的多租户特性,转变成类似 Aurora 使用方式,还能降低数据库实例管理的复杂度。 还有这句话,多租户特性是什么意思呢?它是怎么降低数据库实例管理的复杂度的,老师可以再细说一下吗?

    作者回复: 就是在一个集群上支持多个业务系统,每个业务系统作为一个租户,这样集群管理工作会简化。

    2020-10-15
    2
    2
  • 扩散性百万咸面包
    这也意味着,它对分布式事务这样的复杂操作没有那么强烈的诉求。最后,用分库方案就很好地解决了海量业务的问题。 这句话不是很明白,意思是说,分库分表方案在事务模型比较简单的情况下,比Newsql更有竞争力吗?从技术角度为什么是这样呢?

    作者回复: 如果没有分布式事务,也没有跨分片查询,那确实用分库分表要更简单些。

    2020-10-15
    1
  • tt
    作为银行IT从业者,对技术和业务的关系那是深有体会啊。 很多实际项目中,其实最本质上都体现了数据一致性乃至事物甚至分布式事物的需求,最日常的对账处理,内部账户的使用,都提现了性能和数据一致性的取舍。这又带来数据分析和监管满足的一系列问题。 尤其是涉及到大的三方商户、客户,又是复杂的业务流程时,业务的最本质还是数据一致性的维护,还是会回归到分布式事物或者长事物上来,没有成熟的底层中间件支持,在讨论方案时总是深入甚至陷入到异常处理的细节大海中,这个循环一再重复。
    2020-10-14
    2
    7
  • 佳佳的爸
    一个系统做产品选型,我觉得需要考虑以下几方面: 1) 开发工具选型:都知道用C和C++ 更适合做内核级和系统级的程序,但是你也得考虑人员成本,可能 挂的招聘岗位一年了都招不到一两个适合的C和C++的程序员; 2)开发框架选型:不是每个公司都能像阿里那样有这么多资金和耐心支持一个完全自研的产品,绝大多数公司研发新产品最主要的目的就是尽快推出产品,抢占市场,或者说从竞争很激烈的市场分得一块蛋糕; 3) 运维的便利度: 随着Ansible自动化运维工具和各种开源的监控工具的流行,运维的复杂度确实比以前降低了很多,因此容器化安装部署已经是一个趋势了,谁家的产品安装部署最方面,运维最便利快捷,就能在市场竞争中赢得先机。
    2021-06-09
    4
  • wy
    公司层面: 系统的目标是什么 产品成本 产品层面:稳定性 性能 运维难度 技术栈 其它: 生态 案例
    2021-01-31
    1
  • Jxin
    1.语言,方便深入和二开 2.成熟度,降低故障风险 3.是否主流,降低招聘成本 4.成本,权衡收益很重要
    2020-11-03
    1
  • OM
    的确如作者所说
    2023-04-27归属地:浙江
收起评论
显示
设置
留言
8
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部