写点什么

用一款数据库解决 80% 的问题,OceanBase 的底气在哪?

  • 2023-11-20
    北京
  • 本文字数:3687 字

    阅读完需:约 12 分钟

用一款数据库解决 80%的问题,OceanBase 的底气在哪?

什么是数据库的一体化?近年来,在数据库领域,关于这个问题有不少讨论和思考。


近日,OceanBase 给出了它的回答。从诞生之初,OceanBase 就将一体化作为最“自然而然”的默认选项,如果从用户视角来描述,一体化的本质是用一个数据库解决 80% 的问题,将 OLTP 与 OLAP 的能力融合在一起,同时处理复杂和简单查询,还能应对任意大小规模的数据量,支持不同的数据类型、模态。


对用户来说,一体化的理念可谓非常诱人,但一体化数据库技术在实践中真能顺利落地吗?是不是所有的用户都适合一体化的产品?沿着这条路走下去,数据库技术将如何演变?11 月 16 日,OceanBase 举办了 2023 年度发布会,公布了一体化数据库的首个长期支持版本 OceanBase 4.2.1 LTS,并对用户关心的热点问题做了解答。从 OceanBase 的脚步中,我们清晰地看到了数据库一体化的图景,并对企业自身是否应该转向一体化数据库技术栈有了客观的认知。


一体化战略的来龙去脉:它会为企业带来怎样的价值?


天下诸事,合久必分,分久必合。在单体数据库时代,数据库在多数场景天然就是接近一体化的。彼时,数据库处理的查询复杂度、数据类型、数据量等指标大同小异,很多企业只需要一个数据库就能应付大部分业务问题。然而,随着 IT 产业的飞速发展,数据成为企业竞争力的主要来源,数据库的应用场景也愈加复杂。SQL、NoSQL、结构化、非结构化数据,迅速增大的数据规模、查询复杂度,这些需求催生了擅长各个对应领域的专有数据库产品,企业也往往需要采购多种产品来覆盖业务需求。


但问题在于,现实中的企业业务并不是一成不变的,甚至经常是快速变化的。业务范围扩张、缩小,经营规模扩大,这些因素都会影响数据库的需求。随着企业业务发展,技术团队最后会面对很多数据库产品和技术栈,熟悉了一个又需要引入一个。暂且不提投入的人力、时间和资金成本,还有一桩很大的麻烦是,很可能因为业务变化或厂商退出市场而不得不放弃,造成巨大的浪费。


此外,无论是小企业成长为中型、大型企业,还是大型企业从原有的单体数据库向新的技术栈迁移,做技术选型时也都要考虑长期使用的稳定性、可扩展性、厂商的演进支持能力,而多样化的数据库技术栈在这些指标上是相当薄弱的。此时,技术领导普遍会犹豫不决,更有可能本着能用则用的心态继续使用现有的老旧技术,客观上也阻碍了业务增长和创新。


很显然,能够一站式应付大部分甚至全部需求,具备良好的支持和长期演进能力的一体式数据库产品更能赢得多数企业的青睐。尤其在技术转型期,当替换老旧数据库已经成为迫在眉睫的挑战时,技术领导更希望能用一体化解决方案快速响应需求,并免除他们的后顾之忧。


这样的行业背景便是 OceanBase 的诞生由来,回顾过去,OceanBase 的成长历程也是与企业实际业务需求紧密结合的。正是因为 OceanBase 的客户饱受数据库技术栈山头林立状况的困扰,抱着“要把复杂留给自己、把简单留给客户”的初心,OceanBase 团队才会将一体化作为产品发展的主线。


也正是在企业的实际落地场景推动下,OceanBase 提出了单机分布式一体化、OLTP/OLAP 一体化、多兼容模式一体化等理念与技术路线。如今,OceanBase 有信心通过一个数据库解决 80% 的需求,这也是经过大量技术研发、业务实践和用户反馈后才有信心给出的数字。


简单来说,一体化数据库给企业带来的价值可以分为两个视角。首先是成长型企业视角,他们一开始的业务规模较小,面对的数据需求简单,所以会采购单机、本地化的数据库产品。随着业务成长,公司数据库技术栈必须要向分布式、云端、多模态发展,这时 OceanBase 的单机分布式一体化解决方案就能为他们带来平滑升级的能力。技术团队不需要很多工作,也不需要很高投资,就能顺利将现有数据库升级为分布式、大规模、多模态架构。


