浅聊OceanBase

题外话1：周末就要去德国慕尼黑参加数据库领域的两大最顶级会议之一VLDB(Very Large Database)。今年我们公司是白金赞助商，会议期间比较忙。和去年一样今年如果有时间公众号会更新会场情况。不过因为今年预见到会更忙，所以公众号的更新频率上不好保证。

算起来从2007年第一次在这个国际大会上发表论文演讲，也10多个年头了。这些年来中国人在数据库领域的影响力是越来越大了。

题外话2：有段时间没写技术相关的文章了。主要还是数据库领域的技术其实就这么多，而技术类的文章写深了写专了，读者受众有限。写浅了，又会让另外的读者不满意。所以我也是懒了。今天趁着去参加数据库领域的最顶级会议之前，聊聊技术。

1

OceanBase是蚂蚁金服集团自己研发的的新一代关系型数据库。项目的领导者是阳振坤老师。OceanBase为蚂蚁集团的各方面包括双11提供了技术保障，是一个很牛逼的国产数据库。

我第一次听说的时候是2014年。那个时候宣传如火如荼。我知道这个数据库也是因为2014年杭州的数据库顶级会议VLDB。那个时候阿里巴巴举办了阿里之夜的活动。活动邀请了包括我在内的与会的国内外知名学者工程师去阿里巴巴集团总部，参观并了解阿里巴巴集团的各方面技术。到会的就包括了现在在蚂蚁金服首席数据科学家漆远博士。阿里云飞天系统首席架构师唐洪。还有OceanBase的项目领导人阳振坤老师。

我是从那个时候起开始关注OceanBase这个项目。OceanBae一度开源了。那个开源版本的源代码GitHub至今可以看到。但是后来这个开源项目并没有继续维护下去。而OceanBase的体系架构和代码系统据说在2015到2016年之间又有了长足的进步。OceanBase之后再次红火起来是去年底。到今年初。算得上是OceanBase1.0正式发布，作为云服务提供给大家。

2

传统意义上来讲，OceanBase是一个关系型数据库。它工作的主要领域是事务处理。对应到开源领域来说，最为恰当的对比应该是MySQL。比如说阿里巴巴在某些业务上就用和OceanBase功能类似的自己改造的MySQL版本AliSQL。就公开能看到的情况，OceanBase在整个阿里巴巴和蚂蚁金服的应用，比较多的是在金融领域。而AliSQL则在其他业务上用的多一些。

聊聊OceanBase这样的系统，对我来说是件相对比较困难的事情。这种困难主要来自两个方面。

一个是我自身水平和见识的问题。我自从事数据库的系统相关的研究和开发以来，虽然方方面面都有所涉及。但我的基础主要还是在在线分析方面。而我对事务处理的了解很多时候也只是作为一个做数据库系统的人应该必须了解的那个水平。谈不上专家。这就使得我通过阅读已有的文章介绍去对OceanBase进行判断的难度大一些。如果是在线分析系统的话，那么我多半更容易从只言片语中判断出技术实现的细节。

第二个方面则是目前我所能获得的信息的限制。这些年来我也在陆陆续续的阅读OceanBase相关的东西。知识的获取渠道非常有限。阳老师曾经在国内某大学学报上发表过一篇OceanBase的文章。然而因为我没有国内大学文献数据库的订阅，无法购买。网上也没有找到免费的版本，只能作罢。我也陆陆续续的看过一些不同国际会议上对OceanBase的介绍，但是看起来还是所知有限。对于OceanBase的更多的了解则是在国内各大网站包括知乎上面的文章，其中也包括了阳老师自己的文章。这些文章让我对OceanBase有了一些更深入的了解，然而我觉得知识的获取比较片面。 倘若OceanBase团队能够在Sigmod或者VLDB这两大数据库国际顶级会议之一发表一篇论文讲述一下他们的系统的话，我想无论是对OceanBase自身的影响力，还是对于像我这样的人去理解OceanBase都会更有帮助。

所以在我聊技术之前还得声明一句，我对这个系统的理解比较浅薄，错误之处难免。

3

