浅谈oceanbase与polardb-x

前言

本文不是比较oceanbase与polardb-x到底谁更好,而是主要探讨以下他们一些设计上的特点以及一些思考。之所以把oceanbase和polardb-x拿在一起聊,是因为他们都属于分布式数据库,在他们的设计上互相比较和思考,可以加深理解。

设计与抽象

下图是oceanbase和polardb-x的整体架构图。虽然只有两幅图,但是图上我们可以看出来非常多的东西,让我们来一一探讨。
image.png

是否抽象zone

这个算是oceanbase的一个特点,在总体架构上专门设计了zone。在探讨设计zone的合理性之前,我们先来思考下:为什么人家设计的时候会往这个方向考虑?一种因素可能是不采用zone的设计本身遇到了很多坑,发现必须做这一层的抽象;另外一方面就是有往这方面想的灵感。假设是后一种的话,值得我们学习的点就是,我们自己如何在做设计时也能有这样的灵感。

这种思考的方式在计算机领域的多年发展中其实有了很多实践,核心就是以更高的视角,把整个分布式软硬件作为整体来一起设计。可以分享个例子让你加深理解。过去大家在思考并发处理的范式的时候,更多的是从线程、进程这种粒度来考虑的,[2] 而google的jeff daen则创新的把整个分布式集群的所有节点作为系统设计的一部分一起来思考,从而产生了赫赫有名的MapReduce。

回到zone这一层的抽象,显然oceanbase是有将整个分布式软硬件一起考虑来设计的。分布式系统的机器可以分布在不同地域的不同机器上。做zone这一层抽象,意味着ob可以更加容易围绕可用区来实现一些数据库特性。OceanBase官方文档描述设计zone主要是为了实现高级别容灾能力。这种高级别的容灾能力主要是指可以按照物理部署单元(IDC或者Rack)这种粒度进行控制。其实别的分布式数据库也都是支持容灾的,只不过ob在物理部署单元上做了一层抽象使得其可以在物理部署单元层面(zone)做很多控制,而且这些能力都是可以暴露给用户的。zone只是个逻辑概念,底层具体zone下节点的数据复制和大部分分布式数据库实现都是接近的,就是paxos follower同步leader数据。
image.png

ob基于zone的一个有意思的能力是,轮转合并。因为ob本身算是LSM based的分布式数据库,利用zone的控制机制,可以按照zone的粒度做轮转合并,除了轮转合并以外,zone也可以配合zone隔离做一些低峰时期的合并。

然后总结下优缺点吧:

  • 优点:提供基于zone上的控制能力,可以实现更多这方面的能力
  • 缺点:提升了复杂度,实现上复杂度提升,用户使用上复杂度也提升。如果不涉及多地域部署的,感知zone的管理会带来额外的心智负担。

是否抽象tenant

ob提供了tenant的抽象,实际上是用于资源隔离的namespace。从使用灵活性上来说,这个肯定是有价值的。利用租户可以非常快速的在一个集群上马上隔离出一个新的namespace,而不是让用户重新创建一个数据库实例,那将会是非常重的。那为什么polardb-x没搞?这个后面我们也会提到,polardb-x总体的很多设计和取舍都是围绕——完全兼容mysql协议的分布式数据库而设计的。mysql没有租户的概念,自然polardb-x也是没有的了。

计算、存储的分与合

存算分离是一种被证明比较优秀的设计理念,比较有代表的就是aurora和pulsar了。计算存储分离的架构整体上会更加灵活。解耦、职责分离使得每一层能够更灵活的去实现一些特性。像pulsar的topic就不像kafka这么重,而且能做很多更灵活的特性。

很多分布式数据系统都会在设计之时面临这个问题。在数据库系统中,我们讨论这个数据库是否存算分离,首先得明确定义,哪些是计算,哪些是存储。我们这里探讨时,我们将SQL层作为计算层,将KV存储作为存储层。

  • oceanbase: 按照我们的定义,不属于存算分离。SQL层和KV存储作为一个整体,是个紧耦合的设计。好处是单节点性能会非常好,本质上也是做更加彻底的data locality,避免SQL层和存储之间的网络开销。缺点是提升了系统复杂度,做scale out比较麻烦。
  • polardb-x: 因为我以前也在该团队待过,polardb-x的架构是有其历史根源的。polardb-x的前身团队并不做存储,因此SQL层和存储层是分离的。在data locality的彻底程度上相比oceanbase会差些,不过复杂度更低,scale out也更加方便。类似的还有TiDB

两种设计本身没有对与错,关键取决于你在乎什么。这个文末和大家交流下商业化数据系统设计取舍的思考。

CDC与数据库

polardb-x与oceanbase一个很大的不同就是将其CDC能力作为核心组件抽象。这个其实在业内还是比较少见的。我们通常将CDC能力更多是看成数据集成系统的能力,而polardb-x将CDC作为内置核心组件来抽象可以给到我们一些新的启示。为什么对于polardb-x来说,这个CDC组件会显得更为重要呢?这主要是因为polardb-x是一款非常重视mysql兼容性的分布式数据库。CDC组件的最大意义是提供兼容mysql协议的全局binlog。做过数据集成系统的都明白,mysql的数据集成生态是十分成熟的,polardb-x提供mysql style的binlog对于他融入整个数据生态帮助是非常大的,例如mysql生态下的备份恢复工具、CDC工具,poalrdb-x兼容起来都会比较方便。

元数据组织形态不同

  • oceanbase: oceanbase的元数据管理方式就是:所有信息全部存在表内[5]。一切是自包含无外部依赖的。这样对于系统管理和运维是带来一些好处的,缺点是meta data没有一定程度的职责分离,同时由于实现上完全依赖表,实现上可能会带来一些限制。
  • polardb-x: 拆分了独立的元数据服务GMS。不过这个GMS其实还蛮重的,TSO也一起包含在其中。

设计trade-off的思考

如果是需要设计一款商业化数据系统,我个人在设计上会倾向于:满足客户需求的基础上尽量简单。虽然这句话挺短的,其实要做好是不容易的。为了实践这句话,我们得搞清楚如下两个问题:

  • 用户画像是怎样的:我们开发的产品的用户画像到底是如何的。这个需要设计者有足够的行业积累与洞察,以及众多来源于真实客户的反馈。在这个基础上,我们才能确定什么叫做“满足客户需求”。当产品的用户画像足够清晰时,我们自然也就明白能力上如何做取舍了。
  • 如何保持简单:在充分理解用户画像的基础上,我们要做的就是,keep it simple。像《黑客与画家》这本书给我最重要的启示就是:好的系统一定是简单的。在满足客户需求的基础上我们尽量保持简单,让客户使用起来足够简单,让我们系统的设计足够简单。简单的系统会有更少的bug,更加稳定。当然在保持简单的时候我们仍然需要遵循一些朴实的思想,例如SOLID,来保持你的系统虽然简单,但是仍然保留足够的扩展性。

参考资料