银行互联网金融业务系统,MySQL能否替代Oracle,或是其他数据库替代Oracle的方案?

求助金融行业MySQL替代Oracle的方案或者其它替代Oracle的方案
数据量大,达到单表数十亿记录级别
性能要求高,7x24小时服务
安全要求高,互联网业务
求推荐业界成本低的成熟的方案
同时上层应用架构不需要发生大的调整,运维方便
请业内大神不吝赐教

参与53

11同行回答

匿名用户匿名用户
如果要成本低,业务不用做大的调整的话,几个条件都满足的话,没有方案,就像软件工程学里,没有银弹一样。如果想使用MySQL替换,是需要对业务做调整的,因为Oracle和MySQL的用法都不一样。oracle基本上能用数据库做的,就不要用程序去做; MySQL刚好相反,能用程序做的,就不用数据库做。所以...显示全部

如果要成本低,业务不用做大的调整的话,几个条件都满足的话,没有方案,就像软件工程学里,没有银弹一样。

如果想使用MySQL替换,是需要对业务做调整的,因为Oracle和MySQL的用法都不一样。oracle基本上能用数据库做的,就不要用程序去做; MySQL刚好相反,能用程序做的,就不用数据库做。所以面临调整是思想的调整,更不必说要调整业务了。

数据量大和性能方面,需要基于业务逻辑做表的拆分。
安全是另外一个维度的问题。

收起
互联网服务 · 2019-07-08
浏览8530
墨者阳墨者阳  数据库管理员 , DBA
去 o到 M核心的需求需要明确;2.应用服务对应数据库层一定要合理过渡,禁忌‘牵一发而动全身 ’;3.高效的发挥出m的性能特点,同时满足o的日常场景;4.去不去o不是‘冲动’,一定合乎‘规则’; 5.具体问题具体分析...显示全部
    1. 去 o到 M核心的需求需要明确;

    2.应用服务对应数据库层一定要合理过渡,禁忌‘牵一发而动全身 ’;

    3.高效的发挥出m的性能特点,同时满足o的日常场景;

    4.去不去o不是‘冲动’,一定合乎‘规则’;

    5.具体问题具体分析

收起
互联网服务 · 2019-07-08
浏览8380
kyl123kyl123  系统运维工程师 , 保密
您这表数十亿级别,使用MySQL或者Oracle都一样,都必须进行分区,分片等方法,目前业内比较成熟的做法有:1、通过MySQL+mycat的方案,该方案完全开源免费,缺点是自己的MySQL运维能力要比较牛;2、通过购买商业的分布式数据库,比如action,hotdb,tdsql,OceanBase等分布式,解决您的需求绰绰有余...显示全部

您这表数十亿级别,使用MySQL或者Oracle都一样,都必须进行分区,分片等方法,目前业内比较成熟的做法有:
1、通过MySQL+mycat的方案,该方案完全开源免费,缺点是自己的MySQL运维能力要比较牛;
2、通过购买商业的分布式数据库,比如action,hotdb,tdsql,OceanBase等分布式,解决您的需求绰绰有余。

收起
证券 · 2019-08-09
浏览7667
renou2012renou2012  数据库管理员 , KE
除非自上而下否则不予轻言去什么。银行互联网金融业务不仅仅是说底层使用哪个数据库就是一劳永逸的。要针对特定的场景,举个例子,关于你说的 “数据量大,达到单表数十亿记录级别” 片面的说 无论哪个数据库都吃不消,聚合查询运算加加上dml、ddl等,这个是属于OLAP层面的,正常的...显示全部

除非自上而下否则不予轻言去什么。
银行互联网金融业务不仅仅是说底层使用哪个数据库就是一劳永逸的。要针对特定的场景,举个例子,关于你说的 “数据量大,达到单表数十亿记录级别” 片面的说 无论哪个数据库都吃不消,聚合查询运算加加上dml、ddl等,这个是属于OLAP层面的,正常的日活数据,远远达不到,还有的你说的性能要求高,总体而言,缓存,分布式可以解决百分之七八十,7*24的业务始终是有业务的低谷期,你需要的是评估你的峰值。
所以笼统的寻找替代方案,不如深入研究你的业务。

收起
金融其它 · 2019-08-09
匿名用户匿名用户  其它 , 某银行
MYSQL能否替代Oracle?:能银行互联网金融业务系统,MySQL能否替代Oracle?:技术上能,但真正的关键在于领导的开放态度上层应用架构不需要发生大的调整,MySQL能否替代Oracle?:如果是已有的应用,将面临程序的大量改造工作,这部分工作想开展起来不易;如果是新上应用,倒 是完全可以根据MYSQL...显示全部