OceanBase的架构作为一个数据库来说，很难说到底属于哪种类型。既不是传统意义上的数据库架构。拿来和Spanner比，也不太像。OceanBase的构成由ChunkServer，MergeServer，UpdateServer和RootServer构成。RootServer一般的布局是MergeServer和ChunkServer在一起，UpdateServer和RootServer在一起。

OceanBase最核心的思想是增量数据和基础数据分开。任何的更新操作都用UpdateServer来处理。ChunkServer则保留了基础数据。等到特定的时候MergeServer会把两者合并起来。而RootServer相当于是个入口，同时还承担了元数据和各种分区对应到具体的ChunkServer之间的对应关系的管理等等。

从数据库的实现来看，ChunkServer是个改良版的B+树。具体怎么改良我也不知道，但是从已经有的资料看是数据存储消耗空间大致上是普通B+树的50%。UpdateServer里面存所有的更新，用的是内存B+树。

从这一点上来说，这个实现方式和BigTable或者Spanner使用的LSM tree有类似之处。类似的地方主要是内容都是先写内存然后才会写到磁盘上去。这种体系结构对于写的throughput通常比较好。

不同的地方也很多。首先一点，在BigTable或者Spanner上，每个tablet都是自带本地LSM tree。写都先写进了内存，然后内存满了自动会写磁盘。之后一层层的合并也都是自动的。怎么合并其实是LSM tree性能很关键的一部分。作为谷歌开源的LevelDB，其内存的数据结构是个skiplist，并不是树。而Facebook维护的基于LevelDB的RocksDB里面对性能提高的一个改进就是什么时候合并的改进。

OceanBase的做法从这个角度上来说其实和LSM tree不一样。写内存有专门的UpdateServer，内存和基础数据的合并则通过MergeServer来实现。所以这个正如OceanBase队伍多次宣传的，这个系统实际上是Delta在UpdateServer上，Base在ChunkServer上。这个系统并不存在着类似BigTable或者Spanner那样的本地每个分区自己写内存，然后自己合并的能力。

4

UpdateServer作为一个单独并且是唯一负责写更新的服务，很显然会成为整个系统的瓶颈。瓶颈体现在两个方面，一个是能不能撑得住，第二个是挂掉以后怎么办。而OceanBase的队伍显然也是需要解决这个瓶颈的。

这个问题的解决有几个部分。有关这一块，我的理解也不是很全面，也许有不对的地方。

作为一个内存的B树，阳老师在知乎上有过一个大概的估计，基本上来说就是在淘宝双十一的时候的数据量，大概有1TB的更新，每台机器100GB内存的话，10台机器也就够了。机器的配置是要求很高的，但是10台机器也不是一个大坑。

早年的时候就只有一个地方可以写，显然稳定性就比较差了。国内一般流行两地三中心，所以OceanBase也是类似的结构。我们都知道分布式系统的一致性问题是分布式系统里面最核心的问题。而解决这个问题的任何解法都是Paxos协议或者Paxos协议的变种。这种三中心的结构，当更新在某个UpdateServer的时候，内容更新再内存里，但是redo-log的日志文件(也叫write-ahead log)内容则写入磁盘并且通过Paxos协议传播到其他两个中心去。Paxos协议保证了分布式一致性，从而使得任何一个服务节点下去的时候系统依然可以提供稳定的服务。

有关写操作的另外一个部分，是我比较困惑也可能理解得不对的。假设双十一需要1T数据，而每台机器100GB的话，那么这些机器是不是只有Master上面的UpdateServer才能接受更改而其他的是不可以的呢？从我的理解看早年的版本是，而最新的版本则不是。

因为OceanBase引入了分区的支持，我的理解是不同分区的写操作，可以发生在不同中心的UpdateServer上，但是相同分区的操作则不可以。此外，我注意到OceanBase的分区，不管是基于范围的分区还是基于哈希的分区，都支持。但是各种文档读下来，逻辑分区的边界应该是静态的，而物理存储则可以动态调整。有关分区是如何调整的，比如是不是支持类似于Spanner那样自动分裂分区的问题，我没有看到有文章仔细讨论。所以我姑且假设是静态逻辑分区。

5

