蚂蚁金服阳振坤:OceanBase如何跨越关系数据库的“死亡之谷”

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 蚂蚁金服高级研究员、OceanBase团队负责人阳振坤在北京交通大学计算机与信息技术学院举行的第71期CIT名师大讲堂学术报告中发表了题为《OceanBase:跨越关系数据库的死亡之谷》的主题演讲,介绍了OceanBase从创新到产品的飞跃式发展以及分享了互联网时代下技术和产品如何跨越“死亡之谷”的经验和心得。

小蚂蚁说:

2018年10月15日,北京交通大学计算机与信息技术学院第71期CIT名师大讲堂在第九教学楼中心报告厅举行。蚂蚁金服高级研究员、OceanBase团队负责人阳振坤在本次学术报告中发表了题为《OceanBase:跨越关系数据库的死亡之谷》的主题演讲。阳振坤向同学介绍了OceanBase从创新到产品的飞跃式发展,分享了互联网时代下技术和产品如何跨越“死亡之谷”的经验和心得。

相关阅读:迎双11十周年,OceanBase 2.0挑战新巅峰》、《厉害了,蚂蚁金服!创造了中国自己的数据库OceanBase》      


数据库:技术和市场的“死亡之谷”  

数据库在每个人的生活里无处不在,不管是通讯、交通、金融行业,抑或是每天大家都在接触的互联网,所有这些业务的背后都是数据库在支撑。

b429fd58a1439e59c30d7084a7ac9089381fda31

数据库经历了近半个世纪的发展,在理论上很成熟,在技术应用上也已经非常成熟了。但是数据库偏偏有一个特别高的门槛,原因是数据库有三条特别苛刻的要求:

  1. 事务须并发处理:数据库要支持事务,所有人都希望用最小的处理资源,做到最大价值的事情。所以事务持续要做大量的并发处理。

  2. 数据一条不能错:一个数据库如果数据错了,就永远没有机会了。对于使用者而言,如果你会错一条,你就有可能会错一千、一万条,这是没有公司愿意承担的风险。

  3. 服务片刻不能停:通讯系统、列车系统,甚至飞机航行系统的背后都是数据库在支撑,这些系统一旦启动,一分一秒都是不能终止的。

上面提到的这三条要求,任何两个其实都好满足。但是大家仔细想一想,这三个要求如果要同时满足,就会变得极其困难。

同时,数据库又是一个巨大的市场,对国家、对整个社会都非常重要。这就导致很多国家、很多企业都想做也正在做这件事,但是结果大家都做到了同一个思路上。后来者都成了先行者的模仿者,那么这个模仿的代价就会变得很大。

今天作为一个后来者,你再去做这么一套数据库系统的时候,就真的很难说清楚你与先行者相比有多大的优势。这也就造成了强者恒强、寡头垄断的局面,后来者很难居上。

数据库同样也有开源这条路径,比如大家都了解的MySQL。开源是免费的,对于很多对成本敏感的公司而言开源数据库成为了替代商业数据库的另一种选择。

那么在面对数据库的“死亡之谷”这样的困境下,为什么我们还去花这么多钱,投入这么多设备,花这么多年时间和人力再去做一个数据库,究竟它的意义在哪儿?它又能够产生多大的经济价值?

既然有了开源的数据库,阿里巴巴和蚂蚁金服还要做这么一个商业数据库产品,其实这里面是有本质原因的。很多人知道阿里巴巴今天已经全面去IOE:去掉了Oracle数据库、IBM小型机、 EMC存储。那么很多人就在想,能不能在其他的行业,在铁路、交通,电信、政府这些行业推而广之,全部完成去O的进程呢?这个答案是否定的。

因为像阿里巴巴发展的这一套系统是基于MySQL的开源数据库,跟商业数据库在功能和性能上其实是有很大差距的。阿里巴巴当时在用它的时候,有很多事情数据库是做不了的,那么这些做不了的事情当时就放在应用软件里做。所以阿里巴巴在数据库和应用软件上都投入了很大的技术力量。这套系统拿到外部业务去用是不能彻底解决问题的。本质上这套系统是服务于阿里巴巴的专用系统,而不是一个通用的系统。