MYSQL能否替代Oracle?
:能
银行互联网金融业务系统,MySQL能否替代Oracle?
:技术上能,但真正的关键在于领导的开放态度
上层应用架构不需要发生大的调整,MySQL能否替代Oracle?
:如果是已有的应用,将面临程序的大量改造工作,这部分工作想开展起来不易;如果是新上应用,倒 是完全可以根据MYSQL数据库来做。
成本低?
:即使使用主流开源分布式MYSQL+MYCAT,成本也不低,免费的东西不一定便宜。如果是使用国产分布式数据库,那么开销也不会小。

还是要评估近一两年的业务压力,如果到了必须使用分布式提升性能的阶段,那么用么还是得用

收起
银行 · 2019-08-08
匿名用户匿名用户
说说银行业实践1)mysql 到底可不可以用?可以!工行等银行都有大量mysql 使用经验,不论从生态圈、同业案例、技术支持、产品成熟度等各角度考虑,答案都是肯定的2)试图同一款数据库解决所有问题?不可能!应用系统不一样,数据特点不一样,不可能一个万能的数据库3)可不可以不改造就使用?不...显示全部

说说银行业实践
1)mysql 到底可不可以用?可以!工行等银行都有大量mysql 使用经验,不论从生态圈、同业案例、技术支持、产品成熟度等各角度考虑,答案都是肯定的
2)试图同一款数据库解决所有问题?不可能!应用系统不一样,数据特点不一样,不可能一个万能的数据库
3)可不可以不改造就使用?不太可能。一方面 mysql 的数据处理能力在数据达到一定量后会产生下降,这个经验值有的银行事 500G,有的银行事 1000G,另一方面,题目的需求是说性能要求高,数据量大,这样只能通过分库分表去使用,应用层必然要进行改造。不论什么数据库迁移,肯定有一些改造工作量,而想要用好数据库,肯定需要数据层配合。

收起
银行 · 2019-07-18
baochengchenbaochengchen  系统工程师 , 华际
看你应用情况吧, 不过在金融行业来说, 数据基本上都是oracle db2 吧; 除非数据量很小,或者应用很分布式规划; 可以考虑mysql; 不过不要幻想奥拓达到奥迪的效果就行了。显示全部

看你应用情况吧, 不过在金融行业来说, 数据基本上都是oracle db2 吧; 除非数据量很小,或者应用很分布式规划; 可以考虑mysql; 不过不要幻想奥拓达到奥迪的效果就行了。

收起
系统集成 · 2019-07-15
AcdanteAcdante  技术总监 , SHFY
去O和不去O,不是拍脑袋决定的,是需要根据业务和实际应用场景做分析,Oracle就像一个全能管家,MySQL就像一个需要帮助的大小孩,是极其需要依赖其他组件和外部工具协同的。架构和应用层面的需求才是出发点。还需要有相对应的技术支撑和运维能力去匹配和支持。当然,现在开源的很多i...显示全部

去O和不去O,不是拍脑袋决定的,是需要根据业务和实际应用场景做分析,Oracle就像一个全能管家,MySQL就像一个需要帮助的大小孩,是极其需要依赖其他组件和外部工具协同的。架构和应用层面的需求才是出发点。还需要有相对应的技术支撑和运维能力去匹配和支持。
当然,现在开源的很多i架构也能够满足高并发和大数据量的业务需求,比如MySQL+grode+voltdb的架构,把MySQL彻底释放。只作为存储功能,也能够达到上百万的QPS。

收起
互联网服务 · 2019-07-10
sonicacdsonicacd  高级运营经理 , 某互联网公司
核心系统都有替代的,直接转一个新闻稿,技术细节很丰富了2019 年 9 月 12 日,腾讯云官方宣布了金融级分布式数据库 TDSQL 在张家港农村商业银行正式落地,成为国内首个被银行在传统核心业务场景中使用的国产数据库。随后,冯大辉在留言区评论称:“这是个标志性事件了。”2019 年 9...显示全部

核心系统都有替代的,直接转一个新闻稿,技术细节很丰富了


2019 年 9 月 12 日,腾讯云官方宣布了金融级分布式数据库 TDSQL 在张家港农村商业银行正式落地,成为国内首个被银行在传统核心业务场景中使用的国产数据库。随后,冯大辉在留言区评论称:“这是个标志性事件了。”

