OceanBase CTO杨传辉:单机分布式一体化助力企业降本增效

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 11 月 3 日,2022 云栖大会在杭州开幕,在本届云栖大会上,OceanBase CTO 杨传辉发表了《单机分布式一体化助力企业降本增效》的主题演讲,正式发布了 OceanBase 社区版 4.0(代号:小鱼),并开启了 OceanBase Cloud 4.0 版本的邀测。

image.png

各位来宾、各位蚂蚁集团和 OceanBase 的客户,大家下午好!我是杨传辉,来自OceanBase,今天我给大家分享的主题叫做《单机分布式一体化助力企业降本增效》


在 8 月 10 日 OceanBase 的年度产品发布会上,我们公布了最新的单机分布式一体化架构 OceanBase 4.0,其对于客户来讲最重要的核心价值就是降本增效,帮助每一个客户更好地挖掘数据的价值,今天我的演讲将围绕此进行展开。

image.png

国际货币基金组织的一份数据表明:2022 年全球经济增速已经下降到 3.2%,可能大家对这个数字不一定有感觉,借用最近很流行的一句话叫“让寒意传递到每一个人”,相信大家就明白了。无论身处哪个行业,大家或多或少都感觉到了一些寒意。在今天这样一个经济承压的大背景下,不同行业的客户到底在关心什么样的问题?我给大家简单举几个例子。


首先,给大家分享一下 OceanBase 在不同行业的客户案例。


云南红塔银行:原来使用的是 IBM 的小型机、高端存储,是非常经典的集中式数据库。使用集中式数据库面临着很多问题:硬件成本高昂、集中式数据库处理能力非常有限等,而通过升级到 OceanBase 的分布式核心技术最终使得整个红塔银行的和系统整体成本降低了90%,处理能力也由原来每秒钟 200TPS 提升到每秒钟 8000TPS,并且具备了两地三中心无损容灾能力。


中石化加油卡:原来其使用集中式数据库的架构,即每一个省份都有自己独立的 IT 系统和数据库,所以带来了运维复杂、系统风险等很多问题,没有办法满足业务控制风险和快速发展的需求。通过升级到 OceanBase 分布式数据库,实现了资源利用率的大幅度提升,系统也实现了整个业务的全国大集中,最终我们做到 HTAP 混合负载并发处理能力达到每分钟 5 万笔。


致欧家居:一家跨境电商企业,原来使用的是分散的开源数据库 MySQL,其管理运维比较复杂,客户研发效率比较低,通过 OceanBase Cloud 最终大幅度提升了研发效率和运维效率,使致欧家居的客户可以把更多精力放在业务创新上,大幅度提升了业务迭代效率。


GCash:这是菲律宾版的在线钱包,原来也是使用分散的 MySQL 数据库,通过 OceanBase Cloud 的分布式数据库托管服务,最终使得资源利用率大幅度提升,存储空间下降 70%,资源成本降低 40%,这正是 OceanBase 具备向多租户极致压缩等做数据融合、做数据极限压缩的能力。

image.png

我们看到国内外不同行业的客户,在这样一个全球经济承压的形势下,总是倾向于做两件事情:降本、增效。通过“降本”解决生存问题,“增效”解决发展问题。


大家都知道,全球经济是一个螺旋式上升的过程,有低谷也有高峰,有一些卓越的公司借“低谷”契机,实现了更快的发展速度,成为了行业的领导者,但另外一些普通的公司经过经济低谷以后增长就失速了。他们最大的差别在于卓越公司在经济低谷的时候除了经过降本增效解决生存问题,还会做更多面向未来提升效率的事情,会把更多资源投入到未来的人才和业务布局上。


再说回我们的 OceanBase 4.0,我们称其为单机分布式一体化架构,一方面它具备单机数据库高性能、低成本的优势,这个优势可以帮助客户降低成本;另外一方面具备分布式数据库高可用、可扩展、面向云,面向未来的优势,帮助客户更好地挖掘数据价值,也就是说,通过 OceanBase 4.0 可以同时帮助客户降本增效,赢得未来。


▋85天,4.0经历了什么


距离 8 月 10 日 OceanBase 年度产品发布会到现在正好 85 天时间,OceanBase 的研发团队做了几件事。