那么有人会问,在我的企业里,如果真的想去掉IOE,该怎么办?你同样要投入两拨人,一拨人要去做数据库,针对你的企业的需求来做相应的修改;还有一拨人要去做应用系统。但是问题是并不是所有的企业都像阿里巴巴有这么多优秀的技术人员,这套东西其实很难去直接推广应用。

所以,从一开始我们做OceanBase的目标就是——我们不想只做一个专用的系统,要做就一定要做一个通用的系统。我们希望今后OceanBase能够服务于各行各业,再也不需要企业投入几十几百甚至几千个人去改造、去重新做一套业务系统。

OceanBase的机遇与创新

当时做OceanBase数据库一个最根本性的原因就是需求的变化。因为这么一套基础系统,如果背后没有需求的变化,从0到1自己做出来基本是不可能的。

2010年春夏之际,我来到了阿里巴巴。去了之后发现当时有两个因素影响了阿里巴巴关系数据库的应用。

一个因素是并发,数据库它是按照并发量来卖钱的。说直接点,就是按照处理器来卖钱。之所以要买这么多处理器就是因为业务有这么大的需求。那么传统的业务比如商场,一个商场就那么几个收银台,它是一个相对稳定而且比较小的并发量,大多数情况就是几十几百的并发量。

b1315bfe04ac07906a2f00371207c6e58ab6510d

随着互联网的高速发展,阿里巴巴天猫双11几乎完全改变了过去行业内相对稳定的并发量,突破了几百万人甚至是千万人的同时在线购买。这个并发量跟过去的传统业务场景相比是几个数量级的增长,按照这个数量级去买商业数据库,没有一家企业买得起。

还有一个因素,当时我们叫它建站,其实就是搭建一个数据库。过去建一个商场,建一个银行的分店,这个周期是非常长的,有足够的时间来规划IT业务系统。互联网业务是等不了的,就像当时OceanBase接的第一个业务给到我们的时间就是最多一个星期。现实是一个星期的时间根本连小型机的安装调试都完不成。

原来的模式已经完全无法支撑互联网快速发展的业务。所以这两个需求的变化,是催生我们自己来做数据库的很关键的因素。

OceanBase关键性的技术革新

当时我找了几个同事商量这个事情,我跟大家说,我们是天时地利人和都赶上,这件事情除非是被拍死掉,否则我们是肯定要把它做成的。这个过程真的非常艰辛,我们花了差不多五年的时间,才真正让OceanBase有了关键的应用。

过去做数据库的公司,不管是国内还是国外,大家都是为了做数据库而做数据库,那么最后结果就是所有做传统数据库的厂商,大家的方案都很像。

因为数据库有很成熟的理论和工程的方法,那么如果我们按照以往的原则做过去,结果肯定也是一样的。所以,其实我们走了另外一条路——做分布式。最早做这个东西可能都不叫数据库,它更像是一个分布式系统,但是支持了事务的特性。这条路后来被证明确实是具有特别大的价值和意义。

当时我们在做OceanBase的时候,首先确定了几件事情。第一件事就是我们要做分布式,因为我们的业务要建站,不做分布式靠大型机和小型机是不可能做得到的。

另外一件事是成本,什么东西最便宜,量最大最主流的东西最便宜,它就是PC服务器。小型机少则几十万,多则几百万,PC服务器顶多就是几千几万块的成本。

第三个要解决的就是可靠性问题。大家对数据库的期望是永不宕机,永远不出问题。可是PC服务器到处都有,性价比也非常好,但是不容忽视的是它的故障率高。普通PC服务器它远远达不到数据库所要求的年可靠性五个九的要求。对普通PC服务器而言,差的可能是两个或者三个数量级,所以我们得首先把这个问题解决掉。我们用的就是分布式的办法来解决。

我们运用的是分布式的一致性协议,直白一点就是一个多数派的选举和投票协议。同时,我们把修改的增量直接放在内存里,每次要查询的时候,把内存硬盘的数据做一个merge,那么每天在业务相对的低谷期,再把内存中的数据整理回硬盘去。

做到了这几件事情,这个系统就有了很好的性价比,我们的成本比传统的数据库至少低一个数量级,你只需要用普通的PC机,不需要用昂贵的硬件设施。同时,扩展能力会也变得很好。

OceanBase的第一个业务:淘宝收藏夹