OceanBase这个系统有一些比较先进的地方。比如说用了Paxos来在三个中心之间同步。代表了数据库系统发展的新方向。是很值得我们学习的。OceanBase的scabality不错，适合大吞吐量的环境。然而由于这个技术先天的实现问题，单个事物处理所需要的时间，通常会比更加轻量级的实现，比如说MySQL，要慢一些。也就是说，对于轻量级的服务来说，用OceanBase有点杀鸡用牛刀的感觉。可能这可以解释为什么在蚂蚁金服OceanBase用得比较多，而阿里巴巴集团的其他部分则是以MySQL的改良版为主。毕竟，金融服务有自己的特点，而后者成本应该更低。

这个系统对写优先，并且用专门的UpdateServer来做写的功能。这里面是有假设的。基本上的假设应该是应用场景里面和读操作相比，写的相对要少。我想支付宝里面很多应用场景是符合的。这种做法也使得事务处理的实现相对简单。

但是和BigTable或者Spanner的分布式读写的处理方式，这种做法可扩展性就比较差了。无论我们怎么样的去改进，都不可避免的说写是在单点上进行。当然我们可以通过分区来分散分区和分区的写操作，也可以用Paxos来实现三中心的稳定性。无论如何，单节点写入依然是这个系统比较大的一个瓶颈。

此外，我觉得OceanBase的另外一个问题在于这个系统的通用性。OceanBase代表了国内互联网企业开发软件的一个典型的模式：从解决特定问题特定场景开发开始。系统的存在首先需要解决特定的问题。这个开发模式无论和谷歌这样的互联网巨头相比，还是和国外企业级软件开发商相比，都是不太一样的。

到今天虽然OceanBase已经在努力从架构上解决很多的问题，我们依然可以看到当年为了解决特定应用场景而留下的痕迹。对于一个通用的数据库系统，使用单独的写服务器来应对新的更新，这不会是一个首选的解决方案。

OceanBase的通用性问题还体现在它的系统模型到底是什么？比如说它用的type system到底是什么？比较有意思的是，2014年的OceanBase宣传里面并没有提及对MySQL的兼容性问题。那个时候去IOE，能够替代Oracle的应用是重点。而现在他们则提出了OceanBase全面兼容MySQL，同时还增加了很多Oracle数据库的特性。这是一个很有意思的宣传。

我来解释一下大概可以这样理解，早年的支付宝是跑在Oracle上的。所以OceanBase作为一个在特定应用场景下取代Oracle的产品，它必须和Oracle在很多方面保持一致性。其中很基本的一点是数据类型的问题。举例来说，它的整型应该是Oracle的整型。不然很难兼容。那么这个系统这样一发展。后来不知道出于什么样的考虑，又在前端搭上了MySQL的前端。其实我也不知道是直接用了MySQL的Parser还是自己写了一套。但是不管怎么样，对于一个通用数据库来说，一套稳定的类型系统是非常重要和基础性的东西。我比较难以想象早年以兼容Oracle为目标，后来转向MySQL。现在是MySQL上面加入Oracle的特性。这个发展过程里面透露出来的东西给我的感觉就是这个项目从一开始，对一些非常基础性的东西，并没有一锤定音一般的做好决定。所以，我想最后的结果必然是MySQL不见得能兼容好，Oracle也不见得能取代好。我甚至完全不怀疑整个OceanBase因为系统类型函数等等基础性的东西到底要怎么做，三番两次必须推导重来。向后兼容性外加向MySQL的兼容性，不是那么好做的。

除了兼容性问题以外，就是OceanBase的优化器问题了。我在不同的文章里面看到过类似的言论：客户使用SQL不像阿里里面的人那么懂，知道怎么样可以写出高效的SQL来。所以在用OceanBase的时候就不能够最高效率的发挥出来。这种言论在我看来，是优化器不成熟的一个表现。一个成熟的优化器比如Oracle或者SQL Server的，应该可以很大程度上把用户写得语义上正确的SQL转化成为一个高效的执行方案。因为SQL存在的本质就是它是交代用户的意图而不是交代实现方式的。当然这个可以理解，因为OceanBase这个系统显然是从存储和事务处理先发展起来的。优化器本身估计在很长的时间内都不会是团队的重点。而这个地方其实水很深。