首先,研发版本的快速迭代。上次的产品发布会我们发布的是 Alpha 版本,今天我们发布的是 Beta 版本。OceanBase 有一个非常强大的优势,即背靠蚂蚁集团的核心业务场景,每当 OceanBase 有一些重大技术创新的时候,我们总是能够在蚂蚁集团核心业务场景中找到实验场景,从而打磨 OceanBase 的稳定性。OceanBase Alpha 版本完成以后,在集团和不同行业用户进行了小范围邀测,通过真实的业务场景来打磨 OceanBase 的稳定性。


所以今天我们看到的 4.0 版本,也变更了研发模式,最终我们做到了将社区版与企业版融合成一个主干代码的研发分支,通过这种模式能够实现企业版做的每一个功能都能够实时融入到社区版本,做到 MySQL 兼容能力全面开放,包括企业版所有的能力,最终做到社区版与企业版同等性能。

▋由社区驱动的开源,能力不断突破

去年 6 月 1 日,OceanBase 首次对外宣布开源,到今天一年多的时间,OceanBase 在社区和用户的驱动下得到了飞速发展,整个 OceanBase 的核心能力也得到了非常大的突破。

OceanBase 的开源主要经历了三个阶段:

image.png

第一,核心引擎开放阶段。核心内核引擎的 300 万行代码完全对外开放开源,这个阶段只有一个内核引擎,没有完整的生态工具的支持。


第二,生态建设阶段。基于第一批开源用户和他们的真实需求不断完善我们的生态工具,支持超过 20 个生态工具,支持 8 个主流 Linux12 个版本、支持 K8s-operator、支持监控 Prometheus、支持数据同步工具 Canal 和 DataX 以及客户端工具 Navicat / Dbeaver。

第三,易用性改进阶段。这个阶段已经有少部分开源用户把其核心业务场景放在 OceanBase 的开源版,此时我们的核心目标就是从“能用”到“更好用”,所以在易用性上怎样做监控、怎样做运维、怎样做数据同步链路可视化等等成了我们亟待解决的问题,我们做了很大易用性的提升,最终使越来越多的用户把 OceanBase 的开源版本用在核心业务场景。

我相信基于最新的 4.0 单机一体化架构,可以使 OceanBase 社区版成为每一个客户数据库开源的首选。

image.png

今天我们正式发布 OceanBase 社区版 4.0:全球首个兼容 MySQL 的单机分布式一体化数据库,兼具单机数据库高性能、低成本,与分布式数据库高可用、可扩展、弹性双重技术优势。同时,我们也将 OceanBase 十几年来在蚂蚁集团“双11”、TPC-H 全球前三、TPC-C 全球第一等核心业务场景中的技术创新能力融入到了最新的 OceanBase 社区版 4.0,既能够支持大企业,也能够支持中小企业,甚至是初创企业,“从小到大”一站式满足客户全生命周期的数据管理和存储需求。

image.png

OceanBase 社区版 4.0 代号“小鱼”,我认为其对于行业最大的贡献在于极大降低了分布式数据库的门槛。以前很多人认为分布式数据库有很高的门槛,对硬件要求比较高,运维比较复杂,社区版 4.0 出来以后这个行业发生了改变。


▋4C16G可在生产环境稳定运行


目前,很多用户已经认可了分布式数据库的价值,但仍旧也有一些具体的需求,比如希望能够降低分布式数据库的部署门槛;提升分布式数据库的易用性;希望分布式数据库既能做好 OLTP 交易,也能够做好 OLAP 分析。

此次发布的社区版 4.0,通过单机一体化架构、单机部署、小规格部署降低分布式数据库的部署成本,通过一键安装部署提升分布式数据库的易用性,通过 HTAP 和更强的 OLAP 能力提升分布式数据库的分析能力,最终实现 OceanBase 社区版 4.0 在 4C 16G 的生产系统能够稳定运行。

▋从5步到1步,2分钟快速部署

我们由原来需要 5 步手动安装部署,优化为一步,两分钟可以完成 Demo 体验。在蚂蚁集团展区的 OceanBase 展台有体验环节,其在安装部署的前面放了一个计时器,我昨天试了一下,2 分钟之内即可完成。与此同时,我们还将 TPC-H 全球前三的能力融入到了最新的 OceanBase 社区版 4.0 中。

image.png在 8 月 10 日 OceanBase 的年度产品发布会上,我们对比了 OceanBase 和 MySQL 的性能,当时使用的是 MySQL 企业版 8.0 与 OceanBase 的企业版4.0,在同等硬件条件下,OceanBase 企业版 4.0 的性能是 MySQL 企业版 8.0 的 1.9 倍,今天,我们做了另外一个事情,将企业版与社区版融合到一个分支,做到企业版与社区版完全相同的性能,最终做到 OceanBase 4.0 社区版本性能达到 MySQL 企业版版本性能 1.9 倍。