2019 年 9 月 12 日,腾讯云官方公布了国产分布式数据库 TDSQL 的一个新案例——张家港农商行。据了解,张家港行新一代核心系统采用了腾讯云 TDSQL 来承载核心业务数据,这是银行传统核心数据库首次实现国产化。

张家港行为什么要迁移核心系统?又是如何选定了国产数据库 TDSQL 的解决方案?整个迁移过程是如何做的? 迁移完成之后,效果如何?张家港行案例对其它银行核心系统改造有哪些借鉴意义?...... 为了搞清楚以上问题,我们独家专访了参与张家港行国产数据库迁移全过程的腾讯云 TDSQL 首席架构师——张文。

1 业务特点:一套核心系统支撑多种业务

行业内通常认为银行的业务分为两部分,传统业务和互联网业务。其中,传统业务指的是和实际卡相关的业务,而互联网业务指的是与实际卡无关的业务,例如电子账户、无卡支付等业务。通常来说,针对这两种业务银行会有两套不同的核心系统,分别为互联网核心和传统核心。互联网核心大多为近几年的新系统,没有太多历史包袱,所以针对于互联网核心的数据库改造相对传统核心无论风险还是难度都小得多,并且在行业内已有成功案例。但是张家港行比较特殊,没有区分互联网核心和传统核心,而是出于业务复杂度和用户规模等等的考虑,把互联网核心放到了传统核心里面。

张文用一句话总结了张家港行的业务特点,那就是一套核心系统支撑了全行的传统业务和互联网业务。

张家港行的系统非常多,我们可以简单的划分为两大部分,核心系统和外围系统。如果把核心系统比作心脏,那么外围系统就是四肢,所有与钱相关的操作都要经过核心系统。核心系统的业务逻辑是最为关键的,因为它与银行核心资产数据是直接相关的,而外围更像是一个渠道,最后都要去核心系统中进行核算和清算,比较典型的外围系统:手机银行、贷款、网银、ATM 等等。

2 迁移过程:集中式、分布式两套系统并行

据了解,本次迁移的核心系统的数据量在 TB 级,包括了账户、账目、流水、账单、日志等数据。张家港行系统建设方长亮科技表示其核心系统主要分为两大部分,一个为交易子系统,总共有 70 多个结构,覆盖银行卡、资金管理等等;另一个为会计子系统,主要是资金的交易分离、清算总账。

综上所述,核心系统不仅本身系统结构复杂,且还与各个系统都有联系,因此它的数据库迁移是最复杂、难度最大的。

张家港行对于数据库的要求

在迁移之前,张家港行使用的是 Sybase 数据库,从业务系统到数据库的整体架构大概还是十多年前的架构,不可避免地会遇到性能瓶颈问题,尤其是在高峰时段,数据库的吞吐量低,机器负载高,业务响应缓慢,已无法满足当前的用户请求量。在张文看来,性能问题是当时张家港行当时的最大痛点。

在选择数据库时,张家港行有哪些关注点呢?

  • 数据一致性以及分布式事务可靠性。银行数据关系着金钱,任何一条错误数据造成的损失都无法估量;
  • 性能。高峰期能否扛得住业务压力,各项业务响应时耗能否满足要求,跑批类业务能否在规定时间内完成;
  • 高可用。出现故障多久可以切换,切换过程能否保证数据不丢不错;
  • 稳定性。TDSQL 首先基于 MySQL 生态进行研发,MySQL 作为全世界最流行的数据库之一,在全世界范围内有无数使用者,同时其背后有无数社区的开源爱好者作为强大的技术后盾;其二,TDSQL 在腾讯内部经过数十年的持续研发和验证,支撑内部海量支付交易场景,踩了足够多的坑,积累了大量的实践经验,所以稳定性有保障。
  • 业务改造量。从集中式迁移到分布式,这其中的改造量必须可控,如果工作量太大超过预期时间,那么就必须考虑其它方案了;

以上是一些比较重要的关注点,除此之外,还有一些其它考虑事项,例如运营成本、员工培训、上手难易程度等等。

迁移方案:分布式与集中式并存

2018 年年初,腾讯云首次接触到了张家港行,当时张家港行的一个缴存水电费的外围系统想要尝试国产分布式数据库,经过若干轮 POC 测试最终选择了 TDSQL。2018 年 8 月左右,张家港行准备对核心系统进行改造,原计划数据库采用国外某商用数据库,但是张家港行科技部考虑到目前已有一个外围系统使用了国产分布式数据库,并且运行期间非常稳定,那么这次核心改造是否也可以考虑分布式数据库?

