杨冰:OceanBase助力数字化转型,原生分布式数据库成核心系统首选

简介: 10月22日上午,本届“2021 OceanBase 原生分布式数据库论坛” 上,OceanBase CEO杨冰为大家带来了《基础软件助力核心系统数字化转型》的主题演讲。


121.gif121.gif

121.gif

10月22日上午,本届“2021 OceanBase 原生分布式数据库论坛” 上,OceanBase CEO杨冰为大家带来了《基础软件助力核心系统数字化转型》的主题演讲。


新物种原生分布式数据库

助力企业数字化


当下,数字化转型已经成为全行业最热门的话题之一。在这样一个熟悉的话题下,以前大家讨论是什么,为什么要做,而今天,当我们再提起数字化转型时,90%人都认为“数字化转型已经不是选择题,而是必选题”。


从胶片相机到数码相机,从功能机到智能手机,从燃油车到电动车,这些产品无一不是颠覆了传统,改变了人们的行为和认识。也正是这些新物种开辟了新时代,虽然新物种可能没有全新的外形,但内核的底层逻辑已经改变。


image.png


随着互联网终端产生的海量数据呈几何式暴增,因此,核心业务数据处理平台的架构变革亟待提升。同时,眼下就应用层面来说,另一个重要趋势是应用从单体架构、集群架构,走向分布式云原生架构,这也对底层基础软件提出了快速弹性、无限扩展的新架构诉求。传统集中式数据库在容量、高并发、备份效率、运维、安全风险等方面已经无法满足新的业务需求,有超过90%的企业认为分布式数据库具备更优异的应对能力和部署效果。


因此,在数据库革新的时代背景下,新物种正是原生分布式数据库。OceanBase是一款企业级的原生分布式数据库,自研一体化架构,融合分布式与集中式技术优势,开启了企业级数据库全新模式。杨冰称“原生分布式数据库将引领数据库方向的发展”,它从技术层面上做出了解读:首先是云存储使数据量爆发增长,其次是应用架构加入数据库领域,最后是硬件正在逐渐变成廉价的处理单元。


而相比集中式数据库,理想的核心数据库具有高可用、高扩展、高兼容、易管理、高稳定性、运维成本低、部署灵活等明显优势。杨冰认为:“原生分布式数据库已经成为核心系统首选,金融场景对分布式数据库的大规模替换成为分布式数据库发展的重要推动。


西安银行作为非常典型的金融客户,一方面表现为业务使用频次的提升,另一方面,随着移动互联网的发展,各行业的核心系统在不断向c端延伸,无论整体和局部,都对数据库算力提出很高的要求, 而数据库扩容在过去从来就不是一件容易的事。


西安银行离柜业务率已经超过90%、高达2/3的信用卡获客是通过数字化,客户体验、成本、效率都是目前银行面临的最大的挑战和问题。面对挑战,西安银行主动通过数字化转型,使用了  OceanBase 分布式数据库以及阿里云,有效支撑了西安银行的数字基础设施,适应手机银行的新定位。


OceanBase  取代 Oracle  数据库后,每账号成本降至原来的四分之一,用户数、活跃度增长率均超过100%,客户app响应速度提升1倍以上(从500ms提升到200ms)。从2018年转型开始,不到3年时间,2020年银行总资产超过3000亿元,同比增长超过10%,成为西北地区首家A股上市的城商行。

OceanBase 实践之路

原生分布式数据库成为核心系统首选


企业数字化转型经过这些年的实践和推动,已经进入了数字化转型的第三阶段,转型也从非核心业务真正走向核心业务的深水区。我们看到国家在十四五规划中,明确提出数字技术广泛应用于政府管理服务,加强公共数据开放共享,推动政务信息化共建共用,真正建设数字化政府。


数字化向企业业务纵深层面辐射。但随着移动互联网和大数据的发展,今天我们客户的核心数据库面临比从前更严峻的挑战,主要表现在以下四个大方面:


