暂无图片
暂无图片
1
暂无图片
暂无图片
暂无图片

深度解读OceanBase CTO杨传辉雄文:我们很牛逼!竞争对手们不行不行的!

飞总聊IT 2021-05-18
2744

最近好几个粉丝给我转了这篇发表在公众号OceanBase上的OceanBase CTO的雄文: OceanBase CTO 杨传辉: 下一代企业级分布式数据库的一体化设计 ,希望我能够帮忙解读一下。


这篇文章写的很有意思,值得深入解读一下。 特别是对比市面上的竞争对手们的架构解读,就更有意思了。


文章里面第一个观点是关于存储计算分离的看法。


业界有三种存储计算分离方案:


第一种本质是基于中间件分库分表,后端的数据库表示存储,中间件表示计算,这种方案是真正的存储计算分离吗? 显然不是,我也把这种方案叫做“伪存储计算分离”;


第二种把系统划分为 SQL、事务和分布式 KV 层,分布式 KV 表示存储,SQL 和事务表示计算,存储和计算采用松耦合设计,这种方案能够解决可扩展的 SQL 处理问题,但每次操作都涉及到计算和存储之间的远程访问,且事务相关元数据存储到分布式 KV 表格中,增加了事务处理的额外开销,牺牲了性能;


第三种采用紧耦合设计,SQL、事务和 KV 表示计算,KV 层数据块依赖的分布式文件系统表示存储。 这种方案来自于经典数据库的 IOE 架构,SQL、事务和 KV 层表示计算,底层依赖 EMC 的 SAN 存储。 Amazon Aurora 借鉴了经典数据库的存储计算分离架构,并在云原生环境下发扬光大,成为最终的事实标准。


为了追求极致性能, 我认为,企业级分布式数据库应该向经典数据库学习原生存储计算分离技术 ,我推荐第三种方案。


第二种最经典的代表是开源的TiDB数据库。下面是开源的TiKV,上面是SQL层,存储用KV,这样一来scale out的解决方案就会很方便。同样经典的就是TiDB模仿的对象,谷歌的Spanner,下面用的是BigTable上面再构建起Spanner层。


这种做法最大的好处就是scale out做起来很好。最大的坏处,就是单节点性能不行。客户是不是愿意牺牲单节点性能,从而获得更好的scale out,我想这个问题见仁见智。每个人可能会有不同的观点。


OceanBase CTO杨传辉是不赞同这种方式的,他觉得类似Aurora这样的计算存储分离才是应该追求的目标。OceanBase显然是冲着这条路去的。


但是最开始的Aurora版,底下是一个大磁盘,上面是计算层。这个大磁盘同时具备了Log merge的能力,这样的做法性能是不是可以做到单节点极致其实也存疑。


至于阿里巴巴另外一个数据库PolarDB,下面一个大磁盘接上单机MySQL,根本就没办法谈Scale out的事情了。PolarDB-X倒是更可能Scale out。但是早年的PolarDB-X上面三节点备份,下面文件系统再做三备份,一个记录写9份的骚操作,我没有在第二个数据库里见过。至于现在PolarDB-X演化的怎么样了,我也不好判断。


OceanBase实际上怎么做的,技术细节也没有公布出来,所以我也很难下一个结论说,OceanBase的实际实现,能够同时满足单节点性能最优和很好的Scale out能力。这两者本身就是需要互相妥协的。做好了,需要极高的工程能力。


下面是OceanBase CTO关于Paxos和Raft的看法:


Raft 协议是 Paxos 协议的一种简化,原理是在 Paxos 协议基础上增加了一个限制,要求按顺序投票,也就意味着数据库 redo 日志顺序同步。Raft 协议的好处是实现简单,但每个分区只能顺序同步,并发同步性能较差,在弱网环境下事务卡顿现象概率较高;Paxos 协议支持乱序同步,虽然实现更加复杂,但并发同步性能好,在弱网环境下事务卡顿现象概率较低。Raft 类系统发明了一个概念叫:Multi-Raft,指的是每个分片运行一个 Raft 协议。这个概念和经典的 Multi-Paxos 是不对等的,Multi-Paxos 指的是一个分片内做并发,Multi-Raft 指的是多个分片之间做并发,如果单个分片写入量很大,仍然是会产生性能瓶颈的。


Paxos 和 Raft 两种协议都是合理的做法,我个人建议采用并发性能更高的原生 Paxos 协议,这也是顶尖互联网公司在大规模分布式存储系统的主流做法,包括 Google  Spanner,Microsoft Azure,Amazon  DynamoDB,OceanBase 等等。


简单总结, Raft不如Paxos,因为并发性能高。顶尖互联网公司都用Paxos。这也很有意思。


我们知道目前有两个数据库产品用了Raft,一个是阿里云的PolarDB。它用了自己改进的Paralle Raft协议。另外一个是TiDB。其他的数据库产品,尤其是顶尖互联网公司的,我知道的都是Paxos协议。


这当然有历史原因,Raft出来的比较晚。但是也有现实的原因,Paxos协议的实现有很多很难的地方,一不小心就栽坑。我自己亲自经历的就看到过几个大Bug,导致数据丢失,都是Paxos协议实现细节上不对导致的。要实现一个好的Raft,估计难度上相对容易一些。这当然也会成为某些项目的选择。


有关HTAP的观点如下:


HTAP 也是分布式数据库领域的一个热门概念。有两种做法:


第一种是主备库物理隔离,主库做 OLTP,备库做 OLAP,主备之间通过 redo 日志做同步,备库与主库之间有一定的延迟。第二种是在同一套引擎实现 OLTP 和 OLAP 混合负载,区分 OLTP 和 OLAP 请求所在的资源组,对资源组进行逻辑隔离。


第一种方案实现相对简单,但由于产生了更多数据冗余,性价比较低;第二种方案实现相对复杂,但采用一体化设计,性价比更高。第二种方案来自经典数据库,例如 Oracle、SQL Server。


我认为,企业级分布式数据库应该学习 HTAP 技术,采用第二种方案。


HTAP就是一套数据库同时做两件事情,同时做TP和AP。这当然并不是什么新概念。在早先版本的TiDB里面,Raft增加了单纯的listener,作为备库,备库是列式的存储。有别于基于KV的OLTP workload的存储。 


TiDB的AP引擎是魔改ClickHouse得来的。主要利用列存进行AP处理。但是也可以在有必要的时候从行存中读取。总体来说,还是两套引擎。TiDB 5.0版本,据说引入了类似GreenPlum的MPP架构,使得其对OLAP的处理更上一层楼。


当然总的来说,我还是不太清楚现在两套引擎各自为政,还是说已经开始融合了。但是不管怎么样,融合MySQL和ClickHouse这种事情,我这点Engineer水平是不敢去随波尝试的。


PolarDB本身的AP能力很一般。PolarDB-X的最新版本,搞的有点像GreenPlum那样的MPP架构,但是从已经知道的细节来看,我也无法分辨这OLTP/OLAP是一套引擎还是两套引擎。


OceanBase的理念和观点,在这篇文章里已经阐述的比较清楚了。但是我还是想等一篇公开发表在顶级会议上的论文,通过阅读论文可以让我有更好的理解和判断,现在OceanBase的架构到底怎么样。OceanBase CTO这篇技术雄文里面描述的东西是不是真的实现了,又是怎么样实现的。不然的话,我也不好判断,到底是不是真牛逼。

最后修改时间:2021-05-18 10:07:48
文章转载自飞总聊IT,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论