另一个视角则是来自成熟企业。他们需要将原有的单体数据库产品替换为具备更强能力、弹性,乃至符合信创要求的分布式产品,但又不想为此改变原来的运维和投资策略,不愿意把单一的技术栈换成分散、各自独立的方案丛林。这时候 OceanBase 的架构也能符合他们的标准。


未来,随着数据库需求更加多样化、复杂化,企业对一体化数据库的呼声会更加水涨船高。在这一次 OceanBase 年度发布会上,最新发布的 4.2.1 LTS 版本与列存实验室版本规划则为我们进一步明确了一体化数据库接下来的发展方向,标志着一体化数据库的产品思考已经到位和基本成熟。

OceanBase 4.2.1 与未来版本解析:数据库一体化变革进入成熟阶段


如果要总结 OceanBase 4.2.1 LTS 版本的主要特性,抛开性能登顶等领先优势,最重要的一条就是完整的 OLTP 支持。这一点意味着企业可以在 OLTP 场景中完全放心使用 OceanBase,不用担心任何核心功能缺失。至少在 OLTP 这个层面,数据库运维团队可以真正实现一体化,只对一个技术栈负责。如果说数据库一体化是一株不断生长的大树,那么 OLTP 的完整支持意味着 OceanBase 已经有了可以并值得信任的坚实主干。


OceanBase 4.2.1 的一体化能力,具体体现在三个层面:单机分布式一体化、数据库引擎一体化,以及云上云下一体化。


  • 所谓单机分布式一体化,是指用户无需关心单体或分布式的技术底层,OceanBase 可以根据业务量变化,平滑地在单机和多机乃至超大规模分布式集群之间扩缩容,一套数据库就能满足企业的业务成长和变化需求。发布会上提到一点,目前单机模式已经具备高可用能力,从主备模式到数据强一致的仲裁模式。同时,还在现场演示甚至可以实现 OceanBase 4.2.1 LTS 基于树莓派的单机主备库秒级切换能力。

  • 数据库引擎一体化,则包括了一体化的存储、事务和 SQL 引擎。OceanBase 采用了 Shared Nothing 多副本架构来支持 OLTP + 轻量 OLAP 场景,也可以支持多副本不同存储格式,某一个备副本用列存格式来支持 OLTP + 中度 OLAP 场景。SQL 引擎方面,OceanBase 采用推拉结合模式,简单查询拉数据,复杂查询推执行计划,很好地融合了简单和复杂查询。

  • 最后,OceanBase 的底层存储引擎是 LSM-Tree,将数据分为基线和增量类别,这样多副本基线数据部署到多云基础设施时可以只有接近一份的成本,可以实现 Shared Nothing 与云端常用的 Shared Storage 架构完美融合。另外值得一提的是,OceanBase 解决了数据压缩对性能的影响问题,这也是使用 LSM-Tree 的一大收益,使得存储成本可以大幅降低。


有了一体化的产品架构,OceanBase 4.2.1 LTS 进一步加强了一体化的产品能力,包括混合负载和多模态能力。该版本还支持 Auto DOP 自动设置并行度 SPM SQL 执行计划管理,支持 KV 和 Json,并将 LOB 上限提升到了 512 MB。该版本的一体化 SQL 和事务能力实现了事务大小无限制,并支持全功能 DDL。


此外,该版本还提升了高可用能力,既能支持与传统单体数据库完全对标的主备库方式,也可以通过仲裁的方式,以接近两个副本的成本实现 RPO 等于零。工具能力方面,OceanBase 4.2.1 的 OMS 支持双向同步一键逃生,还内建企业级协同开发平台 ODC,以及支持全场景管控的 OCP,实现智能诊断自制服务的 OAS。当然,OceanBase 在一致性、安全性、合规认证等层面的传统优势在新版本中也得到了继续强化。在所有这些能力的支持下,企业就可以放心地将关键业务场景完整迁移到这个 LTS 版本上。


解决了 OLTP 场景的完整需求,OceanBase 的下一步就是补足 OLAP 的能力。本次发布会上,OceanBase 展示了列存实验室版本的性能预览,可以看到大宽表场景中其性能已经媲美 ClickHouse。预计明年 4 月发布的 4.3 版本就会包含新的列存支持,而明年 10 月发布的 4.4 版本则会引入备受关注的存算分离能力。


纵观 OceanBase 4.2.1 LTS 的特性与未来版本的更新计划,可以发现 OceanBase 的发展理念就是稳扎稳打,一步一个脚印,每一次更新做好几项改进,目标一直都是为用户带来功能覆盖更加全面、更加稳定、可用的数据库产品。无论如何,这一次发布的 LTS 版本是 OceanBase 数据库一体化长期目标的关键里程碑,也意味着面对数据库选型犹疑不决的企业、技术领导层终于可以下定决心,对一体化技术栈 All in。