第一,技术改不了。企业的核心业务系统投建早,大多与数据库能力深度绑定,迁移改造工作量大,风险高,时间长。


image.gif某头部保险公司,信息化时间很早, 核心系统包含数百套数据库实例, 虽然客户自身有非常强的意愿迁移到新的国产数据库,但迁移到全新的数据库有可能面临应用的全面重构,这种工作量和风险是客户无法负担的。 由于 OceanBase 可以提供非常高的Oracle兼容能力,除了SQL语言,还包括完整的PL/SQL能力,以及OCI和Pro*C的替代产品,提供完全兼容的语法和接口调用,原应用几乎不需要修改就能原封不动地运行,所以客户选择了OceanBase。


第二,服务挺不住。服务向客户终端延伸,核心系统面临 7x24 高可用的挑战,系统设计无法支撑。
image.gif

西南某中型银行的核心迁移就是如此。我们知道,监管对金融机构的可用性是有很高要求的,  核心系统要满足城市级容灾标准,业务不中断,数据不丢。这在传统的主备容灾构架中是难以实现的。客户选择 OceanBase  也是因为原生分布式数据库多副本和强一致的特性,且能够以小成本实现异地的无损容灾。对高可用有要求的客户多数会选择OceanBase的两地三中心容灾方案以及可用性更高的三地五中心方案。


第三,管理环节多。业务系统种类不断增加,50%用户认为随着数据库实例数量的不断增加,运维管理变得更困难。
image.gif

OceanBase资源池管理支撑中华财险新一代互联网核心业务。由于历史原因,以及ISV的合作推荐,  客户原有的上百个数据库实例包含了4种数据库产品, 这给运维工作造成了很大的困难, 故障的概率增大。借着核心系统分布式改造的机会,利用  OceanBase 多租户的能力,用户将这数百个实例迁移到了几十套 OceanBase 集群,实现了技术栈归一,  减少了管理实体的数量,也降低了管理的复杂度,提高了运维的稳定性,节省了运维成本。


第四,业务跑不动。面对核心业务持续互联网化,52%用户认为性能难以支持高并发的业务场景。


image.gif

OceanBase透明扩展能力承载电商平台爆发增长的国际业务。某快速增长的互联网跨境电商就碰到了这样的问题。该客户的电商平台就是基于MySQL主从复制构建的,没有做分库设计,因为这样在前期最省。在业务成功之后,单纯靠增加数据库硬件资源已经无法满足业务的发展,这对整个线性扩展要求及成本控制要求都非常高,OceanBase极强的线性扩展能力很好支撑了业务扩展,令其可以自由的扩容和缩容,另外,加上多租户能力和迁移成本,特别是OceanBase在超过50台以上的MySQL集群的规模下,TCU下降50%,存储和计算成本上会有明显优势。

 

通过上面的几大实践案例,我们总结了理想核心数据库的几个典型特征:高可用、高扩展、高兼容、易管理和部署灵活而这些,OceanBase 在与行业伙伴合作的过程中也一次次证明了自己。也正是通过这些检验,可以看出,未来2-3年将是数字化转型的关键期,核心系统升级迫在眉睫,原生分布式数据库正在成为核心系统首选


面向未来 OceanBase

加速数据库生态布局


十一年路漫漫,OceanBase 面向不同的客户核心系统,都已经可以从容面对。既提供商业版、社区开源版不同产品形式,也支持独立软件、私有云、混合云、公有云等多种部署形态,让不同类型的客户都能选择到适合的产品和服务。今天,OceanBase 3.2版本正式发布,可以说在探索理想数据库的道路上,OceanBase又有了新的进步。


未来,OceanBase 也将继续秉承把复杂留给数据库,把简单留给客的宗旨,专注做好数据库的功能,帮应用屏蔽非功能性的复杂度。杨冰表示:看整个 OceanBase 发展历程,从早些年开始讲究“原生分布式”代替“分库分表”,迄今为止也一直坚持做透明可拓展。


