PolarDB-X与X-DB、PolarDB都是阿里巴巴的数据库产品。那么他们之间有什么样的关系?
要回答这个问题,我们首先要搞明白,什么是X-DB。
什么是X-DB?
简言之,X-DB主要指在MySQL的基础上基于XEngine引擎打造的分布式跨AZ高可用数据库。
X-DB的核心能力之一是基于Paxos跨AZ RPO为0。最初阿里内部所使用的的MySQL,是传统的主备架构,每一个MySQL实例由两个节点组成。
这种架构有一个重要缺陷,如果发生主备切换,可能会导致副本数据的不一致。为了解决主备架构的问题,阿里最初是采用了非常多的运维手段来解决这种问题,例如:
一套叫ADHA的系统,专门用来对MySQL服务进行探活、主备切换等操作
在主备切换之前做一些复杂的数据校验,确保主备数据一致才会进行切换(所以万一无法一致,如何切换?)
在跨城场景下,使用自研的数据同步服务来代替MySQL内部的同步机制
业务的数据的回滚回补,利用一套很复杂的数据订正程序(跟业务相关,并且对业务的表结构是有一定要求的) ...
这套架构虽然work,但并不优雅,复杂度和使用成本都非常的高,很难跟得上业务的发展。
16年,阿里内部开始了X-DB的研发。X-DB首先就是要克服副本数据一致性的问题。 X-DB的团队选择自研Paxos协议来替代MySQL内置的主备同步逻辑。Paxos的介绍有很多文章了,这里就不再赘述,有兴趣的同学可以自行进行检索。
这里简单列举下使用了Paxos协议后的MySQL的两个最核心的优势: 1. 可以在任意时刻进行切主操作,不会产生任何数据一致性问题,RPO=0 2. Leader选举、探活等完全由X-DB内核(MySQL进程)内完成,无需依赖任何外部系统
X-DB的Paxos协议库结合MySQL的方案在阿里内部经过几年的发展,目前已经完全替代了存量的传统的主备MySQL集群,具有很高的可靠性。
PolarDB-X与X-DB
从上文看出,X-DB比较好的解决了是灾备、故障恢复这类问题,但是服务场景的通适性以及水平扩展的能力就是PolarDB-X的强项了。
PolarDB-X 2.0的数据节点(DN)融合X-DB的集群容灾技术,在这之上提供了水平扩展的能力。
此外,从业界来看,使用类似Paxos的协议来构造存储节点,是众多分布式数据库的共同选择,例如TiKV使用Raft协议,OceanBase使用Paxos协议等。
例如:TiKV中的Raft三副本:
实际上,X-DB与PolarDB-X的关系远不止Paxos协议这一点,在分布式事务、扩展性、计算能力的下推、HTAP等地方,都做了大量的开发工作,请关注我们后续的文章。
PolarDB-X与PolarDB
PolarDB(这里指PolarDB For MySQL)是一个基于共享存储技术的云原生数据库。PolarDB在存储空间上可以做到很强的弹性能力,但一般使用情况下,其计算能力、写入能力依然存在单机的上限。
PolarDB-X 2.0这种share-nothing的架构,使得包括计算、写入、读取、存储等在内的所有资源,都具备了可水平扩展的能力,因此不会存在单机的瓶颈上限。
但是,share-nothing的架构在单纯的数据容量的弹性上,是不如PolarDB的共享存储架构的。
举个例子,无论使用哪一种share-nothing数据库,例如PolarDB-X 2.0、TiDB,假如现在一共10台机器,10T的数据,现在想通过加机器的方式,扩展存储空间,那总是有一半的数据需要进行搬迁到新的机器上,而这个搬迁所需要的时间,会跟数据量成正相关(比如一般情况下,十几T量级的数据进行搬迁一般都至少需要数小时的时间)。
对于PolarDB来说,上面的场景需要分钟级即可扩容完成。
那么,有没有可能结合share-nothing的优势与shared-storage/share-everything的优势呢?
答案是肯定的。
目前,下一代分布式数据库,就是会在DN引入PolarDB基于RDMA硬件+共享存储架构的核心技术,从而达到在所有资源都可以水平扩展的同时,大幅降低容量弹性的代价。
PolarDB-X 本地盘版与共享存储版未来将会是一个长期并存的关系,不会存在谁完全替代谁的问题。因为本地盘版不依赖任何特殊硬件,主要对专有云轻量化输出更为友好,目标是基于用户3台机器完成PolarDB-X的交付;共享存储版容量上具备高弹性,但这种弹性需要在一定规模下的公有云上才会有很好的体现(公有云上才有足够大的机器池子供业务去弹性)。
PolarDB-X 会是一个划时代的产品,欢迎大家持续关注!