理想看起来很美好,但是现实特别骨感。这个项目刚启动的时候,我们好不容易才找到了几个人,人手是严重不足的。另外一个更大的挑战是时间:在做OceanBase数据库之前,我去找我的老板,他说给你两年时间如果能把一个数据库做出来就可以。当时我心里想两年虽然对于做数据库来说时间确实太短,但是这两年对于那时候的我们而言已经足够支撑起最初的想法了。

技术最终还是需要通过业务落实下去,所以我找了一批业务方,花了很长时间跟对方沟通,最后终于有一个业务愿意用我们的数据库。当时他给我的时间期限是——两个星期

当时我就傻了,两个星期要做个数据库,这可怎么办?后来跟业务的同学反复讨论,最后他们同意说,你们先做个demo出来。于是我们就花了两个月吭哧吭哧的做了一个demo出来。他们看了以后觉得比较满意,后来这个事情就一直坚持做下去了。

最后,我记得是到了第八个月的时候,系统上线了。这个业务就是现在大家都在用的——淘宝收藏夹,这是OceanBase的第一个业务。如果没有这个业务,我们现在也活不下来。

0cd60ce1f0ba21b7d8a3a5c2fb11f18bedfd1464

那么这个业务到底有什么特殊的地方?每个人都用过淘宝收藏夹,每次你打开收藏夹的时候,数据库在背后其实做了很多事情:我们以单个商品为例,它需要到一个叫商品库的地方,逐条纪录核对,看看商品有没有下架,有没有参与促销,有没有参加其他的返点活动等等。

假如你收藏了100多件商品,它就要进去一条条的取出来看。本质上来讲,这就意味着一百多次的随机IO。那么当很多人同时来看的时候,其实一个IO就被放大了几百倍,这时候有多少个硬盘都不够用。

当时他们已经用了几十台服务器了,按照业务的预估,第二年他们要买400台机器,第三年的数量都不敢想象。当时我们想了一个办法——我们做了一个宽表,确切的讲应该称为物化视图

657f9dbe4c4a5c807dc4ce94532500e994db1d2b

首先我们把每个用户收藏的信息聚集起来,这样可以减少IO,然后把收藏的商品放在这个列表里。但是我们怎么避免去访问一百多次IO呢?我们的办法就是找到一个时间点,当时是设定在每天晚上凌晨两点。在这之前,我们就把这些信息全部merge到硬盘,然后从两点开始,我们把新的修改都放在内存里面。

6b2ef344c1bf1497744ce2e7227a94ef10decfee

所以每到两点的时候,我们把两点之前所有的信息都合到这张表里,那么这张表里的信息在两点整的时候是准确的,这时候我们不需要去访问商品库。两点之后的修改,包括商品库的修改是在内存里进行的,这时候如果要看这些商品有哪些修改,商品只需访问内存中的更新即可。

所以其实我们就是通过这样一个手段,把每次收藏夹的展示,由原来的一百多次IO变成了一次。我们一下子就把淘宝收藏夹业务的整个IO降下来了。当时OceanBase确实是帮助业务实际解决了他们的问题,使得业务能够更好的快速的发展。业务是一定要发展的,所以只有我们真正能够解决他们的问题,我们这些做基础系统做底层的人,才能活下去。

dc44c441bd2c83eb268857e4fd9bf155f3384a49

这是当时给淘宝收藏夹做的一个架构,中间是一个做修改的服务器,所有的修改都在这一台机器上进行。旁边的机器是基线数据,就是分片切片以后,放到周围这一圈进行。所以当时我们就用这个看上去很简陋的一个方案来真正解决了淘宝收藏夹的问题。

当时收藏夹用了这个方案之后,服务器的数量从原来预计的第二年要用几百台,最后其实只用了差不多二十几台服务器,就把整个问题解决掉了。

OceanBase 0.3-0.4版本:团队面临解散

从淘宝收藏夹项目之后,我们陆陆续续也做了不少项目,但是没有一个项目能像淘宝收藏夹这样对业务有明显的价值和贡献。

从那之后的整整两年,我们找不到对OceanBase数据库而言特别有价值的业务。那两年对于我们而言特别特别困难,甚至整个团队随时面临着解散。

3e6de713d3300b313e22f585ce9de3be8de0cc29

2012年底,公司把我们从淘宝调到支付宝,当时预估到支付宝在数据库方面所面对的挑战更大,后来证明确实如此。即使是这样,当时仍然还处在一个非常困难的时期。到了支付宝一年多的时间,我们仍然很难找到新的业务,或者说价值比较大的业务来证明我们的价值。