杨冰介绍道,就算是面对超大型企业、头部互联网这些大型客户,我们拥有的原生分布式架构,高兼容性、透明扩展都非常好的适配了这些客户的超高业务负载,快速弹性的诉求,而且支付宝的10年历程更让我们对 OceanBase 的稳定性充满信心;另一方面,一年的商业化之路,我们做了大量的兼容性、性价比、降门槛、易用性的工作,让OceanBase 面对中小型客户时,更加灵活,TCO更低,越来越多的客户选择与OceanBase 一起成长;最后我们还提供成本低廉,架构先进、性能优越、免运维的OceanBase 云数据库,让小微客户选择无忧,同时社区开源后也吸引了更多的数据库开者加入 OceanBase,OceanBase 生态逐步形成。


“路虽远、行则将至、事虽难,做则必成。”回过头来看 OceanBase 的发展之路,杨冰在多个场合提及的这句话掷地有声。

相关文章
|
15天前
|
存储 运维 负载均衡
构建高可用性GraphRAG系统:分布式部署与容错机制
【10月更文挑战第28天】作为一名数据科学家和系统架构师,我在构建和维护大规模分布式系统方面有着丰富的经验。最近,我负责了一个基于GraphRAG(Graph Retrieval-Augmented Generation)模型的项目,该模型用于构建一个高可用性的问答系统。在这个过程中,我深刻体会到分布式部署和容错机制的重要性。本文将详细介绍如何在生产环境中构建一个高可用性的GraphRAG系统,包括分布式部署方案、负载均衡、故障检测与恢复机制等方面的内容。
68 4
构建高可用性GraphRAG系统:分布式部署与容错机制
|
28天前
|
安全 NoSQL 关系型数据库
阿里云数据库:助力企业数字化转型的强大引擎
阿里云数据库:助力企业数字化转型的强大引擎
|
1月前
|
消息中间件 中间件 数据库
NServiceBus:打造企业级服务总线的利器——深度解析这一面向消息中间件如何革新分布式应用开发与提升系统可靠性
【10月更文挑战第9天】NServiceBus 是一个面向消息的中间件,专为构建分布式应用程序设计,特别适用于企业级服务总线(ESB)。它通过消息队列实现服务间的解耦,提高系统的可扩展性和容错性。在 .NET 生态中,NServiceBus 提供了强大的功能,支持多种传输方式如 RabbitMQ 和 Azure Service Bus。通过异步消息传递模式,各组件可以独立运作,即使某部分出现故障也不会影响整体系统。 示例代码展示了如何使用 NServiceBus 发送和接收消息,简化了系统的设计和维护。
46 3
|
1月前
|
存储 开发框架 .NET
C#语言如何搭建分布式文件存储系统
C#语言如何搭建分布式文件存储系统
69 2
|
30天前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现?
消息队列系统中的确认机制在分布式系统中如何实现?
|
1月前
|
存储 分布式计算 监控
C# 创建一个分布式文件存储系统需要怎么设计??
C# 创建一个分布式文件存储系统需要怎么设计??
33 0
|
1月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
3月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
110 2
基于Redis的高可用分布式锁——RedLock
|
3月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
|
7天前
|
NoSQL Redis
Redis分布式锁如何实现 ?
Redis分布式锁通过SETNX指令实现,确保仅在键不存在时设置值。此机制用于控制多个线程对共享资源的访问,避免并发冲突。然而,实际应用中需解决死锁、锁超时、归一化、可重入及阻塞等问题,以确保系统的稳定性和可靠性。解决方案包括设置锁超时、引入Watch Dog机制、使用ThreadLocal绑定加解锁操作、实现计数器支持可重入锁以及采用自旋锁思想处理阻塞请求。
40 16