金融数据库的战场,太平洋保险和OceanBase打了场胜仗

这篇具有很好参考价值的文章主要介绍了金融数据库的战场,太平洋保险和OceanBase打了场胜仗。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

点击关注

金融数据库的战场,太平洋保险和OceanBase打了场胜仗,金融,数据库,oceanbase

文丨刘雨琦 

“数据库的国产替代,必须经过严格的考虑,保证不会出错,所以大多数企业的领导层选择按兵不动或者简单扩容。因为不换就不会错,选了很久如果选错,还可能会出现重大事故。” 

某银行数据库技术人员曾对光锥智能一语道出了在数据库的国产替代中的核心难点。“真的要大刀阔斧的改革,需要领导层有魄力和决心,否则只能是边缘试探。”

下定决心全面替换,一方面是企业对国产数据库有足够的开放程度,另一方面,也要国产数据库有超过Oracle等老牌数据库的性能。一次改革,不仅完成“平替”,更能升级,帮助企业降本增效。

2022年,中国太平洋保险集团(以下简称:太保)面临着一样的十字路口,作为国内头部的综合性保险集团,太保核心业务系统的数据库要比其他的要求更高、更困难,但同时,也更具代表性,一旦拥有成功经验,也将为整个保险行业建立新的行业标准。 太保集团科技管理部总经理马波勇曾公开分享过替换经历:“太保从业务场景出发,通过梳理保险业务的典型场景,选择了两类数据库。既有高并发、大数据量、具备互联网业务特征的场景,又有大量以内部用户为主的业务场景。比如在核心的P17客户服务系统中,我们经过两年多的调研、测试和评估,选择了之前服务过金融行业的蚂蚁集团数据库OceanBase,进行分布式转型。” 

“数据库的国产替代,正在从边缘的OA系统,深入到核心的业务系统。如今国产数据库占20%的市场份额,传统数据库占80%的份额,这样的‘二八’分布将在三年之内颠倒过来。”OceanBase副总裁王爽认为,国产数据库已经经历了磨砺产品性能、攻克替代难关的过程,将在三年内加速进入全面升级的阶段。

据光锥智能了解到,很多企业制定了内部战略,要在2027年做到数据库的“应替尽替”。国内企业逐渐对国产数据库重新认知并抱有开放态度,尤其在数据库最核心的金融场景,也有更多企业愿意“押注”在国产数据库上。 国产数据库,从金融行业里“杀”出了一条路。

金融行业升级的三座大山

 “没有经历过金融行业历练的数据库,不算合格的数据库。” 

一直以来,金融场景都是数据库的最大练兵场,不仅是因为数据量庞大,同时,交易、分析、事故更加复杂,高频高并发是金融数据库的特性,更因为金融行业本身7×24小时不间断,对数据库安全性、稳定性都有更高要求,运维也更加复杂。

王爽举了一个例子:“以前银行的交易来自于营业网点,存钱、取钱、转钱,但现在已经互联网化了,频率大大增加。以前一年去营业厅也就三五次,但现在用户每天都在交易,每天点外卖、坐公交/地铁,每刷一次都会产生数据。这就造成了爆炸性的数据量增长,传统数据库处理起来,成本非常巨大。所以,并不只是为了国产替代,更是为了升级。

此前,企业在选择国产数据库时,第一考虑的是与Oracle的适配和兼容关系,以降低应用和迁移成本。“2020年之前,几乎所有的国产数据库对企业宣传的核心价值就是兼容Oracle和MySQL。”一位数据库厂商对光锥智能讲道。

但在真正落地时发现,兼容是不够的,在适配时必须要取舍。Oracle数据库垄断了近20年,有很多特性逐渐落后,国产数据库的单纯替代没有意义,底层架构发生改变之后,性能要做到更加优化。

更重要的是,银行、保险、券商过去与Oracle进行了深度绑定,包括⾃定义锁、⾃治事务、嵌套表、索引组织表、PLSQL包、物化视图、DBlink、触发器、系统视图,改造难度极⼤,如何提升庞⼤存储过程中的识别效率⾄关重要。

这不只依赖数据库厂商一家来完成,更需要使用方一起深度改造。太保集团与OceanBase打磨的过程中,马波勇总结了升级过程中的三大挑战:

第一是国产数据库的性能,能否满足业务需求。“由于之前大部分系统使用传统数据库做支撑,在制定数据库的选型策略和升级方案方面,系统的兼容性、稳定性,数据迁移的便捷性、完整性是我们考虑的首要问题。第二,要考虑它在金融行业的应用案例是否广泛,是否具备足够的成熟度。第三个是在运维方面,需要具备较强的自主营运能力和支撑能力”,马波勇谈道。

