❝开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,可以解决你的问题。加群请联系 liuaustin3 ,(共3000人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9)(1 2 3 4 5 6 7群均已爆满,开8群350+ 9群 100+)
刚刚参加完OceanBase的开发者大会,让我感受到了什么是冲上云霄。
会开完了,人要回归现实,飞机要着陆,数据库要实现价值,怎么实现。这次大会下的什么棋,出的什么招。期间发布大会中OceanBase对接的云共享存储部分,特别的吸引我。每个人的关注点不同,我走云一脉。上云的企业越来越多。一个数据库厂商如果要扩大自己的攻城略地的速度,占领更大的市场,制造让友商不能逾越的雷池,云是一个非常好的划分第一梯队和第二梯队能力分割线。
国产数据库这么多年,线下市场竞争激烈,各种国产数据库技术的发展和利用已经到了一个平台期,看问题看本质。为什么OceanBase在2025年针对云的对象存储这个维度进行了功能的添加,值得深思。在论述前我们先说需求,再说技术,不说需求,谈技术当下已经无法满足聪明的客户的看客。最后针对共享存储技术,个人斗胆猜测OceanBase这样做的目的,直击本质。
一、理清需求与传统数据库上云障碍:
在我上一篇关于OceanBase开发者大会的内容中,强调过,在大会小剧场上去演讲的内容,数据库技术是被动的,数据库是最后获知需求的,相对于开发和架构,数据库技术发展是滞后的,这些年一些先进的数据库厂商已经意识到这个问题,业务匹配数据库成为选型的必选项。有需求才有客户。
1 云上客户变化
什么样的企业上云:上云的企业多种多样,大体可以从时间维度和行业的维度来分析,在2010年前大部分上云企业多为中小型企业,基于自身的技术能力和差异,无法在基础架构上有所建树,不得不使用云技术来弥补自己的短板,随着新一代的IT高层领导的更新换代和经济形势的突变,2015年后上云的企业在针对云数据库上有了显著的变化。这些企业多为中大型的IT类企业,云上客户开始集中在以IT服务为中坚力量的企业,且渗透到各个行业中,如互金融企业,SaaS类型的企业,IT服务类企业等。
| 主要企业类型 | ||
| 上云主要动因 | ||
| 核心关注点 | ||
| 基础架构 | ||
| 成本 | ||
| 技术能力 | ||
| 业务敏捷性 | ||
| 数据安全合规 | ||
| 管理与治理 | ||
| 生态与集成 |
随着时间的推进,企业对于云上数据库的要求在逐步变化,以开源数据库产品为代表的RDS完全胜任的工作,现阶段这些产品开始面对客户各种新颖的需求,表现开始乏力,无法满足现中大型企业对数据库功能使用需求。企业急迫的需要对接线下商业数据库媲美的产品在云上使用。
单纯的MySQL、PostgreSQL类的数据库已经不能满足大中型线下商用数据库客户对上云后的高要求。
数据库厂商的问题:
数据库厂商此时并未跟上时代的需求,在上云客户需求产生后,线下业务为主的数据库厂商还玩线下的产品,云上厂商则如诸侯割据,互不通融!
客户需求有了,可以单机部署,分布式部署,云下部署,云上部署,公有云可购买,有开源产品和服务,且成熟数据库产品,我想不出第二个。(注意成熟二字)
这里数据库厂商们像一个个围棋选手,有的是看一步,下一步,有的是下一步看10步。所以我捕捉到OceanBase的共享存储在此次大会发布的目的和根因。
凭着4年云上数据库产品的经验,我非常明白这是传统数据库上云这一局中关键的一步,按照武功来说,算是要打通任督二脉,开始要筑基了。
我稍微解释一下,普通线下数据库厂商不理解的云存储的问题。云上的存储主要有以下几点需要注意。
1 云厂商独有的云存储技术:比如我经常用到的 PLS4 PLS5,以及ESSD1 ,ESSD 2, ESSD3,本地盘,云盘。这些是云上数据库的性能的秘籍之一,这些也是数据库成本和性能的关键之一。
2 高级的存储是不会开放给ECS主机的,ECS主机所使用的磁盘无法对比如PolarDB使用的 PLS4 PLS5等高级存储系统的功能和特性。
有了这两点的把持,一个传统数据库要在云上站稳脚跟比登天还难,这也是大部分传统数据库厂商上云的难点之一。
一个传统数据库产品跨越两个不同云的存储设备,最后给客户展现了两种截然不同的数据库产品的性能,客户会答应吗?
而云上最稳定的,且公开性能和价格及成本的IO系统就是对象存储,上有AWS的S3,下有阿里云的OSS。我上周刚用过阿里云的OSS产品(今天就不介绍OSS),上传数据最快可以达到每秒225MB/S,而每GB的存储成本只有几分钱。此时此刻我说的够多的了,聪明的人下面的文字应该不用看了。