OceanBase 0.5版本:成功抗住10%流量

2013年的夏天,支付宝希望全面去掉IOE——去掉IBM的小型机,Oracle的数据库和EMC的存储。当时面临了一个问题,就是去掉之后是可以用MySQL来代替Oracle,但是MySQL的主备镜像其实是做不到主备完全一致的。

这个时候我们意识到:OceanBase的机会来了。因为我们可以通过分布式的选举跟投票来做,哪怕硬件本身不可靠,我们也能保证数据的不丢失。传统数据库本质上是借助硬件的可靠性,也就是硬件需要达到五个九的可靠性来实现高可用的。就算出了故障,它的数据也能救得回来。但是这种手段需要非常高的成本,同时没有足够的扩展能力。

银行虽然有很高的可用性,但是它的高可用性是用很高的硬件成本换来的。我们建议一定要淘汰这些高可靠的硬件,因为他们的成本实在太高了。一旦真的使用了高性能,高性价比的PC服务器,那么你就不可能再花那么多钱去买高端的硬件。

所以我当时心里很明白,如果这件事情我们做不成,这个项目就只有死路一条。

64b7eb3c1fe1c934a9d8feefed28e6a6e163238f

那么,OceanBase到底如何做到主备完全一致的呢?理论上我们也没有办法说完全做到主库备库的一致。我们用了另外一个办法:主库还是主库,还是需要它快速的做事务,但同时主库还要把事务的日志同步给至少两个备库。两个备库中至少有一个收到了,那么加上它自己就超过了半数,或者我们叫多数派。当多数的节点收到了这个事务,并且把它持久化到硬盘了,我们就认为这个事务是成功的。

所以这时候任何一台机器坏掉,每笔事务在剩下两台机器里面至少一台存在。所以说即使主库突然坏掉,另外两台机器经过握手,它们再选举出一个新的主库,那么肯定可以继续工作下去,同时可以保证数据是没有损失的。

2014年的时候,我们在会议室里讨论支付宝交易库的上线,当时吵得面红耳赤,争论了很久别人就是不愿意上OB。他们原来的交易、支付系统全都在Oracle上,当时的Oracle无论是在稳定性、可靠性还是性能方面,肯定比OceanBase要好得多。所以没有人愿意用。

最后,在鲁肃的力挺下决定切给 OceanBase 1%的流量试试。因为那几年业务发展的太快,当时Oracle的共享存储已经扛不住这个流量,按照当时的业务流量去做压测的时候,几分钟就要坏一块盘。最后发现,把业务切掉10%,才能勉强扛得住。所以那一年的双11就把10%的流量切到了OceanBase。OceanBase也成功扛过去了那一年的双11。

OceanBase 1.0版本:唯一支持分布式事务的商业数据库

但是其实在0.5这个版本上线的时候,我们心里非常清楚,这个版本是临时的。我们当时选择做多数派协议的时候,还是用了原来的想法,每个集群还是中间有一个中心节点。这个事情一定不会是长久持续下去的,我们知道这个一定会遇到问题。所以当时其实交易库还没有完全上线,我们就已经启动了1.0版本的开发。

2014年到2016年,整整两年的时间,我们投入了40多个人,全部投在OceanBase 1.0版本的开发上。整整两年,这40多个人没干任何别的事情。所有的线上问题,版本修改、升级都是我们调出来的五个同学全部扛下来的。

有人会问什么样的因素让这么多人做了两年才能把这个版本做出来?这个版本里面我们主要做的一件事就是分布式。

如果你问分布式事务有这么难吗?我可以自豪的回答你:今天的商业数据库里有且只有一个是能够支持分布式事务的,它就是OceanBase。

OceanBase通过分布式的一致性协议做到了系统的高可用性,就是说哪怕我们今天用的是比较廉价的,可靠性比较低的PC服务器,但是我们的可用性其实会变得更高。因为单机的故障我们完全能够自动的容忍掉,而且我们做到了现在的数据做不到的一件事情——哪怕主库出故障,我们能够保证数据没有任何损失。

今天的银行每年国家都要求他们至少做一次消防演习,银行要到最前端的网关把交易纪录捞出来核对,把这些账对平了,备库才能继续服务。我们今天根本没有这个问题,主库出故障了,也就是几十秒以后,新的主库就会被选出来。因为只要剩下的机器超过半数,他们互相之间会通过握手把数据补齐,很快就能工作。其实这30秒大部分还是消耗在确定主库是否真的有故障。