第二是数据库的安全性和弹性伸缩能力。银行保险业数据量大、私密性强、波峰波谷期动荡,本地部署的数据库能保证安全性,但是相应的成本也会更高,且弹性伸缩能力差,无法灵活应变银行互联网化后的高频和多发需求。

第三是平滑迁移的能力。迁移的过程中保证业务不停,同时要高度兼容,节省调试时间。马波勇谈到:“太保集团作为32年的国企,数据量及业务量都很大,如何在有限的时间窗口,完成数据迁移,成为摆在太保集团面前的一大难题。” 

那么,这三座“大山”,太保和OceanBase是如何携手跨过的?

最难的P17系统,OceanBase如何搞定?

OceanBase所升级的太保P17核心系统,同时面临着上述的三座大山。

在太保的业务系统中,有P20的级别之分,P17是集团排名中的高级别,因此,该系统的成功升级具有标杆作用和里程碑意义。“P17客户服务系统”是太平洋保险产、寿、健康、长江等所有子公司客户服务系统的整合,为公司6地8个电话中心超过2000坐席提供系统服务。”太保集团数智研究院首席数据库专家林春介绍道。

“与一般热线系统相比,‘P17客户服务系统’涵盖了太平洋保险几乎所有子公司业务的服务入口功能,包括车险报案、车险增值服务、非车人意报案、道路救援、寿险保单查询、寿险保全受理、投保预约等等,对接周边系统超过200个,是太平洋保险关联关系最为复杂的系统之一。” 

同时,作为太平洋保险的服务品牌,“P17客户服务系统”需要提供7*24⼩时的全天服务,系统可⽤性要求全年99.9%以上,对停机时间有着严苛的控制。因此,也是太平洋保险运维保障最⾼的核⼼系统之⼀。

毫无疑问,对于P17的升级,是最为慎重的决定。2021年初,太保对国产分布式数据库,从功能、性能、易用性、完整性、可移植性、可靠性、扩展性、安全性等指标进行了全方位评估,最终选择了OceanBase升级传统数据库。

2022年上半年,在不少项目暂停、放缓之时,太保和OceanBase正在紧锣密鼓的远程协作,加班加点,只为搞定P17。

据林春回忆,2022年初启动项目到8月31号,核心业务场景就完成了数据功能的开发;12月18日,P17第一个子系统成功上线,并完成了全量数据库迁移;2023年5月6日,核心交易、相关的报表库迁移上线;5月13日核心系统中最难的核心交易库上线。至今,P17核心系统已经成功运行了200多天,确保交易成功率达到99.99%。

“项目刚开始时,正是上海管控最紧张的时刻。大家没办法到场地,造成了很多困难,但是OB在产业侧和技术侧联合攻坚,把这块硬骨头啃了下来。”林春谈起到项目的全过程,仍然不禁感慨。

金融数据库的战场,太平洋保险和OceanBase打了场胜仗,金融,数据库,oceanbase

OceanBase的系统整体架构图

整个升级的流程,可以分为四个阶段:

第一阶段的重点,是通过OceanBase的分布式架构彻底升级传统商用的主备架构,破除传统数据库与操作系统、中间件的耦合。据了解,与Oracle配套的DS、Cognos等产品对于Oracle深度依赖,适配改造复杂度很⾼,将数据库分库分表,从集中式拆分成分布式,每个分片都能够独立执行读写,这个过程中需不断拆解中间件和操作系统之间的关系。

第二阶段,OceanBase和太保并没有急着对业务进行升级,而是建立了迁移“标准”,一次次探索形成行业经验,破除替换升级的壁垒。

OceanBase华东区金融技术服务总监郭文讲道:“厂商和用户侧的目标是希望效果稳定的与传统数据库兼容,标准化、流程化、制式化能够降低双方的人力投入,少走弯路,同时能够复制工具和经验。” 

郭文介绍道:“OceanBase通过制定33类标准规范和28类最佳实践,以及打磨了16款数据库转向工具,实现了标准化的Oracle兼容,这会极大程度破除迁移的不透明性,让企业更有信心,意识到升级不再是一件特别困难的事情。” 

比如创新研发的“指南针”工具,能够对传统数据库进⾏改造评估预扫描,包括近20个检查⼤类,近200多个检查项,评估项全⾯⾼效,极⼤提升项⽬组问题排查的效率,缩短项⽬周期从⽽降低应⽤改造成本。以“P17客户服务系统”为例,扫描出改造项约6000个,假设⼈⼯⽅式排查2个问题/⼩时,单个项⽬即节约⼈⼒成本12.6⼈/⽉。

