共计 3436 个字符，预计需要花费 9 分钟才能阅读完成。
简介：深刻解读 PolarDB- X 的产品架构，以及分布式事务、通明分布式、程度扩大等技术底细。
一、PolarDB- X 是什么
PolarDB- X 最早起源于阿里团体 2009 年提出用分布式架构代替传统商业数据库，阿里研发了 TDDL 分库分表中间件。2014 年阿里团体开始全面上云，将 TDDL 升级成 DRDS 分布式数据库服务，实现了在线扩缩容以及数据拆分等能力。2018 年后，国内分布式数据库技术进入一个百家争鸣的场面，阿里在这方面也做了很多摸索，通过对 X -DB、PolarDB 等技术整合，诞生了 PolarDB-X。
PolarDB- X 联合了 Sharding On MySQL、NewSQL、Cloud Native DB 几种数据库理念的精髓，具备云原生分布式的个性，底层应用了 PolarDB 云原生数据库的技术，下层用到了很多分布式技术。
二、PolarDB-X 技术架构
PolarDB- X 采纳经典的两层架构，分计算层和存储层。计算层用的 PolarDB-X，能够独立程度扩大、扩缩容，各种能力齐备。在整个零碎里，一条 SQL 通过自研的解析器、优化器，失去分布式的执行打算；而后发送到存储节点执行；在两头的网络传输层，应用了定制的 RPC 协定，效率远高于传统的 JDBC 协定；之后执行打算会发送到 PolarDB- X 的执行引擎里去做具体的计算。
PolarDB- X 目前具备高可用、高可扩大、极致弹性等几个个性，高兼容、HTAP、凋谢生态，在 MySQL 生态里是一款具备竞争力的产品。
三、PolarDB- X 的几个关键技术
（一）分布式事务，如何实现 ACID？
如果分布式数据库要反对金融转账场景，就必须反对分布式事务，能力保障一致性，不会产生数据失落等异样。纵观业界技术，能够归成以下几类，第一类是基于 MySQL 的 XA 技术，实现两阶段提交；毛病是不能保障全局统一，不能保障全局快照。第二类是 TSO 技术做全局调配，实现给全局的事务定序，从而实现分布式快照。第三是 HLC 技术，也存在肯定的局限性。第四类是在 PG 里比拟多应用的 GTM 技术。这几项技术目前没有一个能完满解决所有场景，都须要在性能、可用性、扩展性方面去做衡量。PolarDB- X 认为 TSO 是比拟符合私有云以及混合云的技术。
PolarDB- X 基于 TSO 技术实现全局分布式事务。第一个问题是如何去做全局时钟，也就是 TSO。TSO 会给分布式事务做定序，依照工夫戳的程序去做排序。第二个问题是如何基于 MySQL 的 InnoDB 做分布式事务。PolarDB- X 对 InnoDB 的事务零碎做了深度革新，从本来的 ReadView 的事务机制革新成基于工夫戳的事务零碎。有了基于工夫戳的事务零碎之后，联合 TSO 技术，就能够实现全局统一的分布式事务。除此之外，事务里还有很多的技术难点，如何解决长写事务以及做全局的垃圾回收。
用 TSO 技术有一个必须要解决的问题——通常会减少几十微秒到几百微秒的 RT。因而，PolarDB- X 实现了一阶段提交、2PC 的异步提交等优化，可能尽量克服 TSO 带来的性能损失。
实现上述性能优化之后，通过与业界产品在 sysbench 和 TPCC 等测试集做了性能比照，PolarDB- X 的性能相对来说十分有竞争力。
（二）通明分布式，如何优化易用性？
通明分布式次要解决的问题是分布式数据库的应用门槛。很多分布式数据库技术听起来很好，但用户却认为很难用。比方用户经常困扰，为什么某些场景的性能会不如一个单机零碎，或者某些性能不具备，或者问题难以排查？从咱们对服务用户的教训来看，用户在应用分布式数据库过程中通常会遇到以下几个门槛，即如何抉择拆分键、如何优化分布式事务、如何优化慢查问。因而，咱们研发了通明分布式的我的项目，试图升高用户应用分布式数据库的门槛。
第一，如何做 Sharding。每个产品都有不同的解决方案，PolarDB- X 联合了 MySQL 分区表语法，从语法上齐全兼容 MySQL 列表，应用二级分区笼罩到用户的各种 Workload。这背地是基于一致性哈希算法，实现分区级的动静决裂，大大降低扩缩容的代价。以 Range 分区为例，一开始可能是 4 千到 5 千这个数据范畴，当这个 Range 的数据变多之后，它能够决裂成多个 Range，迁徙到多个机器上，防止数据过于集中。将这些技术融入 PolarDB- X 中，可能无效解决热点数据等问题。
第二，PolarDB- X 做的跟其余产品有差异化的技术，是 TableGroup。它解决的问题是 Join 下推，这是阿里的业务场景中十分常见。如果不能做 Join 的下推，做分布式 Join 的性能会比拟差。在 PolarDB- X 中，多个表按一个分区形式做 Partition，它们就会搁置于同一个 TableGroup，因而就能够实现 Join 下推。当然对应的，一个 TableGroup 中的分区决裂、迁徙，都须要以 PartitionGroup 为单位了。
第三，扩缩容离不开的一个问题，就是 Online DDL。例如 PolarDB- X 反对单表、拆分表、分区表，当用户对表类型进行批改，把分区键从买家 ID 改成卖家 ID 的时候，背地就是用 Online DDL 的技术。PolarDB- X 反对多种的 Online DDL，包含拆分键批改、创立索引、加减列等等，这些操作都能够在线上间接执行，对用户业务影响十分小。
PolarDB- X 的通明分布式提供了分区表、全局索引、Online DDL 等技术，使得用户的业务可能以很低的老本接入到分布式数据库中，并且后续随着业务的倒退，数据库还能够做通过 Scale-Up 或者 Scale-Out 的形式进步性能。
（三）HTAP 技术，如何进步剖析能力
所谓 HTAP，在 PolarDB- X 的了解中，即是否在线上数据库中执行简单查问。它的价值有两方面，一方面是可能升高用户的应用老本、运维老本，另一方面，就是实时的剖析，可能从实时数据取得实时洞察。做 HTAP 面对的技术挑战有几方面，别离是负载隔离、计算能力、存储能力。
对应到 PolarDB- X 的架构，会通过只读节点做负载隔离，简略查问发到读写节点，简单查问发到只读节点执行，因而这两种负载可能失去较好的隔离，不会相互影响。这两头的智能路由是通过优化器的代价估算去实现，代价高的断定为 AP 查问，代价低的断定 TP 查问。除此之外，这种架构还须要解决的一个问题是一致性快照，PolarDB- X 通过 TSO 技术，实现了只读节点的分布式事务。
接下来的问题是如何晋升计算能力和存储能力。
进步计算能力次要通过 MPP 并行计算、向量化计算等形式。此前 PolarDB- X 次要面向 TP 场景，做算子下推，以及通过分区裁剪尽量查问更少的分片，优化 TP 场景的性能。而面对 AP 场景，须要的技术则很不一样。具体来说，PolarDB- X 提供了原生的 MPP 反对，可能充分发挥多个节点的资源进行计算。为此，优化器里中减少了 MPP 优化阶段，在单机执行打算之后，两头退出 Exchange，变成分布式的执行打算，实现多机并行。具体到执行器，也会有两种执行模式，一种是本地单机执行，另一种是 MPP 分布式执行。
具体来看，在 MPP 并行计算中，PolarDB- X 做了两层的并行，第一层是节点之间的并行，第二层是计算节点外部的运行。分为两层的益处在于可能缩小调度开销，缩小数据传输的开销。除此之外，PolarDB- X 还做了内存池化、流水线化、向量化等精细化的技术，通过向量化进步执行器的执行效率，通过流水线化减少并行度缩小数据物化。这些技术使得 PolarDB- X 在执行简单 SQL 查问时具备较高的效率。
除此之外，就是进步存储方面的性能。从技术角度看，独自做一个行存、列存都不难，难的是做一个可能实时更新的列存。PolarDB- X 采纳的计划是在写入节点用行存，在只读节点用列存，两头通过 redo 做异步复制，实现列存的实时更新。基于这样的架构，就能够实现行列混存，行存承当高并发写入，列存承当简单查问。联合 MPP、行列混存、向量化等技术，PolarDB- X 实现了 TPC- H 场景的 5 -10 倍的性能晋升。这一成绩也行将在私有云上线，敬请期待。
四、总结
PolarDB- X 可能高度兼容单机 MySQL，从 SQL 兼容到事务兼容到生态兼容。在此基础上，通过通明分布式的技术升高用户应用门槛，使得用户能够疾速上手，适配各种用户业务，并通过弹性扩缩容的能力，适应用户的业务变动。而 HTAP 技术，将造成差异化的竞争力，使得用户可能从在线数据中取得实时洞察。
原文链接
本文为阿里云原创内容，未经容许不得转载。