据张文介绍,“当时张家港行有两个选择,一是集中式数据库,二是分布式数据库。大部分银行在做核心系统升级时都会选择国外集中式的商业数据库,虽然技术掌握在别人手中,但它是国内无数银行普遍使用的数据库,并且国内银行核心系统也没有使用国产分布式数据库的先例。”

在改造时,张家港行做了一个大胆的决定:同时开发两套新核心业务系统,一套基于国外某商用数据库而另外一套则基于 TDSQL,然后进行“内部赛马”,一年之后对两个系统的稳定性、性能进行对比测试,根据测试结果再决定使用哪套。张文表示:“经过整整一年的改造,无论是从性能成本,还是易用性,分布式数据库都表现出明显优势,进而最终新核心系统采用了 TDSQL 分布式数据库,而之前采用集中式数据库的核心系统则保留为灾备系统。”

核心系统迁移遇到的挑战

相信很多人都很好奇张家港行核心系统的整个迁移过程,在采访中,张文讲到:“整个实施过程分为两个阶段,第一个阶段是功能性改造,第二个阶段是性能优化。整个改造过程是从简单到复杂,我们是先从高频交易入手,集中处理与高频交易相关的业务以及子系统,然后是跑批类交易,跑批与高频交易相比,SQL 相对复杂冗余但是占总交易类的比重较低。解决了高频交易其实就已经解决了 99% 的问题,这个过程积累了丰富的调优经验,这些经验再应用到其它业务系统中可以更方便迅速地解决问题。”

当然,从集中式数据库转变到分布式数据库由于数据组织方式的差异,不可避免地带来一系列问题,例如语法差异、性能差异、兼容性问题等。

  • 从集中式架构转变到分布式架构,要求所有的库表都要重新设计,这是所有数据库做分布式改造时都无法避免的问题。之所以需要重新设计库表,是因为分布式数据库引入了分片关键字的概念,如何根据全局业务,选择最佳的数据分布策略,是分布式改造需要面对的首要问题。即使确定了分片关键字,还需要对该分片关键字以及索引做持续优化调整以寻求最佳实践;
  • 兼容性差异,包括两部分:Oracle 生态与 MySQL 生态、集中式架构与分布式架构的差异,如何解决这个问题呢?针对 Oracle 支持的语法但 MySQL 不支持这个问题,TDSQL 做了大量对 Oracle 语法兼容性的优化。对于一些不太适合分布式场景下的使用特性如:存储过程、视图、触发器等,业务之所以用到这些特性,是因为将很多业务逻辑也放在了数据库中,这一定程度上导致了扩展性不足,TDSQL 团队与行方、核心系统开发商长亮科技进行了仔细的分析与评估,将更合适放到应用层的部分逻辑上移,实现了更为彻底的分布式架构,极大提升了整体的水平扩展性。
  • 复杂 SQL,在集中式数据库中,由于数据集中存储在一个节点上,SQL 无需考虑跨多个节点关联问题。而在分布式数据库中,数据是打散在多个节点上的,一条复杂 SQL 可能会涉及到多个数据节点,此时会导致数据库性能急剧下降。针对复杂 SQL 问题,业务侧通过调整分片关键字和复杂 SQL 拆分两个方面做优化,让 SQL 尽可能限制在一个数据节点内。当然,必定会有一些 SQL 由于其业务逻辑的特殊性(如:银行跑批类业务),无法避免跨多个数据节点的表关联。针对这种情况,TDSQL 做了大量针对复杂 SQL 的优化,如:子查询上提、左连接消除、丰富下推逻辑以及基于统计信息的条件推导逻辑等,尽可能提高处理这种复杂 sql 的性能。
    迁移完成之后的运行效果

2019 年 8 月 16 日下午 6 点,张家港行挂牌停业,正式开始进行新核心系统的上线工作。首先进行的是数据库割接,在割接期间完成了原有数据的倒出、TDSQL 数据的倒入以及中间数据的加工校验。48 小时之后,也就是 2019 年 8 月 18 日下午 6 点,整个改造工作结束,新核心系统成功跑在了 TDSQL 数据库上,张家港行正式对外开业。从正式上线至今已有一个多月,在这一个多月的时间里,数据库运行稳定各项指标均正常,即使业务高峰期数据库也维持极低负载。