对于一个数据库来说,既能用 OLTP 做交易,也能用 OLAP 做分析,这是一件很棒的事。今天我非常高兴在这里和大家一起见证 OceanBase 社区版 4.0 的 TPC-H 性能。

我们已经在云端分别部署了 OceanBase 社区版 4.0 和 Greenplum 6.22.1 两个数据库,采用一模一样的硬件配置,都是三台机器,每台机器 32C 128G,分别对这两个数据库进行跑分测试。


image.png

如上图所示,左边屏幕是压测的画面,有两个数据库,接下来我们将同时启动两个测试脚本,一个是 OceanBase 社区版 4.0 的测试脚本,一个是 Greenplum 6.22.1 的版本,我们在右边做了一个实时画面,同时做了一个工具每秒钟实时读取左侧画面的压测数据,并在右边转化为实时画面。右边这个画面中是一系列的柱状图,柱子有两种颜色:蓝色表示 OceanBase 社区版 4.0,橙色表示 Greenplum 6.22.1,这个柱子长短表示压测的时间,总共 22 条查询,柱子越短跑的越快,可以看到 OceanBase 跑的速度比较快。第一个查询 OceanBase 跑的2.29 秒,Greenplum 跑的 22.47 秒;第一个查询在 TPC-H 是单张表格做聚合的查询,主要考察的是数据库的并行执行能力,OceanBase 在并行执行上,尤其是分区内做并行执行有明显优势。Greenplum 跑到第 9 条,有一些跑得更快一些,一些跑得更慢一些。

测试表明,同等硬件的环境之下,OceanBase 社区版 4.0 版本的性能是 Greenplum6.22 的 5-6 倍,部分性能场景性能达到 20-60 倍,侧面表明了 OceanBase 社区版 4.0 具备强大的 OLAP 处理能力,是一个同时能够处理 OLTP 与 OLAP 的 HTAP 数据库。

在测试尾声,我给大家分享一下 OceanBase 在 HTAP 的一些应用场景。以前数据库一般分为 OLTP 数据库和 OLAP 数据库,通过 ETL 工具实时或定期把 OLTP 的数据库拉取到 OLAP 的数据库中,这种模式带来两个问题:第一,数据可能有延迟。第二,OLAP 与 OLTP 数据库之间数据不一致,有了 HTAP 数据库以后,可以在一个数据引擎里实现 TP 和 AP 的混合负载,最终避免了数据延迟和数据一致性的问题。

这个数据库有什么样的好处?我给大家举几个例子。

最近正好是“双 11”,当买家完成一笔交易或一笔付款操作的时候,商家希望根据你的付款操作实时调整营销策略。如果是以前 OLTP 和 OLAP 分离的模式肯定做不到,因为会有延迟,有了 HTAP 数据库之后,能够实现在“双 11”当天实时根据交易支付的情况调整最优的营销策略。

大家知道 DBA 经常维护在线库和历史库,在线库主要是一些并发量比较高的数据,算是一个 OLTP 数据库,历史库是一个并发量很低,但是数据量很大、查询很复杂的数据库,它是一个 OLAP 的数据库。此时,DBA 经常需要干一个事情:把在线库数据定期拉到历史库,并且删除在线库数据,这个操作非常复杂,有了 HTAP 数据库,可以避免这样的一些操作,大大降低业务的复杂度。


image.png

下面进入到今天的第二个发布环节,OceanBase 是一个面向多云设计的一体化架构数据库,既支持专有云部署也支持公有云部署,支持混合云部署、多云部署,而且可以做到在不同云的模式下,OceanBase 对用户提供的是完全一致的体验。


原来 OceanBase 已经有公有云的托管服务,但是最多能够支持到公有云 3.2 的版本,今天我们全托管的 OceanBase Cloud 正式开放 4.0 的邀测:规格更小,部署成本更低、降本增效能力更好、可观测性更强,大家可以进入官网加入到 OceanBase Cloud 4.0 版本邀测体验过程当中。


OceanBase Cloud 4.0 版本通过单机分布式一体化架构助力云上客户实现降本增效,其支持更小的规格,已经能够支持到 4C 16G 这样从小到大的全发展过程,从 4C 16G 到 8C 32G,到 16C 64G,再到 42C 400G,乃至多机分布式部署,OceanBase Cloud 4.0 有更好的降本增效的能力,TP 性能相比之前的版本提升50%,AP 性能也得到大幅度提升,并且有更好的多租户隔离能力。


