简介：PolarDB-X 2.1 是 PolarDB-X 十分重要的版本，也是第一次 PolarDB-X 分布式数据库的产品能够作为企业级的分布式数据库真正部署到客户的生产环境应用。
PolarDB-X 2.1 新版本公布
让“MySQL 原生分布式”触手可及
——黄贵（曲山）
阿里云数据首席架构师
理解更多 PolarDB-X 内容：https://developer.aliyun.com/…
PolarDB-X 2.1 是 PolarDB-X 十分重要的版本，也是第一次 PolarDB-X 分布式数据库的产品能够作为企业级的分布式数据库真正部署到客户的生产环境应用。
一、一个好的 MySQL 分布式数据库应该是什么样的
image.png
C++ 语言设计的概念 Zero Overhead Abstraction ——0 累赘形象准则，它有两个重要个性：
毋庸为不必的个性付出代价：C 类用户降级到 C++ 时，如果不应用 C++ 里的高级个性，则毋庸为这些个性付出额定的代价。比方在 C 外面是 structure，到 C++ 里可能是 class。对于 C 中的 structure 和 C++ 中的 class，如果不带 virtual function，则在内存布局的性能耗费上是等同的，不必付出额定的代价。
你所应用的代码，不可能手写得更好：如果想要应用更高级的个性，用 C++ 扩大的能力，肯定比手写的代码更好，即 C ++ 提供的语言个性可能很好地帮忙到用户。
C 语言的用户降级到 C++，必然是因为它带来了更新更强的能力，比方封装、形象的能力，能够做继承、有多态。另外，C++ 提供了多种编程范式，比方面向对象、泛型编程、函数式编程等，这些个性都能够极大地拓展语言的形象，带来能力的晋升。
同理，从单机的 MySQL 数据库降级到分布式 MySQL 数据库，咱们冀望它能有哪些体现？
首先是齐全兼容，能够由单机平滑过渡到分布式系统，无需对利用进行革新；第二，无需对数据库的构造进行革新；第三，不应用分布式能力则毋庸付出额定的开销。
单机到分布式最重要的变动是数据会散布在多个节点上，对于数据库中很多操作而言，尤其是事务，是须要付出一些额定代价的。如果事务波及到多个数据的分区，而只是想将分布式系统作为单机数据库来用，同样也能够有单表的个性，毋庸付出分布式事务的代价。
降级到分布式系统后可能取得主动伸缩的能力，可能人造地利用分布式的个性实现跨地区的高可用，还能够解决混合的负载类型，包含事务的负载以及剖析的负载，提供了高性价比的解决方案。
二、让分布式能力透明化
image.png
如何实现从单机到分布式齐全透明化？
以从单机 MySQL 迁徙到 PolarDB-X 2.1 版本为例：
第一步：建表。应用单机 MySQL 上的建表语句、DDL 语句在新的分布式数据库上建表，毋庸做任何批改。
第二步：让利用跑起来。利用代码也毋庸做任何批改，原有的 SQL 语法、原有的客户端驱动程序都能够间接应用，只须要更换新的数据库连贯地址。
第三步：性能调优。能够应用很多工具做压测，包含一些可视化工具，可能提供对整个零碎 SQL 性能的剖析，DAS 主动调优工具可能帮忙找到热点 SQL，还能够通过 DDL 建新的索引或对数据分区进行调整，对热点 SQL 进行调优。
实现以上整个过程的大部分操作只是诊断和适配，毋庸进行过多革新工作。
image.png
对于分布式系统而言，要做到通明，外围就是对分布式事务的反对。分布式数据库与单机数据库的要害差别在于，分布式数据库是以肯定的规定将数据做分片，而后散布在多个节点上，其中外围点在于如何在事务跨了多个数据分片时，保障它的 ACID 语义。这其中会波及到如何做事务的 ACID 保障，如何做多版本解决并发的管制。有了事务 ACID 的保障，能力在此之上建设全局二级索引。
此外，很多其余性能比方备份复原、工夫回溯的查问以及分布式的备份等，都须要依赖分布式事务提供的全局一致性能力。数据的导入和导出也须要保证数据有全局快照的能力，在任何工夫点都能读到统一的版本。
有了全局二级索引和多版本的并发管制等能力的反对，即可实现通明的分布式，毋庸显式地指定分区键，只须要像单机数库一样创立表，即能默认做数据的分区，也毋庸思考数据分区带来的跨节点事务的解决。表的批改操作和 Online DDL 也不会对数据库的其余操作产生影响。
image.png
PolarDB-X 实现的是全局一致性的分布式事务
（应用 TSO 全局 timestamp）+ MVCC（多版本并发管制机制）实现的分布式数据库。次要的技术原理是基于 Paxos 做事务日志的同步来保障高可用。
在事务在解决的过程中，因为应用了两阶段提交的形式来做分布式事务的解决，如果产生了节点生效，也能够利用 Paxos 带来的高可用能力保障事务持续进行上来。
另外，应用了全局惟一的工夫戳以及多版本并发管制的机制来保障它的隔离性，实现了 Snapshot Isolation 的隔离级别。
具体流程如下：GMS 组件提供全局事务的工夫戳，在发动事务的过程中，如果事务要做提交，则会获取提交的工夫戳并将其带到所有上面存储节点的参与者上。而后联合事务以后的状态，依据工夫戳判断事务的可见性。每一条数据上都有其提交的工夫戳，将其与以后事务的工夫戳做比拟，以决定这条数据在以后的事务中是否可见。
通过上述机制即可实现分布式事务的全局一致性和快照隔离。
本次 2.1 版本公布的最重要的性能就是主动模式数据库的性能。PolarDB-X 在 1.0 版本时代，是利用分库分表的模式来进行数据的主动分区。2.0 的时代引入了全新的 AUTO 模式数据库，无需指定分区键。
image.png
上图展现了典型的电商交易场景，有交易记录表，其主键是事务 ID，还有买家和卖家两个重要角色。对于交易的流水而言，通常除了按交易的流水日志 ID 查问以外，也有可能从买 / 卖家的维度查问。
表内可能有上亿条记录，须要将它创立为分区表。对于分布式数据库 PolarDB-X 而言，无需指定特定的分区键。因为这里的分区健，如果是依照 buyer_id 或者 seller_id 去查问，无奈做分区裁剪。能够像应用单机数据库一样默认按主键 ID 做数据的分片。分片的算法默认是一致性哈希，也反对很多其余算法，包含 interval 做范畴的划分、range 的分区等，此类算法也能够通过 DDL 语句依据业务特点做调整，另外还能够通过多个查问维度建全局二级索引。
上图例子中建了两个全局二级索引，别离是买家 ID 和卖家 ID。往表外面插入数据的时候，会针对数据依据数据的分区规定，将它平均地散布在数据节点上。上图右侧两张索引表同样也依照分区规定做了平均的散布。
image.png
数据主动负载平衡的性能，使得用户无需关怀数据具体散布在哪个数据节点上，可由零碎主动实现，主表以及两张索引表都依照肯定的规定做数据的拆分，分片当前依照数据的大小和容量均匀分布到各个数据节点上。
有了主动负载平衡的能力当前，也就具备了在线扩缩容的能力，而在线扩缩容是单机到分布式平滑演进的重要根底。
image.png
上图有计算层的 CN 节点，也有存储层的 DN 节点。CN 节点是无状态节点，扩容和缩容十分轻量化，因为所有 CN 的能力都对等，将 SQL 发送到任意 CN 节点都能够实现同样的解决能力，失去雷同的后果。出于性能的思考，个别会将数据就近调度到邻近的 CN 节点上。
因而，CN 的扩容十分不便，只需简略地将 CN 节点增加到集群上，同步到 GMS 节点里即可。
DN 是有状态的数据节点，扩缩容须要做数据的迁徙。减少了一组数据节点后，调度工作管理器会依据以后数据的散布情况，将一部分数据迁徙到新的数据节点上，以此保障所有节点的数据处在平衡的散布状态。
性能和容量方面，PolarDB-X 最大能够反对 1024 个节点，单节点最大存储 5TB 数据，可能满足大部分数据库的容量需要。
缩容同理，下线数据节点后，会将它缺失的正本补足，而后从新均匀分布到其余数据节点上。
从单机数据库迁徙到分布式数据库，能够基于 Online DDL 的能力动静实现单机大表切换到数据分片的模式。比方原来在单机上十分大的表，心愿通过分布式系统的数据分布能力对其进行拆分，能够通过一些 DDL 的能力动静地批改其分区模式，来实现单表到数据分布表的转换。
对于单机分布式而言，PolarDB-X 齐全兼容了 MySQL 的语义及其行为，包含上下游对接的生态，比方全局 CDC 能够生成全局统一的 Binlog，能够将其作为单机 MySQL 的日志流来应用。不论是同步到上游大数据系统，还是作为 MySQL 的备份，都能够通过 CDC 来对接。
image.png
Online DDL 最大的特点就是在做 DDL 的过程中对以后数据库正在解决的业务 DML 语句没有任何影响, 极大加重了数据库运维人员的累赘。数据库难免会遇到一些批改表构造、减少点索引等诉求，如果每次都要在业务的低峰期去进行，对运维会造成很大困扰，而且不够及时。有了 Online DDL 的反对当前，能够在任意工夫点做变更。这些变更包含了创立索引、加减列、变更分区算法。
值得一提的是，加列操作应用了 Instant DDL 机制，能够只批改元数据，毋庸对全副数据进行批改，操作性能极高，为毫秒级，对业务的影响能够缩减到最小。
此外，能够将数据库由单表变成分区表。在分区表上还能够批改分区数、表组以及分区算法等。同时也能够将它批改成播送表，在每个数据节点上都有同样的复制表，对于频繁做 join 的小表十分有用。这些能力也使得用户能够灵便调整数据表的数据分布形式，以满足不同业务负载的需要。
三、分布式是一种全新数据库的模式
分布式是一种全新的数据库模式，它不仅是对单机数据库的齐全兼容，更大的作用是带来了更多更强的能力。PolarDB-X 2.1 版本带来了以下卓越的能力：
- 高可用容灾能力
image.png
2.1 版本正式引入了 X-Paxos，应用 Paxos 一致性协定保证数据的可靠性以及零碎节点生效时的可用性。
它实现了 99.99% 可用性：任意节点的故障都不会影响集群的可用，数据 0 失落。
提供了多种部署状态：
① 同城三机房，默认 2.5 正本。在 Paxos 协定框架下有几种角色，包含 leader 节点（数据事务的主节点），它带有两个正本，别离是 follower 节点和 logger 节点。logger 节点为了节省成本，不存储全量数据，只存储日志来保证数据的一致性，同时也缩小了数据正本的存储；另外还有 learner 节点，能够做只读的正本。
② 两地的三核心，默认五正本。
领有分布式个性：用 Paxos 协定做一致性同步时，须要传输日志，而在网络上保障大量的日志传输的一致性较为艰难。2.1 版本反对日志分片的拆分，也做了行级热点的写入，反对主动合并，为很多电商的秒杀业务场景提供了保障；另外，通过对 follower 节点凋谢读，在 follower 节点上能够将全局 TSO 带过来，做一致性版本的读，利用 follower 节点的解决能力来晋升整个零碎的吞吐。
image.png
高可用的架构帮忙咱们提供了一个很好的根底。使得 PolarDB-X 在容灾方面也提供了强有力的撑持，比方两地三核心的部署形式。采纳 5 正本（2+2+1）的机制，设置了很多规定，比方存储正本 leader 节点生效从新选主的时候，会优先选择同机房的主节点，对整个零碎服务的可靠性和延时不会带来太大的影响；另外，机房生效时，能够做五正本到三正本的降级操作，保障强一致性、继续的解决能力。
主可用区的概念是为了保障在同机范畴内做网络拜访时，最大可能地减小延时。
- 冷热拆散存储
image.png
冷热拆散存储是基于分布式数据库做的老本上的优化。利用 TTL 机制，在创立表的时候指定其过期工夫，将曾经过期的数据归为冷数据，做归档的存储。归档存储于 OSS 里，绝对于本地的在线存储，极大升高了老本。与此同时，OSS 上的存储格局进行了高度压缩，进一步升高了老本。
归档到 OSS 时采纳了凋谢的格局，长处在于能够对接很多开源生态，比方 Spark、Flink 的生态，而后做剖析、查问。同时，其本身的查问引擎也反对疾速查问在 OSS 归档的数据。
3. 可观测性
image.png
PolarDB-X 的 Dashboard 集成了开源的 Prometheus 等工具做监控、告警，剖析以后零碎的运行状态。另外还建了一套做 performance 的 insight 工具，剖析数据在各个节点上的散布情况以及他们在分区上的拜访频率，帮忙用户更好地发现零碎的性能瓶颈，并进行调优。
四、将来往何处去
将来咱们会继续在 PolarDB-X 开源版本上做更多投入。
image.png
咱们会将开源的 codebase 与以后的商业版本对齐，所有能力在内核层面齐全开源。也会持续做更多企业级能力的加强，使 PolarDB-X 齐全变为企业级的分布式数据库。
全新的 HTAP 引擎使得 PolarDB-X 同时可能处理事务型和剖析型的负载。另外还会做国产化适配调优，实现国产化代替的工作，包含深度诊断、自动化调优工具以及各种生态的对接等。
原文链接：http://click.aliyun.com/m/100…
本文为阿里云原创内容，未经容许不得转载。