和云数据库,云原生数据库打交道4年了,对于云上的技术,我有一定的了解且也是深度的使用者。用OceanBase 此次大会上OceanBase共享存储:架构创新与核心优势的这部分的PPT中的一个动图来解释,创新和核心的优势。

1 类似技术与纯云原生数据库产品上的技术很相似。
2 传统数据库厂商将利用云上的共享存储设施作为自己稳定的存储系统的基座。
这打破了我曾经的一个认知,线下业务为主的数据库厂商玩不懂云上的技术,云上产品的硬件和线下硬件的形成和概念完全不同。云上技术重要的特点之一是存算分离,计算单元和存储单元分离,线下业务为主的数据库厂商很少能搞明白什么是这些东西,他们日常的客户和需求也不需要他们懂这些,单机,一体机,那些铁壳子的服务器是他们的发力点。
而在OceanBase 2025开发者大会,我看到线下业务为主的数据库厂商已经做出了坚定和云技术靠近的态势拿出了类似的技术。 我们来看看OceanBase都做了什么。
第一张图曾在某云的云原生数据库产品的技术架构看到类似的,虽然使用场景略有不同。
第二张图是云原生数据库产品中共享存储架构的优势和特性


可以用六个字来表述,弹性性能成本。这六个字是有顺序的,上云的数据库产品要有弹性,云上的关系型数据库没有弹性,就如同判了死刑。业务高峰弹出资源,业务低谷期撤回资源,业务高峰保证性能,业务低峰时最小化成本。云上的客户是很精明的,会想尽方法利用合法的手段,榨取云厂商的各种技术福利,来体现选择这些技术的人在企业中的“价值”。
在听完共享存储后,我的出了一个结论,OB 作为过去以线下业务为主的数据库厂商,上云并不是作秀,而是真实在技术上贴近云上的特点,利用云上对象存储进行了有效的存算分离技术的落地和实现,克服了传统数据库厂商,在云技术上的肌无力,从这个面可以看到,OceanBase开始利用此技术,去开辟云数据库这个第二个战场的远谋,并在一步步搭建自己的城池。
注:以上为个人观点,与任何组织机构无关。

置顶
删除数据“八扇屏” 之 锦门英豪 --我去-BigData!
写了3750万字的我,在2000字的OB白皮书上了一课--记 《OceanBase 社区版在泛互场景的应用案例研究》
疯狂老DBA 和 年轻“网红” 程序员 --火星撞地球-- 谁也不是怂货
和架构师沟通那种“一坨”的系统,推荐只能是OceanBase,Why ?
跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)
跟我学OceanBase4.0 --阅读白皮书 (4.0优化的核心点是什么)
跟我学OceanBase4.0 --阅读白皮书 (0.5-4.0的架构与之前架构特点)
跟我学OceanBase4.0 --阅读白皮书 (旧的概念害死人呀,更新知识和理念)
MongoDB 相关文章
MongoDB “升级项目” 大型连续剧(4)-- 与开发和架构沟通与扫尾
MongoDB “升级项目” 大型连续剧(3)-- 自动校对代码与注意事项
MongoDB “升级项目” 大型连续剧(2)-- 到底谁是"der"
MongoDB “升级项目” 大型连续剧(1)-- 可“生”可不升
MongoDB 大俗大雅,上来问分片真三俗 -- 4 分什么分
MongoDB 大俗大雅,高端知识讲“庸俗” --3 奇葩数据更新方法
MongoDB 大俗大雅,高端的知识讲“通俗” -- 2 嵌套和引用
MongoDB 大俗大雅,高端的知识讲“低俗” -- 1 什么叫多模
MongoDB 合作考试报销活动 贴附属,MongoDB基础知识速通
MongoDB 使用网上妙招,直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!
POLARDB 添加字段 “卡” 住---这锅Polar不背
PolarDB 版本差异分析--外人不知道的秘密(谁是绵羊,谁是怪兽)
PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤,来自杭州的Package(活动结束了)
PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火
PostgreSQL 无服务 Neon and Aurora 新技术下的新经济模式 (翻译)
“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!
全世界都在“搞” PostgreSQL ,从Oracle 得到一个“馊主意”开始
PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁
PostgreSQL “我怎么就连个数据库都不会建?” --- 你还真不会!
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
PostgreSQL 分组查询可以不进行全表扫描吗?速度提高上千倍?
POSTGRESQL --Austindatabaes 历年文章整理
PostgreSQL 查询语句开发写不好是必然,不是PG的锅
MySQL相关文章