第三阶段,对P17中的业务场景进行逐个点测。对寿险保监会稽核接口系统、寿险营销员系统的佣金计算、智能决策服务平台和寿险统一承保平台等“一事一议”的替换。

第四阶段,从点测到全面升级。这里的全面升级,并不只是P17系统的全面升级,而是太保秉持着“先难后易”的原则,以P17这套最复杂的系统为模版,对周边配套系统进行分布式升级。

在全面升级后,国产数据库的优异性能开始展现出来。据太保反馈数据,在保持了高运行性能、高可用能力的同时,数据库软件的运维费用大幅降低,每年可节省设备投入数亿元。特别是OceanBase的高级压缩技术,结合“数据库瘦身”,将存储容量节省80%以上。

可以说,升级后的应⽤系统弹性扩缩容、处理速度、数据加⼯能⼒均实现⼤幅提升。

长于金融的数据库,更懂金融

 OceanBase与太保的探索经验,也带动着金融数据库发展进入下一个阶段。

在整个实践的过程中能够明显发现,金融场景考验的不只是性能,更多还在于复杂业务中的灵活应变能力和适应能力。显然,诞生于金融场景的OceanBase更懂行业的需求和痛点,也有机会能将实验室的解决方案,搬到了业务中去。

2013年,OceanBase开始应用于蚂蚁集团的支付业务,当时大部分互联网企业都在采买Oracle,但随着双十一交易量的瞬时爆发,成本高企压力之下,促使了云厂商们开始自研数据库。

彼时OceanBase最核心的任务,是完成降本增效和弹性伸缩。在这两个方面的经验,也在太保案例中得以体现。

正如前文所讲,之所以将存储容量节省至80%以上,来源于OceanBase独创的高压缩比的分布式存储引擎,在提升业务系统稳定性和安全性的前提下,存储成本为70%-90%,同时硬件和维保资源投入显著降低。

林春就算过一笔账:“1TB的存储成本传统数据库要4500块钱,OceanBase压缩到了三分之一,成本会大幅减少。另外数据库加密之后,对场地成本要求就没有那么高,也能降低硬件成本。” 

2020年山东移动计费业务系统接入OceanBase,其计费业务详单处理时长缩短至5分钟,处理效率提升30%,数据由7T压缩至0.7T,存储投入成本降低90%。

另一方面,OceanBase的单机一体化分布式架构也能够在硬件存储资源帮助企业控制成本和灵活扩缩容。顾名思义,单机一体化的数据库,既能够适应大型企业的系统逐步替换需求,在不需要分布式架构时,也可以作为一个完整的集中数据库提供,让企业能够部署更灵活。

同时,HTAP集TP(交易)和AP(分析)于一体的数据库架构,也能够同时适应TP场景和AP场景,单一引擎支持高性能混合负载应用,通过基于时间片的混合负载调度技术,解决混合负载的资源隔离问题。一个典型案例是太保的寿险需要与保监会稽核系统接口,以前该系统夜间批处理占据整体计算资源的90%以上,现在,相同资源的批处理节省了时间62%,监管报送批量场景的性能提升了3倍。

除此之外,全自研数据库也成为了OceanBase换道超车的关键。

OceanBase数据库创始人、首席科学家阳振坤此前提到,“全自研是个苦活累活,OceanBase数据库是从第一行代码开始,到现在积累了几百万行代码量,但是好处也显而易见。” 

让林春印象最深刻的是OceanBase对Bug的修复速度非常震撼。常常很多问题,大致是第一天发现,第二天就能更新一个修复版本,这就体现了OceanBase全自研数据库,将内核代码都掌握在自己手中的特点。Bug修复速度是技术兜底的一个很好的验证,如果没有对核心代码的掌控,从排查问题到解决问题,就做不到闪电速度。

也正是因为上述原因,让大型银行、保险业开始对国产数据库充满信心。

但这也只是万里长征的第二阶段,数字化、智能化的车轮滚滚向前,国产数据库从金融场景“杀”出来之后,千行百业中还有更广阔的星辰大海。

欢迎关注光锥智能CSDN号,获取更多前沿科技知识!文章来源地址https://www.toymoban.com/news/detail-589621.html

