当前位置:   article > 正文

十年磨一剑,云原生分布式数据库PolarDB-X的核心技术演化

polardb-x

前言
PolarDB-X前身是淘宝内部使用的分库分表中间件TDDL(2007年,Java库的形态),早期以DRDS(2012年开始研发,2014年上线,分库分表中间件+MySQL Proxy的形态)的品牌在阿里云上提供服务,后来(2019年)正式转型为分布式数据库PolarDB-X(正式成为了PolarDB品牌的一员)。从中间件到分布式数据库,我们在以MySQL为存储构建分布式数据库这条路上走了10余年,这中间积累了大量的技术,也走了一些弯路,未来我们也会坚定的走下去。
PolarDB-X的发展过程主要分成了中间件(DRDS)和数据库(PolarDB-X)两个阶段,这两个阶段存在着巨大的差异。笔者参与PolarDB-X的开发恰好刚满十年,全程经历了整个发展过程。今天就和大家唠一唠PolarDB-X发展与转型过程中的一些有意思的事情。
中间件时代(2012~2019)
DRDS时期的发展思路其实很简单,满足用户的几个主要诉求:

  • 阿里云上提供的RDS MySQL单实例最大存储空间有限制(例如早期只有2T);
  • Share Storage的数据库可以解决磁盘容量问题,但依然受到单机CPU\内存的限制,无法解决写扩展性的问题;
  • 使用开源中间件能解决上述问题,但做扩容等运维操作十分的麻烦复杂。

在这样的背景下,我们在中间件TDDL之上增加了一个MySQL Proxy(实际上是Cobar的网络层),部署在了阿里云上,便成为了最早的DRDS。
上云的开始--使用云,也服务云
值得一提的是,DRDS上云的方式放到现在看,也是非常时髦的。
像阿里云的普通用户一样,它也拥有一个阿里云的账号(只不过这个账号有上万亿的授信额度),使用这个账号的AK/SK,调用阿里云各个产品的Open API来进行各种操作。


例如,创建实例时,会购买ECS来进行部署DRDS节点;会购买SLB搭在前面来做负载均衡;会购买SLS服务用来存储该实例的SQL审计;会打通DRDS节点到用户RDS的网络等等。
这种形式的管控架构目前被广泛地运用,充分地利用了云的优势。DRDS几乎不需要关注资源问题,也不需要自己维护库存;像机器宕机这种问题,ECS也能自动地进行迁移(连IP都不会发生变化),非常的便利。让DRDS的研发团队可以将更多的精力放在提升产品本身的能力上。
DRDS一方面为阿里云上的用户提供服务,另一方面也作为阿里云的一个“普通用户”,享受着云技术带来的好处,还是非常有趣的。
在DRDS时期,我们在内核侧重点积累了以下技术能力:
SQL语义上与MySQL的兼容性
TDDL仅服务于内部用户,而淘宝的研发规范相对是比较严格的,应用使用的SQL都是比较简单的类型,所以对SQL的处理是非常少的,简单说,它甚至不需要理解SQL的语义,仅做转发即可。但云上用户的需求五花八门,又存在大量迁移上云的存量应用,对SQL兼容性要求变高了很多。这就要求我们要提供一个完整的SQL引擎。
DRDS相对于TDDL以及市面上一众的分库分表中间件,多了两个关键组件:具备完整的算子体系的查询优化器与执行器。它的目标是无论SQL有多复杂,都要能够正确理解其语义,并执行出正确的结果。
这里有非常多需要长期积累的工作。举几个例子:

类似这样的工作还有很多,例如类型系统(PolarDB-X 类型系统概述 - 知乎)、sql_mode、时区系统、默认值等等,繁琐但必要。这些工作都很好地延续到了PolarDB-X中。
极致的下推优化
将计算下推到与数据最近的地方,这是保证性能的一个最朴素的原则。
将MySQL作为一个分布式数据库的存储引擎,它实际上本身也具备很强的计算能力。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/Monodyee/article/detail/247884
推荐阅读
相关标签
  

闽ICP备14008679号