所以,我们用不可靠的硬件反而做到了更高的可用性,而且做到了数据真正的一致。

传统的数据库因为涉及到共享存储,共享存储是一个单一的设备,你只能放在一个机房。所以一旦那个机房出现了故障,你就只能靠备库容灾把系统恢复起来。

OceanBase通过“三地五中心”部署实现城市级故障自动无损容灾。比方说相当于你一共写了五份日志,放在三个不同的城市里。任何一个城市哪怕出故障,比方说杭州断网了,那么剩下的依然超过半数,这个系统还是可以恢复工作的。这也是原来的传统数据库,不管想什么办法,都做不到的事情。

752fe820c364d76effabfd0c2d4907373bc2fa9d

前段时间,大家可能也看到了云栖大会的新闻。蚂蚁金服副CTO胡喜在ATEC主论坛现场模拟挖断支付宝近一半服务器的光缆。结果只过了26秒,模拟环境中的支付宝就完全恢复了正常。而这场26秒自断服务器现场演示的技术核心其实正是基于OceanBase的三地五中心架构方案

2017年,天猫双11中蚂蚁金服的全部核心系统,包括很多业务系统都放在了OceanBase上。去年我们创造了25.6万笔/秒支付峰值的世界纪录,这下面还有一个数据,就是说我们为了要执行这25.6万笔的支付,执行了4200万条SQL

新的历史机遇:走出去

所以从今天来看,OceanBase在过去的历史进程中面临了一个个新的机遇,无论是处理器、操作系统还是数据库,这些都是非常大的挑战。

从2016年底,我们就开始做准备,OceanBase一定要走出去。从我们成立的第一天起,团队里的每个成员的目标都是一致的:我们不是想做一个数据库只是给自己用,我们要做一个数据库真的去推动整个社会的进步,能够让整个社会的生产力发生变化。

所以,2017年我们正式开始服务于外部,最早的两家客户是浙商银行南京银行,我们现在的客户要多很多。从内部的应用到真正走出去服务于外部,真的是一个很大的挑战,是一件很困难的事情。

4e23c0739304043c696273f4e435463cc4b476ee

回想这八年多来,OceanBase走过的路:开始的头两三年,我们真的每天都在挣扎,每分每秒都在想着怎么能让自己活下来。到了2013、2014年,我们终于找到了一个真正的立足点,就是支付宝的交易库。然后我们接着花了整整两年的时间,真正在OceanBase 1.0 版本把分布式做出来。在接下来的一到两年时间里,我们把支付宝的核心业务全部搬到OceanBase上。

关系数据库确实是个门槛很高的东西,但是凡事有利有弊。门槛高意味着我们进来很难,别人进来一样难。我们集中精力在做事务处理这一块,它的门槛是很高,很不容易进去,但我们恰恰有这个机会能进去。我们费了很大的力气跨进来了,别人可能费了全部力气也进不来。

现在回想起来,能够把最早的一些想法一些创新变成产品,真的是非常辛苦或者说非常痛苦的一条道路。但是我们做的所有事情其实还是从业务、从客户中出发,只有技术真的能够落到生产中去,落到用户中去才是真正有价值的,否则你做得再好也是一个空中楼阁。

到了今天,当我们走出阿里巴巴,走出蚂蚁金服再来看,发现当你做的事情能够提供十倍性价比的时候,其实真的有机会去颠覆一个产业,重新塑造一个行业。

OceanBase TechTalk · 北京站

10月27日(本周六),OceanBase TechTalk 第二期线下技术交流活动将在北京启动。

届时,OceanBase三大重量级嘉宾:陈萌萌(酒满)、韩富晟(颜然)、乔国治(鸷腾)将跟大家一起聊聊支撑了今年天猫双11的 OceanBase 2.0版本的产品新特性和重大的技术革新。北京中关村,我们不见不散!

960818d202aa474dfed65438531027cb3cd3c004


— END —