到了这里,关于金融数据库的战场,太平洋保险和OceanBase打了场胜仗的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 代码随想录第六十三天——被围绕的区域,太平洋大西洋水流问题,最大人工岛

    题目链接:被围绕的区域 步骤一:深搜或者广搜将地图周边的’O’全部改成’A’ 步骤二:遍历地图,将’O’全部改成’X’,将’A’改回’O’ 题目链接:太平洋大西洋水流问题 思路:从太平洋边上的节点 逆流而上,将遍历过的节点都标记上。 从大西洋的边上节点 逆流而

    2024年01月16日
    浏览(53)
  • 代码随想录| 图论02●695岛屿最大面积 ●1020飞地的数量 ●130被围绕的区域 ●417太平洋大西洋水流问题

    #695岛屿最大面积 模板题,很快.以下两种dfs,区别是看第一个点放不放到dfs函数中处理,那么初始化的area一个是1一个是0  bfs:对应也有两种 #1020飞地的数量 下面是自己写的dfs,过了但是很多可以改进。bfs也差不多这里就不写了  可改进的点: 1 其实遍历四周可以四个循环合

    2024年02月16日
    浏览(45)
  • 分布式数据库 GaiaDB-X 金融应用实践

    在银行的 IT 建设历程中,尤其是中大行,大多都基于大型机和小型机来构建核心系统。随着银行业务的快速发展,这样的系统对业务的支持越来越举步维艰,主要体现在以下四个方面: 首先是难以支持银行快速发展的业务。随着国内电商、互联网支付、手机支付的迅猛发展

    2024年02月04日
    浏览(39)
  • 苏光牛:全面数字化时代,金融核心业务系统数据库如何选型?

    在新一轮科技革命和产业变革的背景下,全球企业进入数字化时代,全球的营商环境发生了很大的变化,金融业需要加速进入智能化升级时代。此外,由于金融是国家经济的基础,结合营商环境,需要跟上产业的变革转型,增强金融产品的核心竞争力。 金融业的信息化建设思

    2024年02月06日
    浏览(46)
  • GBASE金融信创优秀解决方案鉴赏 · 核心业务系统数据库解决方案

    为此,实验室特别开设金融信创优秀解决方案专栏,集中展示优秀成果。现在,让我们一起来领略下GBASE的优秀解决方案吧~ 可点击阅读原文  → 《金融信创优秀解决方案--核心业务系统数据库解决方案》。 核心业务系统数据库解决方案 方案简介 随着技术的不断创新发展,银

    2024年02月10日
    浏览(45)
  • 【数据库原理】(32)数据库设计-数据库物理设计

    数据库的物理设计是数据库设计过程中至关重要的一个阶段。其核心目标是选择一个适合应用环境的物理结构,以满足特定的性能、存储和访问需求。这一阶段涉及的关键任务可以分为两个主要步骤: 1. 确定数据的物理结构 存储结构和存取方法的选择 :这包括决定数据在物

    2024年01月19日
    浏览(55)
  • 【数据库概论】图数据库 Vs 关系数据库(1)

    假设有一个社交网络需要用数据库存储,其中人与人之间的关系有:朋友(friend)、父母(parent) 首先用关系数据库来实现朋友关系,需要 3 张表:people、people_relation、relation 如果要查询 Jam 的所有朋友的信息,那么就需要连接三张表: 如果表的数据量较大,那么查询效率就

    2024年03月14日
    浏览(46)
  • 【数据库】 | 初始数据库

    🎗️ 博客新人,希望大家一起加油进步 🎗️ 乾坤未定,你我皆黑马 1、什么是数据库 存储数据用文件就可以了,为什么还要弄个数据库? 文件保存数据有以下几个缺点: 文件的安全性问题 文件不利于数据查询和管理 文件不利于存储海量数据 文件在程序中控制不方便 数据

    2023年04月23日
    浏览(57)
  • 【数据库】数据库设计

    数据库设计面对的主要有哪些问题 (1) 懂数据库原理同时懂甲方软件专业知识的人缺少; (2) 应用的数据库系统的最终目标往往在一开始不能完全明确,与开发者与用户方最初没在要求完全一致有关; (3) 应用业务系统千差万别的,难以找到一种通用的工具和方法。 (1) 对人员

    2024年02月05日
    浏览(63)
  • 数据库应用:数据库管理系统与安装MySQL数据库

    目录 一、理论 1.数据库管理系统 2.关系型数据库 3.数据库 4.MySQL数据库 5.MySQL部署 二、实验 1.yum安装MySQL 2.编译安装MySQL 3.配置MySQL数据库的Tab补全  三、问题 1.数据库登录报错 2.数据库密码复杂度报错 3.数据库连接报错 四、总结 (1)概念 数据库管理系统(Database Management

    2024年02月13日
    浏览(55)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包