一体化数据库的未来:并非全能,却可位居主流


目前,OceanBase 已经展示了一体化产品战略的雄心和成果,让更多企业有信心选择一体化的技术路线。客观来讲,对于很多业务长期非常稳定,数据库团队对现有技术足够熟悉,缺乏扩张、转型业务需求的企业来说,将已有的技术栈替换为一体化架构并没有特别迫切的需要。但如果这些企业开始向变化激烈的新市场涉足时,选择一体化路线无疑是更优的方案。


我们从 OceanBase 的发展历程也能作出一项判断,那就是 OceanBase 未来覆盖的场景需求必然会越来越广,能力也会越来越强。虽然一体化数据库或许不可能做到一种产品应对所有挑战,但也足以成为未来行业的主流技术形态。相比之下,专用数据库则会在特定领域继续发光发热,凭借自身的独有优势维持市场地位。


正如 OceanBase 在发布会现场所说的,好比手机解决了大部分的问题,但是还是会有人买专业的游戏机。

分久必合,合久必分,直到 IT 行业下一次大规模技术变革来临,我们或许又能看到数据库市场迎来新的变局。无论如何,技术的进化迭代都是为了适应业务的需求,不同技术路线的竞争最终都会造福用户,成为推动技术进步的动力。

2023-11-20 14:007765

评论

发布
暂无评论
发现更多内容

java工程师培训机构哪里好

小谷哥

线下培训机构哪个比较靠谱?

小谷哥

【Go实现】实践GoF的23种设计模式:访问者模式

元闰子

Go 设计模式 访问者模式

【Nacos源码之配置管理 三】TaskManager 任务管理的使用

石臻臻的杂货铺

nacos 10月月更

你的方案逻辑自洽吗?

老张

测试方案 思维逻辑

GitHub上的宝藏级SpringBoot核心文档,拿走不谢!

Geek_0c76c3

Java 数据库 开源 程序员 开发

二本Java菜鸟9面字节遭虐,苦修数月深造这份 Java面试宝典,终进阿里

程序知音

Java java面试 程序员面试 后端技术 Java面试八股文

浅谈中小企业如何正确选择网络营销模式

石头IT视角

如何在 Goerli 网络中获取测试 ETH

devpoint

以太坊 Goerli 测试网络

React源码分析3-render阶段(穿插scheduler和reconciler)

goClient1992

React

Redis--Redis持久化方式

Java学术趴

10月月更

clickhouse准实时数仓能力探索

水滴

实时数仓 OLAP 数仓 10月月更 clickhosue

极客时间架构训练营模块二作业

李晨

架构

书单推荐|书籍是人类的良师益友

图灵社区

书单 教师节

阿里P8面试官总结的《2022最新java面试题》,搞定90%以上的技术面

程序知音

Java 程序员面试 后端技术 Java面试题 Java面试八股文

web前端开发培训机构比较好的是哪家

小谷哥

RecSysOps: 大规模推荐系统运维最佳实践

俞凡

架构 最佳实践 netflix 大厂实践

React源码分析2-深入理解fiber

goClient1992

React

web前端开发培训机构哪个好

小谷哥

React源码分析4-深度理解diff算法

goClient1992

React

Redis--Redis事务及错误处理方式

Java学术趴

10月月更

书单推荐|书籍是人类的良师益友

图灵教育

书单 教师节

验证二叉搜索树

掘金安东尼

算法 10月月更

Vue项目处理错误上报如此简单

茶无味的一天

Vue 异常捕获

【Nacos源码之配置管理 四】DumpService如何将配置文件全部Dump到磁盘中

石臻臻的杂货铺

nacos 10月月更

Python 3.12 目标:还可以更快!

Python猫

Python

为什么大家偏爱怪异盒模型border-box?

茶无味的一天

CSS 前端 HTML5, CSS3

前端培训机构应该怎么选

小谷哥

ESP32-C3 应用 篇(实例二、通过蓝牙将传感器数据发送给手机,手机端控制 SK6812 LED)

矜辰所致

蓝牙 ESP32-C3 10月月更

React源码分析1-jsx转换及React.createElement

goClient1992

React

吃透这份Java面试精选题解,我轻松拿到了字节跳动offer

Geek_0c76c3

Java 数据库 程序员 架构 开发

用一款数据库解决 80%的问题,OceanBase 的底气在哪?_数据库_郑思宇_InfoQ精选文章