X-DB到PolarDB-X:管中窥豹之阿里数据库的变迁
读到一篇阿里巴巴出品的不算太新的文章:阿里巴巴举办首届产业数据库研发论坛:链结产学院,构建创新生态圈。https://yq.aliyun.com/articles/653376 微信公众号无法外链,我把一些主要的内容贴一下。大家可以自行阅读全文。
这篇文章传达了不少信息。对于关注祖国数据库产业的人来说,很多都算旧文了。2017年是阿里巴巴数据库丰收之年。这一年,阿里云发布了PolarDB,一个兼容mySQL的云数据库:阿里云发布自研商用关系型数据库POLARDB。PolarDB组更是在数据库顶级会议VLDB2018上发表了工业界论文,介绍了PolarDB的核心技术PolarFS。
同年阿里巴巴集团也发布了X-DB:阿里自研分布式强一致关系型数据库——X-DB。X-DB组也在计算机研究与发展上发表了论文:X-DB:软硬一体的新型数据库系统。阿里巴巴内部两个历史悠久的数据库研发组织的两大数据库的发布,标志着阿里巴巴对数据库技术的掌控进入了新时代。
2018年,阿里巴巴正式任命了前犹他大学教授李飞飞博士为阿里巴巴集团副总裁,达摩院科学家,数据库与存储技术负责人。之后就有了李飞飞博士携旗下两大组织2017年发布的两大产品PolarDB和X-DB举办首届产业数据库研发论坛的事情。
达摩院的数据库与存储实验室更是兵强马壮,按照其官网,囊括了PolarDB的负责人曹伟,以前Azure Storage team,现在阿里存储负责人的Jason Wu,Facebook第一个入职中国人,曾高调入职阿里巴巴的赵海平,阿里集团OLAP产品负责人占超哲,以及研发了X-DB的阿里集团数据库的负责人张瑞一众数据库与存储的专家。
这篇文章也传达了一些有意思的新信息,比如说:PolarDB X(Powered by X-DB)。PolarDB X这个名字是阿里巴巴第一次在公开场合使用。后面括号里面的Powered by X-DB更是让这个名字显得非常的耀眼。
按照本文的信息PolarDB X是个数据库。我们已经知道X-DB是个数据库。那么一个数据库 powered by 另外一个数据库是什么意思呢?逻辑上讲不通。这些数据库研发负责人PhD们都受过良好的博士训练。对于博士来说,讲逻辑首先就是必要的条件。所以合理推测,我们只能认为PolarDB X和X-DB其实就是一个东西。但是如果就是一个东西的话,就没必要非得写的这么复杂了。
如果我们往2017年看一看的话,PolarDB这个品牌主要是阿里云在用,X-DB是阿里巴巴集团数据库的产品名字。大家都知道大公司赛马机制下,不同组做功能相似的东西,彼此之间肯定不会太愉快。比如说我曾经在的Cosmos组和微软Azure下面的HDInsight组。屁股决定脑袋的事情是必然的。
但是2018年,事情起了变化,如同当年Cosmos和HDInsight合并,同时汇报给一个大领导Raghu Ramakrishnan一样,PolarDB和X-DB同时汇报给了李飞飞。显然,在集团层面,已经选定了PolarDB作为以后OLTP数据库的品牌。但是X-DB的品牌拥有者,在这个选定的背景下,肯定会有缺失感。我拍脑袋猜一下,这个长名字就是上面的意图和团队之间妥协的产物。
缺失感可以理解,但这种妥协并不是什么好事情。Cosmos被合并的时候,整个团队包括我本人都经历过一种缺失感。上层也为了团队的稳定暂时做了妥协。但是事后最终还是上级的意志得到贯彻,不配合上级的团队成员或者主动或者被动的离开了团队。我曾经不止一次的回忆思考过那段历史。回头看,上级是组织请过来委以重任的,自然受到组织的各种力挺。任何和上级有矛盾的做法,都是得不偿失的。
可能更值得关注的是这些产品的技术栈之间会怎么样的演进合并。PolarDB的核心是替换了innodb的PolarFS。PolarDB X则构建在盘古文件系统上。加之达摩院数据库与存储技术组不但包括了数据库的人还有存储的人。一个问题是,PolarDB的文件系统PolarFS会被迁移到盘古2.0上吗?
从2018年的VLDB论文看,PolarFS作为一个分布式存储系统,其性能还是非常不错的。配合对mySQL的优化,基本上可以解决掉mySQL单库单表过小的问题。PolarDB的架构体现出了很强的实用性,尽管没有Aurora那么彻底的计算存储分离的设计,从云服务角度看,不失为一种不错的现实解决方案。
但是如果盘古2.0可以提供类似的posix接口,相近的性能,那么PolarFS也就没存在的必要了,毕竟,一个统一的存储层,对云厂商来说是更加有利的实施方案。这方面我们可以拭目以待。
PolarDB X构建在盘古文件系统上,上层的典型布局是两地三中心的架构,通过X-Paxos同步。其本地存储格式类似于RocksDB这样的LSM Tree。但是X-DB组创造性的使用FPGA进行compaction,从而保证了系统CPU占用率的稳定。
PolarDB X的这个架构,底层使用盘古文件系统是值得商榷的。盘古文件系统的三备份冗余架构,加上PolarDB X上层使用的两地三中心配置,一个简单的实现会导致每条记录被写了9份拷贝。这显然是无法承受的。当然,我拍着脑袋就能想出很多办法来减少冗余,我相信X-DB团队肯定做了很多工作去优化。
只是我一直都觉得盘古文件系统上面配置上两地三中心这种架构,多少有那么一点不搭。正是因为有了这种不搭,所以才需要额外的工作去处理和解决冗余过多的问题。这好像需要通过架构的改变才能比较好的解决。
2017年AWS Aurora团队在SIGMOD上发的关于Aurora的论文,我第一次读到的时候,就有很惊艳的感觉。这个架构确实很美,那种美感是很难用词语形容的。相反的,那篇获得了OSDI最佳论文的谷歌的Spanner论文,我第一次读的时候,感觉并不怎么样。连带的,我也对以追随Spanner为己任的项目,多少持一些怀疑态度。当然我知道这种言辞肯定会被很多人批死。OSDI钦定的最佳论文,岂是我这个小人物可以随便怀疑和鄙视的。
PolarDB的架构谈不非常惊艳,但是充满了实用感。PolarDB X的架构,架在盘古文件系统上,给我怎么都有一种冗余的别扭感。所以,阿里巴巴的数据库和存储现在都归于一个人领导,PolarFS,盘古文件系统,以及PolarDB和PolarDB X之间的整合,很值得期待。