OceanBase Cloud 4.0 版本具备更强的可观测性,支持了几个功能,包括全链路诊断的能力、数据迁移的可观测性,最终实现了对于每一个 DBA 来说更加好的运维体验。


image.png

我们始终认为,对于一个数据库来说,降低成本只是第一步,OceanBase Cloud 4.0 版本不仅仅是降成本,更是在空中换上面向未来的数据发动机,这是其核心意义。不仅仅能够用来做适合分布式场景的大型用户,也能够用来做适合单机场景的中小规模用户,甚至是初创企业。通过 4.0 版本的技术创新,包括小型化、小规格部署能力,更强的降本增效能力,社区版和企业版的融合,社区版能力的增强、易用性提升、可观测性的提升,最终实现“小就是大”——一个企业从小到大发展的过程当中,能够实现一次选择,终身受用。在这个发展过程当中,OceanBase 也能够在后方做好服务,保证稳定可靠,使企业能够更放心、更安全地享受到数据处理的价值。


相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
3月前
|
存储 SQL 分布式数据库
OceanBase 入门:分布式数据库的基础概念
【8月更文第31天】在当今的大数据时代,随着业务规模的不断扩大,传统的单机数据库已经难以满足高并发、大数据量的应用需求。分布式数据库应运而生,成为解决这一问题的有效方案之一。本文将介绍一款由阿里巴巴集团自主研发的分布式数据库——OceanBase,并通过一些基础概念和实际代码示例来帮助读者理解其工作原理。
279 0
|
3月前
|
存储 分布式计算 算法
探索Hadoop的三种运行模式:单机模式、伪分布式模式和完全分布式模式
在配置Hadoop集群之前,了解这三种模式的特点、适用场景和配置差异是非常重要的。这有助于用户根据个人需求和资源情况,选择最适合自己的Hadoop运行模式。在最初的学习和开发阶段,单机模式和伪分布式模式能为用户提供便利和成本效益。进而,当用户要处理大规模数据集时,完全分布式模式将是理想的选择。
157 2
|
3月前
|
SQL 监控 分布式数据库
【解锁数据库监控的神秘力量!】OceanBase社区版与Zabbix的完美邂逅 —— 揭秘分布式数据库监控的终极奥秘!
【8月更文挑战第7天】随着OceanBase社区版的普及,企业广泛采用这一高性能、高可用的分布式数据库。为保障系统稳定,使用成熟的Zabbix监控工具对其进行全方位监控至关重要。本文通过实例介绍如何在Zabbix中配置监控OceanBase的方法,包括创建监控模板、添加监控项(如TPS)、设置触发器及图形展示,并提供示例脚本帮助快速上手。通过这些步骤,可以有效监控OceanBase状态,确保业务连续性。
102 0
|
5月前
|
关系型数据库 MySQL 数据库
深入OceanBase分布式数据库:MySQL 模式下的 SQL 基本操作
深入OceanBase分布式数据库:MySQL 模式下的 SQL 基本操作
|
5月前
|
存储 分布式数据库 数据库
深入OceanBase内部机制:分区构建高可用、高性能的分布式数据库基石
深入OceanBase内部机制:分区构建高可用、高性能的分布式数据库基石
|
20天前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
3月前
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
103 2
基于Redis的高可用分布式锁——RedLock
|
3月前
|
缓存 NoSQL Java
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
这篇文章是关于如何在SpringBoot应用中整合Redis并处理分布式场景下的缓存问题,包括缓存穿透、缓存雪崩和缓存击穿。文章详细讨论了在分布式情况下如何添加分布式锁来解决缓存击穿问题,提供了加锁和解锁的实现过程,并展示了使用JMeter进行压力测试来验证锁机制有效性的方法。
SpringBoot整合Redis、以及缓存穿透、缓存雪崩、缓存击穿的理解分布式情况下如何添加分布式锁 【续篇】
|
28天前
|
缓存 NoSQL Java
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁
53 3
大数据-50 Redis 分布式锁 乐观锁 Watch SETNX Lua Redisson分布式锁 Java实现分布式锁
|
21天前
|
NoSQL Redis 数据库
计数器 分布式锁 redis实现
【10月更文挑战第5天】
43 1

热门文章

最新文章