引言众所周知，分布式数据库具有天然的复杂性，导致其有较高的使用门槛，想要非常轻松的享用分布式数据库带来的红利，并不是一件简单的事情，往往要感知到很多分布式的细节，从而拉高了使用痛点。让产品更加简单易用，是PolarDB-X孜孜不倦的追求，实现简单易用的一个重要手段就是“去分布式”，当然并不是说从技术架构上“去分布式”，而是让产品越来越透明，从用户体感上“去分布式”，进而实现让简单触手可及。本篇来介绍一下PolarDB-X在“简单”这一课题上的思考和实践，聊一聊我们的“去分布式”之路。
一、分布式数据库面对的问题
从广义上来理解，具备分布式能力的数据库便可以称为分布式数据库。其显著特征是实现了副本一致性的协议，在某种程度上具备scale up的能力，典型的代表有MySQL MGR、Oracle RAC以及云厂商阿里云的PolarDB、AWS Aurora等。
从狭义上来理解，真正意义上的分布式数据库应该是具备水平伸缩能力的数据库，其特征为数据分区和横向的线性扩展能力。业界典型的代表有Google Spanner、TiDB、PolarDB-X、HBase、OceanBase等。
和所有的事物一样，分布式数据库具有明显的两面性。
首先，分布式数据库解决的两大核心问题是：海量数据存储以及高性能并行计算。在解决这两个核心问题的基础之上，分布式数据库同时在高可用、高性能、灵活性等层面也具有一些天然优势。
然而，使用分布式数据库并不是一件简单的事。成本上，显性成本比如硬件成本非常高，隐性成本比如开发成本、运维成本也一直是业界痛点；技术架构上，分布式数据库为了保证一致性、稳定性，天生具有很高的复杂性；用户的使用上，分布式数据库需要实现生态兼容和简单易用，也颇具挑战。
近年，随着技术的发展，分布式数据库一直在往好的方向演进。
数据库诞生于上世纪70年代，真正意义上的分布式数据库诞生于2005年，以Google BigTable为标志开启了NoSQL时代。2012年，以Google Spanner为标志，进入了NewSQL时代，分布式数据库在体系架构以及各个层面都有了很大发展。
如今，随着云计算越来越成熟，我们进入了分布式数据库和云计算深度融合的时代。数据库从工程积累、技术理论、硬件层面都有了非常大的进步，前文所述的痛点问题也呈现出非常快的收敛趋势。
二、PolarDB-X的思考和实践
PolarDB-X是阿里自研的云原生的分布式数据库，是一款基于Share-Nothing架构，并同时支持在线事务处理和在线分析处理的融合型分布式数据库，具备金融级的数据高可用、分布式一致性以及极致的弹性能力。
PolarDB-X的发展经历了三个阶段，其前身是TDDL——孵化于阿里电商场景，最早期以TDDL+ALISQL的形式在阿里内部持续使用多年。15-17 年进入了PolarDB-X 1.0时代，产品名为DRDS，以DRDS+RDS的中间件形态，支撑了很多线上公共云的用户以及线下税务系统、路网系统以及社保系统等的大规模使用。2020年左右，PolarDB-X进入了2.0时代，主打计算、存储一体化和HTAP，进入了深度融合时代。
PolarDB-X作为一款分布式数据库，能够解决诸多痛点问题和胜任多种业务场景，比如：在线超高并发，普通数据库扛不住的问题；海量业务数据，普通数据库存不下的问题。提供了金融级的可靠性，提供了 HTAP 能力以解决复杂分析查询场景下性能慢的问题。另外，提供了多种数据分区策略，得以解决单表数据量大、效率低的问题。它也是分库分表方案的完美替代者，能够解决分库分表场景下的各种运维痛点。
PolarDB-X的技术架构由四个部分组成。
- 元数据服务：提供了全局授时服务 TSO，整个集群的元数据以及安全权限账号等相关体系都基于元数据服务进行支撑。
- 存储节点：解决数据的一致性、可靠性问题以及处理分布式 MVCC 事务的可见性判断。
- 计算节点：负责 SQL 引擎相关的工作，处理分布式事务的2PC协调以及全局二级索引维护等。
- 日志节点：对外提供数据订阅能力，提供了兼容 MySQL 的全局 binlog 协议和数据格式，兼容了 MySQL 的数据流入协议，支持数据的高效流入和流出。
相比于计算和存储一体化的架构，PolarDB-X灵活的存算分离架构有两个明显优势，分别是灵活性和低成本。在计算密集型场景，可以单独对计算节点进行扩容，而无需增加存储节点的成本。在存储密集型场景，可以单独扩充存储层的节点，而无需增加计算层的成本。
PolarDB-X当前在公共云售卖的形态下，可以在计算层做到非常好的极致弹性能力，存储层目前使用本地磁盘的架构，进行存储层扩容时会涉及到数据迁移的动作，因此暂时还无法做到极致弹性，在速度上还有一定限制。
基于上述问题，目前我们内部正在做孵化和演进，将本地磁盘替换成共享存储。比如类似PolarDB的 PolarFS 或基于高效云盘 ESSD 来构建共享存储池。当共享存储本身未达到容量瓶颈时，无需任何数据迁移的动作，可实现存储层的秒级扩容，只需调整参数即可达到极致的弹性能力。
提供金融级的可靠性和一致性是数据库的核心目标之一，PolarDB-X在此方向上也一直在进行探索和创新。
数据存储方面，我们自研了一套X-Paxos协议来实现 RPO=0的目标，保证在单机房部署、跨中心部署和两地三中心部署时，都能实现数据可靠不丢，并通过一系列自愈算法，保证RTO<30S。基于两阶段2PC来保证事务的 ACID，并对存储层的 InnoDB 做了创新性的改造，结合 TSO 实现了分布式的 MVCC ，从而保证了数据读的线性一致。
以驾驶场景来做个比喻，在驾驶汽车时，路况较好时一般会采用自动模式，比如定速巡航或自动驾驶；路况不好时则需要手动介入。
在使用分布式数据库时，遵循同样的规律， 80% 的场景都是一些常规需求，此时用户可以选择自动模式。自动模式指使用PolarDB-X时，可以完全将其作为单机MySQL来看待，比如创建表时只需执行和单机 MySQL 一样的建表 SQL ，使用索引时亦如此。
而另外 20% 的高阶需求则需要用户进行手动或定制化的处理，具体来说就是要明确感知到数据的分区规则和分区分布。比如数据库在跨地域部署甚至是全球部署的场景下，往往需要显式的将一些数据保存到特定的存储节点上，基于PolarDB-X的Locality 特性可以实现数据与地域相关的高阶管理。再比如在数据归档场景，基于PolarDB-X的local partition 和 partition TTL机制，通过指定分区规则和分区过期策略，数据即可按照用户指定的策略完成自动归档。
自动模式加手动模式的组合相辅相成，为用户带来充满乐趣的使用之旅。
PolarDB-X的混合负载能力,可以从两个层面来理解。
首先，TP场景的读写分离。
比如用户购买了主实例，当主实例的读写压力较大时，可以增加只读的存储实例，然后设定好读写比例，即可自动将设定比例的读流量路由到只读的存储副本，从而给主实例减轻压力。如果有更高阶的需求，也可通过Hints的方式显式指定某条 SQL 只路由到读实例上查询。
SQL被路由到只读实例之后，在读一致性的保障上，能够支持灵活的选择。比如对查询一致性要求不高的场景，可以设定成弱一致模式，查询时数据即使在只读副本上不存在，也会立刻返回结果；如果对数据查询的一致性要求比较高，则基于 TSO 的策略可以实现线性的一致读，即保证写后读的能力。
其次，智能读写分离。
PolarDB-X内部实现了混合优化器和执行器。当用户提交的查询流量是 AP 查询时，优化器可以自动感知到此为 AP 型 SQL ，会将查询自动路由到只读实例集群，并基于 MPP 进行查询加速，从而保证 AP 查询的响应时间更低，用户等待时间更短。该方案可以满足大部分场景的 AP查询需求。目前，PolarDB-X的存储节点依然为行存模式，我们内部正在做列存系统的研发，通过实时消费存储节点的增量日志将数据格式转换为列存，并实时同步到 OSS 来支撑 AP 场景下更苛刻的查询需求。
使用数据库时对冷数据进行定期归档是非常常见的场景。常规的实现手段为：首先需要维护一套定时的归档程序， 对数据进行定期删除，并将数据保存到冷备存储中；其次，为了实现对冷数据的查询需求，往往还需改造应用代码，分别适配热数据的查询和冷数据的查询；在一些更高阶的融合型查询场景中，即对冷数据和热数据有join查询的需求时，往往还需搭建一套独立的查询引擎，如presto。
上述手段是成本高昂的、运维痛苦的、复杂难用的，好消息是PolarDB-X提供了原生的冷热数据分离能力，开箱即用，简单透明，主要特点可以归纳为：
- 易用性：如需对某张表进行归档，只需在建表 SQL 中指定好归档策略，PolarDB-X内核程序会自动完成归档操作，入门极简。
- 透明性：不论是对冷数据进行独立查询，还是对冷热数据进行融合查询，只需提交业务SQL即可，PolarDB-X的SQL执行器会进行自动适配，为归档表提供和主表一致的使用体验，完全透明。
- 高性能：通过多级缓存、多级索引与查询裁剪等技术，可实现数据的快速存取，并结合列存索引选择、向量化计算、AGG加速等手段，不论是点查询还是分析型查询，都拥有非常不错的性能表现。
- 开放性：归档数据兼容业界主流数据存储格式，如ORC，默认归档到OSS存储，使用入口是多元的，并非必须是PolarDB-X，用户可在自己的大数据引擎中轻松访问。
- 低成本：归档数据保存在OSS对象存储，并进行了高效压缩，成本仅为PolarDB-X热数据的1/20，拥有非常高的性价比。
DDL是数据库的必备能力, 也是数据库系统中一个颇为复杂的模块，对于分布式数据库来说复杂性则更甚，存在很多技术挑战和难点。
面对这种复杂性， PolarDB-X的目标是把复杂留给自己，把简单留给用户，秉持的理念是“One SQL ，One Enter”， 通过一条SQL、一次回车即可完成各种各样的DDL变更，比如：
- 快速将单表演进成分区表
- 快速进行分区数量的变更
- 快速对热点数据进行分区迁移或分区分裂
- 当出现数据分布不均衡时，执行全局的分区Rebalance
并且通过一系列机制，来保证DDL操作是
- Online的
如提供了instant add column能力，online modify column type能力等，保证变更过程中DDL和DML互不干扰；通过类似Google F1的方案，保证元数据状态的柔性切换，规避全局Lock； - 稳定的
提供了资源评估和自感知能力，保证DDL负载控制在一定范围内，避免影响正常业务流量；提供DDL任务的全生命周期管理能力，可以实现快速的启停、限速能操作； - 快速的
通过多分片并行执行，降低数据迁移量，提升DN节点的instant ddl能力，来尽量缩短DDL变更的时间窗口。
数据是非常关键的企业核心资产，数据丢失时有发生，快速的数据恢复能力，是数据库必备的特性。PolarDB-X在数据恢复层面主要提供了3种恢复策略。
- Flashback Query （闪回查询）：基于 Undo log 和 TSO 实现的技术方案。原生 MySQL 并没有该能力，Oracle 是基于 Undo log 来实现的，PolarDB-X的技术实现原理与 Oracle 比较类似。使用层面，用户提交 SQL 并指定好时间戳即可查找对应版本的数据，其特性是可以实现表级的数据恢复，性能超快、超轻量。
- SQL FlaskBack（SQL闪回）：基于全局 Binlog 实现的恢复能力，支持镜像恢复和逆向恢复两种策略，其特性是表级的恢复能力、快速轻量，用户只需指定时间范围，即可通过文件的方式获取到恢复Sql。
- 传统的基于 PITR 的方式：实例级的恢复能力。基于全量的备份恢复集加幂等执行Binlog可以实现全局任意时间点的一致性恢复。
另外，PolarDB-X也支持回收站功能，开启回收站之后，可以基于回收站对某些操作进行还原，如常见的truncate操作。
在分布式数据库领域，主键的设计方案有很多种，比如基于单表自增的方案、基于分段缓存的方案、基于timebase sequence的方案等等。但这些方案很难做到单调递增，增长趋势基本没有任何规律（如上图黄线所示），让习惯了MySQL Auto_increment特性的用户很是不爽。
PolarDB-X为大家带来了福音，从5.4.14版本开始PolarDB-X实现了完全兼容 MySQL AUTO_INCREMENR 的主键方案，可以保证全局单调递增且拥有不错的性能，与 MySQL 的行为完全一致。举例来说，使用一张表执行 insert sql时，如果不指定主键，则主键呈现单调递增的增长趋势，如上图蓝线所示；当然也支持自动跟随能力，如果执行某条insert sql时显式指定了主键，下次的auto插入会自动跳跃到该主键之后，如图中绿色曲线所示。
流动的数据才有价值，因此 CDC 是所有分布式数据库的必备功能。PolarDB-X 的目标是不仅要让数据流动起来，而且要让数据畅通、优雅地流动起来，主要体现在几个方面：
第一，提供了完全兼容MySQL Binlog的全局Binlog；
第二，提供了完全兼容MySQL Dump协议的数据订阅能力；
第三，透明分布式。数据库内部发生变更时，对外保证完全透明，如对分布式事务、分布式 DDL 以及对分布式扩缩容等保证透明无感；
第四，不错的性能。500M/s的写入吞吐，50w-70w的EPS，200ms-5s 秒的延迟。
基于上述特性，在使用PolarDB-X进行数据订阅时，完全将 PolarDB-X看作单机 MySQL即可 ，能够轻松将业界主流的数据同步工具和大数据生态打通，且成本非常低，存量系统无需或仅需少量改造，即可适配到 PolarDB-X生态体系。
全局Binlog目前是以单个流的形态对外提供订阅服务，能够满足大部分场景下的数据订阅需求，但是对于超大规模集群，全局 Binlog 需要汇聚所有存储节点的数据，存在一定的性能瓶颈。为了应对超大规模集群场景，我们正在进行Binlog-X 多流系统的研发，可以将每一个流看作单机 MySQL，既能兼顾兼容性，又能提供很好的性能，预计会在2023年3月份对外开源。
数据流入层面，PolarDB-X可以完全当作 MySQL Slave 来使用。只需登录数据库，执行 change master......即可消费单机 MySQL 的Binlog ，将数据源源不断地导入到 PolarDB-X内部，并支持多种写入模式：按事务串行写入，表级的并行写入，行级的并行写入等。
PolarDB-X于 2021 年 10 月完成了首次开源，后续进行了多轮版本迭代，发布了诸多功能特性。开源的目标，除了提升自身产品的影响力，更多是期望接触和拥抱社区，能为社区做一些贡献，并打通整个生态，让更多的用户看到源码，让更多对技术感兴趣的同学一起参与产品的共建。
最近一年，我们开设了开源学堂，组织了开源训练营，得到了很多技术同学的积极参与。另外，在企业合作层面也进行了大力推广，目前已经落地的合作项目是与韵达股份进行PolarDB-X的开源共建。离客户越近，才能感受到用户最实际的需求和痛点，让产品变得更好。
PolarDB-X的后续计划如上图所示，主要分为三个阶段：
第一，计划于 9月30日之前开放一些企业级特性，主要包括并行跑批、读写分离、容灾部署、备份恢复等；
第二，预计于今年年底完成国产化相关的特性开放；
第三，会在明年3月30日前实现商业和开源分支的统一，正式将商业版本的代码在开源分支100% 开放，并且开放各种开发框架，让更多感兴趣的同行一起参与到PolarDB-X的开源宫殿里。
三、分布式数据库的未来展望
在单机时代，用户进行数据存取的选择很少，几乎只有数据库一个选项。随着互联网和物联网的发展，大数据从数据库体系中独立出来，形成了独立的大数据赛道，近些年呈现了百花齐放、百家争鸣的态势。
对用户来说，可选择的产品更多了，能支撑的业务场景也更丰富了，但过多的选择也给用户带来了很多选型上的困扰，并且整个行业也没有统一的标准，企业在构建自己的数据架构时，往往只能将不同的产品拼凑在一起，运维、开发成本极高，也极为繁琐。
近些年随着云计算的不断发展和成熟，大数据和数据库呈现出了快速融合的态势。可以大胆预测，未来数据库和大数据必定会进入超融合的时代，很多功能单一的产品会逐渐被淘汰。而分布式数据库则是实现超融合的能力担当，只有借助于分布式架构的灵活性，才能将各个领域的需求和场景归集到一起，从而实现真正的融合，为用户提供更好的使用体验。
HTAP是数据库和大数据相融合的一个典型代表，但这仅仅是冰山一角，TP、AP、Streaming、ML等方向都有很大的融合空间，而终极融合则是Cloud Native。只有借助于云的虚拟化技术，才能实现真正的 Serverless，从用户视角看，才是真正意义上的让简单触手可及。当然Serverless肯定也不会是终点，道阻且长，行则将至，PolarDB-X会朝着这个方向不断发展、不断进阶！
作者：阿里云数据库技术专家 卢彪（自扬）
/ End /