由此我们回头再去看OceanBase这样的一个架构，我想这个架构对特定的查询会很快，但是如果要让系统做一些OLAP的查询，我的感觉上来说，就会非常困难了。换一句更通俗的话去说，如果拿数据的时候，主键是存在的，都好办。如果没有主键，要拿出很多数据来，这个系统的性能值得怀疑。

不是说这个东西不好，也不是说这样就有问题。什么样的系统解决什么样的问题。OceanBase对于它所需要解决的很多问题，提供了一个良好的解决方案。但是我觉得专用系统的局限性在于它的通用化并不好。我相信OceanBase可以在很多方面做得比Oracle表现好。取而代之不是问题。我所疑惑的是，这些应用场景的通用性有多高？

OceanBase如果想要作为一个通用的系统去取代Oracle，就像OceanBase团队和阳老师一直强调的去IOE里面的O，我想目前的这个体系架构基本上是不可能的。

6

总结来说，这个架构对于大规模并发，有很多的读，有一定的写的事物系统优化的非常不错。确实代表了国内领先水平，是华人的骄傲。

这个架构对于通用事物处理，尤其是不需要那么大规模并发的场景，可能latency会偏高，有杀鸡用牛刀的感觉。我想这解释了阿里里面并没有全面铺向OceanBase。MySQL的改良版在很多其他应用场景上依然很普遍的原因。

这个架构对于没有主键的大规模数据读取不友好，所以我想OceanBase基本上是应该放弃了高效支持OLAP的愿望了。除非体系架构发生根本性的变化。支持高效OLAP应该是做不到的。但是体系架构改变也是不容易的一件事情。

通用性问题，尤其是在数据类型，支持的函数，特殊情况下的行为，等等，是一个很基础性的问题。OceanBase在这方面的整个发展过程，从我能看到的信息来看似乎经过了一些转折。从兼容Oracle到兼容MySQL，加上对Oracle的支持。我觉得这个基础性问题在一开始没有被非常严肃的对待，是很多以应用场景为主导的互联网企业开发软件的通病。而一旦软件定型以后，在向后兼容性和向特定数据库的兼容性的双重压力下，往往产品会很容易陷入僵局，可作为的空间不断被压缩。我觉得如果OceanBase的人能聊聊这一方面，会是非常值得一读的。

OceanBase的优化器应该很长时间都不是他们的重点。但是一个对外服务的优秀数据库系统，优化器不可能不做好。到今天我相信优化器依然是任重道远。

Michael Stonebraker说数据库领域的发展已经从通用系统过渡到专用系统了。这一点我是很相信的。所以如果OceanBase作为一个比较专有的系统继续发展我觉得一点问题也没有。当然如果OceanBase的目标就是要全方位取代Oracle，那么一个从特定应用场景的专用系统成长成通用系统的系统期间的曲折变化，我觉得也是任何做数据库的人都感兴趣的宝贵财富，真心希望可以看到这方面的经验交流的文章。

最后，不得不很遗憾的说，迄今为止我没有看到有关tpc-c的benchmark的数据出来。也许是我关注不够。OceanBase的团队反复强调过很多性能的东西，比如说比MySQL快两倍之类的。但是我们都知道，一个相对公平的比较需要相对公平的基准测试以及测试的软硬件环境。MySQL的版本实在是很多。OceanBase也发表过在不同应用场景下的测试数据。

但是无论如何，作为一个事务处理系统，没有tpc-c的数据出来，让我对这个团队说的任何话，都只能在心里先打个折扣。也不仅仅是我会打折扣。任何一个在这个领域从事工作的人，都一样会打折扣。因为这个东西既然是国际通行的一个标准，OceanBase的团队无法提供的话，我只能在系统不能完整的跑tpc-c和系统跑tpc-c的结果不能亮瞎我的眼之间选一个。无论是哪个，在我看来都只有负面效应。因此，我觉得OceanBase的团队应该认真的考虑一下，先给我们看看tpc-c的结果。倘若到今天OceanBase到现在还不能完整的跑tpc-c，那将极大程度上改变我对这个系统的认知。

打赏专用二维码