在性能方面,迁移后的核心系统也有了很大的提升,张文列举了一些性能方面的具体数据指标:

  • 高频账户类交易耗时在 300 毫秒之内
  • 查询类交易耗时在 100 毫秒之内
  • 20 秒内可以完成 1 万笔批量代发代扣业务
  • 日终跑批耗时 14 分钟
  • 存款结息耗时 11 分钟
  • 贷款结息耗时 3 分钟

张文表示:“批量业务进行时,数据库负载均保持在 10% 以下,这样的性能完全可以满足张家港行未来五到十年业务发展需求。TDSQL 还能发挥分布式数据库在线横向扩展的优势,如果后续业务发展有需要时,只需加入硬件资源,便能够自动水平扩展化解性能瓶颈。”

在成本方面,张文表示不太方便透露具体的数据,但是他给我们算了一笔账,“张家港行在硬件层面采用传统的 X86 服务器,取代了大型机、小型机。以近期上线核心系统的某商业银行为例,传统的商业数据库都得用大型机、小型机,综合硬件成本大概在 4000 万 -5000 万,系统处理能力大约为 8000 TPS。而张家港行这边的硬件成本不到 1000w,综合降低成本 75% 以上,吞吐量达到了 6200 TPS,并且支持横向扩展。”

3 经验总结:先跑通再优化

张家港行的案例对于其它银行有哪些借鉴意义呢?张文表示:“最重要的一个经验就是先跑通再优化。”具体来说,就是先要跑通兼容性问题,兼容性问题解决后再攻克性能问题,并且从兼容性到性能是一个持续优化的过程,同时也是一个寻找分布式数据库最佳实践的过程。根据 TDSQL 团队的经验,按照从高频交易到批量业务的顺序来解决问题是效率最高的,问题的复杂度会逐步降低。

核心系统与外围系统在重要性、业务逻辑复杂度等方面有很大的差异,因而也决定了其改造难度的不同。从重要性来讲,核心系统是所有系统的心脏,所有和钱有关系的操作都要经过核心核算、清算,因而核心系统出现问题会导致全行业务中断甚至瘫痪;相对来说外围系统一般都只关联一个特定业务,其故障一般不会造成全行业务的瘫痪;从业务逻辑来看,由于外围系统一般只涉及特定的业务对其改造只需考虑对应业务即可,而核心系统是所有系统的中枢,对其改造需要梳理所有和其相关的业务;从兼容性来看,外围系统相对来说新系统居多,没有太多的历史包袱,可以从零开始而不需要考虑太多兼容性问题。而核心系统就没有这么简单,例如张家港行核心从集中式平滑过渡到分布式数据库过程中需要考虑无数兼容性适配问题。

针对银行核心系统的数据库,通常银行的做法是沿用、并存或者替代,目前大部分银行的数据库战略是沿用、并存,而地方性股份制银行可能走得更快一点,在沿用、并存的基础上尝试国产化替代。对此,张文表示:“核心系统是银行业务系统的心脏,而核心系统的数据库就是心脏中的心脏,针对核心系统的数据库进行改造的难度无异于做一次心脏更换手术。在国有自主可控的大背景下,再结合性能、成本考虑,银行试水互联网公司的分布式数据库已经成为一个趋势。全国性股份制银行,相比于地方性股份制银行步子迈得可能稍微慢一些,但是也是为了更稳一些,因为大行相对而言历史包袱更重,迁移工作量和难度更大。当然,我们也看到越来越多的大型银行机构也在积极参与,积极探索核心系统数据库的国产化改造。这是一个循序渐进的过程。”

张家港行核心系统数据库改造案例公开之后,很多行业工作者认为这是个标志性事件。对于标志性,张文是这样理解的:“首先,这个案例证明了在银行核心系统中,长期被国外所垄断商用数据库是可以被替换为国产分布式数据库,并且替换后带来更强劲的性能指标,更低廉的软硬件成本以及更符合中国人操作的用户习惯;其次,对于腾讯云来说,这也是一个具有代表性的案例,未来可能会将该模式复制到其它银行客户中。”

收起
互联网服务 · 2020-03-26
浏览6278
hfbosshfboss  技术总监 , ahzyhl
运维成本是一个很大的考量显示全部

运维成本是一个很大的考量

收起
系统集成 · 2019-08-09
浏览7547

相关问题

相关资料

相关文章

问题状态

  • 发布时间:2019-07-08
  • 关注会员:13 人
  • 问题浏览:18257
  • 最近回答:2020-03-26
  • X社区推广