相关实践学习
体验RDS通用云盘核心能力
本次实验任务是创建一个云数据库RDS MySQL(通用云盘),并通过云服务器ECS对RDS MySQL实例进行压测,体验IO加速和IO突发带来的性能提升;并通过DMS执行DDL,将数据归档到OSS,再结合云盘缩容,体验数据归档带来的成本优势。
相关文章
|
4月前
|
存储 SQL 分布式数据库
OceanBase 入门:分布式数据库的基础概念
【8月更文第31天】在当今的大数据时代,随着业务规模的不断扩大,传统的单机数据库已经难以满足高并发、大数据量的应用需求。分布式数据库应运而生,成为解决这一问题的有效方案之一。本文将介绍一款由阿里巴巴集团自主研发的分布式数据库——OceanBase,并通过一些基础概念和实际代码示例来帮助读者理解其工作原理。
346 0
|
2月前
|
SQL 存储 人工智能
OceanBase CTO杨传辉谈AI时代下数据库技术的创新演进路径!
在「DATA+AI」见解论坛上,OceanBase CTO杨传辉先生分享了AI与数据库技术融合的最新进展。他探讨了AI如何助力数据库技术演进,并介绍了OceanBase一体化数据库的创新。OceanBase通过单机分布式一体化架构,实现了从小规模到大规模的无缝扩展,具备高可用性和高效的数据处理能力。此外,OceanBase还实现了交易处理、分析和AI的一体化,大幅提升了系统的灵活性和性能。杨传辉强调,OceanBase的目标是成为一套能满足80%工作负载需求的系统,推动AI技术在各行各业的广泛应用。关注我们,深入了解AI与大数据的未来!
|
4月前
|
Oracle 架构师 分布式数据库
OceanBase数据库的发展历程是什么?
【8月更文挑战第11天】OceanBase数据库的发展历程是什么?
183 63
|
4月前
|
Oracle 关系型数据库 MySQL
OceanBase 与传统数据库的对比
【8月更文第31天】随着云计算和大数据技术的发展,分布式数据库因其高扩展性、高可用性和高性能而逐渐成为企业和开发者关注的焦点。在众多分布式数据库解决方案中,OceanBase作为一个由阿里巴巴集团自主研发的分布式数据库系统,以其独特的架构设计和卓越的性能表现脱颖而出。本文将深入探讨OceanBase与其他常见关系型数据库管理系统(如MySQL、Oracle)之间的关键差异,并通过具体的代码示例来展示这些差异。
318 1
|
4月前
|
关系型数据库 OLAP 分布式数据库
揭秘Polardb与OceanBase:从OLTP到OLAP,你的业务选对数据库了吗?热点技术对比,激发你的选择好奇心!
【8月更文挑战第22天】在数据库领域,阿里巴巴的Polardb与OceanBase各具特色。Polardb采用共享存储架构,分离计算与存储,适配高并发OLTP场景,如电商交易;OceanBase利用灵活的分布式架构,优化数据分布与处理,擅长OLAP分析及大规模数据管理。选择时需考量业务特性——Polardb适合事务密集型应用,而OceanBase则为数据分析提供强大支持。
1126 2
|
4月前
|
存储 SQL 数据库
OceanBase数据库的分区策略
【8月更文挑战第13天】OceanBase数据库的分区策略
224 5
|
4月前
|
SQL 存储 数据库
OceanBase数据库优化
【8月更文挑战第14天】OceanBase数据库优化
147 2
|
4月前
|
存储 SQL 算法
【OceanBase】惊天大反转!启动时真的会占用95%磁盘空间?别怕!揭秘真相+实用调整技巧,手把手教你如何优雅地管理磁盘空间,让你的数据库从此告别“吃土”模式!
【8月更文挑战第15天】OceanBase是一款高性能分布式数据库,启动时并不会默认占用95%磁盘空间,这是一种误解。其设计注重资源管理,可根据业务需求动态调整空间使用。通过设置`max_disk_usage`等参数、优化表设计、定期清理数据及启用压缩等功能,可有效控制磁盘占用,确保高效利用存储资源。
94 1
|
4月前
|
SQL DataWorks 关系型数据库
DataWorks操作报错合集之如何处理在DI节点同步到OceanBase数据库时,出现SQLException: Not supported feature or function
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
|
4月前
|
运维 监控 数据库
在OceanBase数据库中,obd集群版本需在线升级4.3.1.0升级至4.3.2
【8月更文挑战第14天】在OceanBase数据库中,obd集群版本需在线升级4.3.1.0升级至4.3.2
88 0

热门文章

最新文章