PolarDB · 新品介绍 · 深刻了解阿里云新一代产品 PolarDB

背景意义

云计算为现在的互联网时代提供了更多的计算能力，乃至创造能力，关系型数据库做为全部应用不可或缺的重要部件，开箱即用，高性价加比特性的云数据库深受开发者的喜好。做为一线的开发和运维人员，在阿里云的线上值班中，咱们常常会碰到如下经典的客户抱怨。
"你好，大家RDS的产品很棒，可是就是有点小贵，尤为是我要买只读实例的时候，成本是线性增长的，大家何时能便宜点？"
"我在4天前，手工作了一个备份，数据库比较大，3T，大家说差很少要70个小时备份，这个。。有没有什么办法加快一点，我老板还着急要数据呢"
"我昨天花钱买了一个只读实例，可是实例到今天还没建立好，3T数据量是大了一点，有没有方法能加快一点？"
"我拿大家的RDS MySQL测试了一下性能，可是貌似不太给力，跟我以前用的Oracle/SQL Server等一些商业数据库差的有点多，有什么办法提升性能么？若是不行，我仍是迁回自建的数据中心吧"
"你好，咱们公司有个数据库，想迁到阿里云RDS上，对RDS的产品品质咱们很满意，只是咱们的数据库有10T，请问一下，支持这么大的实例么？"
"你好，我用了大家的MySQL数据库，最近几天在作活动，主库压力比较大，只读实例就延迟了，如今看过去貌似很难跟上，有什么办法么？"

上述抱怨/吐槽都来自用户真实的案例，总结起来，传统的云数据库因为自身架构缘由，会遇到以下问题：

1. 读写实例和只读实例各自拥有一份独立的数据，用户购买只读实例，不只须要付出计算的成本，也须要付出存储资源的成本。
2. 传统备份技术，因为也涉及到拷贝数据，并上传廉价存储，速度所以也受网络影响。
3. 读写实例和只读实例各自拥有一份独立的数据，新建一个只读实例须要从新拷贝数据，考虑到网络限流，速度不会很快。
4. MySQL数据库早期的版本，对早期的系统/硬件作了不少优化，可是并无考虑到现代主流的系统/硬件的优秀特性，在高并发环境下，性能还有很大的提高空间。此外，与其余关系型数据库不一样，MySQL为了兼容性，须要写两份日志(事务日志和复制日志)，与其余商业数据库相比，性能相对较差。
5. 因为物理机磁盘限制以及备份等策略，数据库的数据大小不能太大，太大的实例是运维的灾难。
6. 读写实例和只读实例经过增量逻辑数据同步，读写实例上全部的SQL须要在只读实例上从新执行一遍(包括SQL解析，SQL优化等无效步骤)，同时，复制并发读最高是基于表维度，致使主备延迟很是广泛，进而影响各类切换任务。
   随着数据库数据量的增大，这些小麻烦会不断的加重，给DBA，开发乃至CTO带来困恼。
   现在，这些困扰你们已久的问题，在阿里云即将推出去的PolarDB中将获得解决，注意，是从本质上解决，而不是想个trick绕过去。

PolarDB是阿里云ApsaraDB数据库团队研发的基于云计算架构的下一代关系型数据库(暂时仅支持MySQL，PostgreSQL正在紧锣密鼓的开发中)，其最大的特点是计算节点(主要作SQL解析以及存储引擎计算的服务器)与存储节点(主要作数据块存储，数据库快照的服务器)分离，其次，与传统的云数据库一个实例一份数据拷贝不一样，同一个实例的全部节点(包括读写节点和只读节点)都访问存储节点上的同一份数据，最后，借助优秀的RDMA网络以及最新的块存储技术，PolarDB的数据备份耗时能够作到秒级别(备份时间与底层数据量无关)，这三点相结合，咱们能够推断出PolarDB不但知足了公有云计算环境下用户业务快速弹性扩展的刚性需求(只读实例扩展时间与底层数据量无关)，同时也知足了互联网环境下用户对数据库服务器高可用的需求(服务器宕机后无需搬运数据重启进程便可服务)。

架构分析

图1是PolarDB公测版本的整体架构图。图2是PolarDB数据库内核上的架构。
解释一下图1中的各个组件。
上部分三个黑色框表示三台计算节点，下部分三个蓝色框表示三台存储节点。
在计算节点上，主要有三个重要部件：

DB Server: 即数据库进程(Polar DataBase, 简称PolarDB)。PolarDB数据库内核区分实例角色，目前包括三种角色，Primary，Standby和Replica。Primary即为拥有读写权限的读写库，Replica即为只读实例，仅仅拥有读取数据的权限(后台线程也不能修改数据)，Primary和Replica采用Shared Everything架构，即底层共享同一份数据文件和日志文件。StandBy节点拥有一份独立的数据和日志文件(如图2所示)，虽然用户线程依然只有读取数据的权限，可是后台线程能够更新数据，例如经过物理复制的方式从Primary节点更新增量数据。StandBy节点主要用来机房级别的容灾以及建立跨可用区的只读实例，公测阶段暂时不开放。因为只读实例的扩展不须要拷贝数据，建立新的只读实例不但速度快，并且很便宜，用户只须要支付相应计算节点的成本便可。咱们称StandBy和Replica节点为Slave节点，Primary节点也可称为Master节点。

User Space File System: 即用户态文件系统(Polar File Sytem, 简称PolarFS)。因为多个主机的数据库实例须要访问块存储上的同一份数据，经常使用的Ext4等文件系统不支持多点挂载，PolarDB数据库团队自行研发了专用的用户态文件系统，提供常见的文件读写查看接口，便于MySQL和相关的外围运维工具使用文件系统支持相似O_DIRECT的非缓存方式读写数据，还支持数据页原子写，IO优先级等优秀的特性，为上层数据库的高性能提供告终实的保障。传统的文件系统，因为嵌入在操做系统内核中，每次系统文件读写操做都须要先陷入内核态，完成后再返回用户态，形成效率低下。PolarFS以函数库形式编译在MySQL中，所以都运行在用户态，从而减小了操做系统切换的开销。

Data Router & Cache: 即块存储系统客户端(Polar Store Client, 别名PolarSwitch)。PolarFS收到读写请求后，会经过共享内存的方式把数据发送给PolarSwitch，PolarSwith是一个计算节点主机维度的后台守护进程，接收主机上全部实例以及工具发来的读写块存储的请求。PolarSwith作简单的聚合，统计后分发给相应的存储节点上的守护进程。因而可知PolarSwitch是一个重资源的进程，若是处理很差，对计算节点上的数据库实例有很大的影响，所以咱们的管控程序对其使用了CPU绑定，内存预分配，资源隔离等一些手段，而且同时部署了高效可靠的监控系统，保证其稳定运行。

Data Chunk Server: 即块存储系统服务器端(Polar Store Server, 别名ChunkSever)。上述三个部件都运行在计算节点上，这个部件则运行在存储节点上。主要负责相应数据块的读取。数据块的大小目前为10GB，每一个数据块都有三个副本(位于三台不一样的存储节点上)，两个副本写成功，才给客户端返回成功。支持数据块维度的高可用，即若是一个数据块发生不可用，能够在上层无感知的状况下秒级恢复。此外，PolarStore使用了相似Copy On Write技术，支持秒级快照，即对数据库来讲，无论底层数据有多大，都能快速完成全量数据备份，所以PolarDB支持高达100T的磁盘规格。
计算节点和存储节点之间经过25G RDMA网络链接，保证数据的传输瓶颈不会出如今网络上。
此外，PolarDB还有一套完善的基于docker的管控系统，处理用户下发的建立实例，删除实例，建立帐号等任务，还包括完善详细的监控，以及可靠的高可用切换。管控系统还维护了一套元数据库，用以记录各个数据块的位置信息，提供给PolarSwitch，便于其转发。
能够说，PolarDB整个项目用了不少不少的新技术黑科技，给用户直接的感觉是，又快(性能是官方MySQL6倍)又大(磁盘规格支持高达100T)又便宜(价格只有商业数据库的1/10)。
接下里，咱们重点分析PolarDB在MySQL内核方面的功能加强、性能优化以及将来的规划。便于读者了解PolarDB数据库内部运行的机制。

功能加强

物理复制

简单的想，若是读写实例和只读实例共享了底层的数据和日志，只要把只读数据库配置文件中的数据目录换成读写实例的目录，貌似就能够直接工做了。可是这样会遇到不少问题，随便列举几条：

1. 若是读写实例上对某条数据进行了修改，因为Buffer Pool缓存机制，数据页可能尚未被刷新到磁盘上，这个时候只读实例就会看不到数据，难道每次都刷盘，那跟文件有什么区别。
2. 再仔细想想事务，一个读写事务，修改了3个数据页，2个数据页刷下去了，可是1个数据页尚未刷盘，这个时候只读节点由于须要查询也须要这几个数据页，而后数据就不一致了？也就是说只读节点上的MVCC机制彷佛会被破坏。
3. 考虑一下DDL，若是在读写实例上把一个表给删除了，万一只读实例上还有对这个表的查询呢？只读实例去哪里查询数据哈？要知道IBD文件已经被读写实例这个家伙干掉了，可怜的只读实例只能coredump以示不满？
4. 若是读写实例正在写一个数据页，然而恰好只读实例也要读取这个数据页，而后只读实例有可能读了一个写了一半的数据页上来，而后checksum校验不过，数据库crash。

因此，仔细思考一下，多个数据库实例共享同一份数据不是一件容易的事情。为了解决上述问题，咱们须要只读实例也按照读写实例更新数据的节奏来更新数据而且须要一套完善的脏页刷盘机制。现代关系型数据库中其实已经有一份记录数据页更新的Redolog事务日志了，在MySQL中，就是ib_logfileXX相似这种文件，所以参考Binlog复制框架，PolarDB使用这种事务日志构建了一套数据复制方法，在只读实例上只须要顺序应用读写实例产生的日志便可，StandBy节点和Replica节点二者都须要更新内存中的数据结构，可是StandBy节点因为独立维护一份数据和日志，因此须要把更新的增量数据写入到本身的数据文件和日志中，而Replica则不须要。因为MySQL的Redolog相比于Binlog记录的都是物理的数据页(固然也有逻辑部分)，因此咱们把这种复制称为物理复制。
因为Redolog并无记录用户的SQL，仅仅记录了最终的结果，即这个SQL执行后形成的数据页变化，因此依赖这种复制架构，不须要SQL解析SQL优化，MySQL直接找到对应的文件中的数据页，定位到指定偏移，直接更新便可。所以性能上能够作到极致，毕竟并发粒度从以前的表级别变为了数据页级别。固然也会带进来不少新的问题，简单列举几个：
物理复制中的MVCC。MySQL的MVCC依赖Undo来获取数据的多版本，若是Primary节点须要删除一个Undo数据页，这个时候若是Replica节点还在读取的话就会有问题，同理，StandBy节点也有这个问题，所以咱们给客户提供两种方式，一种是全部Slave按期向Primary汇报本身的最大能删除的Undo数据页，Primary节点统筹安排，另一种是当Primary节点删除Undo数据页时候，Slave接收到日志后，判断即将被删除的数据页是否还在被使用，若是在使用则等待，超过一个时间后直接给客户端报错。此外，为了让Slave节点感知到事务的开始和结束以及时间点，咱们也在日志中增长了很多逻辑日志类型。
物理复制中的DDL。Primary节点删除一个表以后，Replica可能还会有对此表的请求。所以，咱们约定，若是主库对一个表进行了表结构变动操做，在操做返回成功前，必须通知到全部的Replica(有一个最大的超时时间)，告诉他们，这个表已经被删除了，后续的请求都失败吧，具体实现上可使用MDL锁来控制。固然这种强同步操做会给性能带来极大的影响，后续咱们会对DDL作进一步的优化。
物理复制中的数据复制。除了复制引擎层的数据以外，PolarDB还须要考虑MySQL Server层表结构的一些文件复制，例如frm, opt文件等。此外，还须要考虑一些Server层的Cache一致性问题，包括权限信息，表级别的统计信息等。
物理复制中的日志并发应用。既然物理日志可让咱们按照数据页的维度来支持并发，那么PolarDB须要充分的利用这个特性，同时保证在数据库奔溃后也能正确的应用日志和回滚事务。其实这部分的代码逻辑与MySQL崩溃恢复的逻辑很像，PolarDB对其进行了复用和改造，作了大量的性能上的优化，保证物理复制又快有稳。
物理复制中的Change Buffer问题。Change Buffer本质上是为了减小二级索引带来的IO开销而产生的一种特殊缓存机制。当对应的二级索引页没有被读入内存时，暂时缓存起来，当数据页后续被读进内存时，再进行应用，这个特性也带来的一些问题，例如Primary节点可能由于数据页还未读入内存，相应的操做还缓存在Change Buffer中，可是StandBy节点则由于不一样的查询请求致使这个数据页已经读入内存，发生了Change Buffer Merge操做，从而致使数据不一致，为了解决这个问题，咱们引入shadow page的概念，把未修改的数据页保存到其中，将change buffer记录合并到原来的数据页上，同时关闭该Mtr的redo log，这样修改后的Page就不会放到flush list上了。此外，为了保证Change Buffer merge中，不被用户线程看到中间状态，咱们须要加入新的日志类型来控制。
物理复制中的脏页控制。Primary节点不能毫无控制的刷脏页，由于这样Replica会读取到不一致的数据页，也会读取到未提交事务的数据页。咱们给出了一个策略，replica须要缓存全部未刷盘的数据变动(即RedoLog)，只有primary节点把脏页刷入盘后，replica缓存的日志才能被释放。采用这个策略后，replica内存的使用率与primary的刷脏速度就相关量起来，因此须要对primary节点的刷脏算法进行调整，同时也要考虑一些频繁更新的数据页致使primary节点刷脏缓慢的问题。
物理复制中的Query Cache问题，discard/import表空间问题，都须要考虑。
此外，在兼容性方面，因为PolarDB存储引擎暂时只兼容InnoDB数据表，Myisam和Tokudb暂时都不兼容，而系统表不少都是Myisam的，因此也须要转换。
物理复制能带来性能上的巨大提高，可是逻辑日志因为其良好的兼容性也并非一无可取，因此PolarDB依然保留了Binlog的逻辑，方便用户开启。

实例角色

传统的MySQL数据库并无实例角色这个概念，咱们只能经过查询read_only这个变量还判断实例当前的角色。PolarDB中引入三种角色，知足不一样场景下的需求。Primary节点在初始化的时候指定，StandBy和Replica则经过后续的配置文件指定。

故障切换

目前支持三种类型的切换，Primary降级为StandBy，StandBy提高为Primary以及Replica提高为Primary。每次切换后，都会在系统表中记录，便于后续查询。Primary节点和StandBy节点因为拥有各自的数据文件，在异步复制的模式下，容易形成数据不一致，咱们提供了一种机制，保证新StandBy的数据必定与新Primary的数据一致。想法很简单，当新StandBy再次启动时，去新Primary查询，回滚掉多余的数据便可，只是咱们这里不使用基于Binlog的SQL FlashBack，而是基于Redolog的数据页FlashBack，更加高效和准确。Primary节点和Replica节点，因为共享同一份数据，不存在数据不一致的分享，当发生切换的时候，新Primary只须要把老Primary未应用完的日志应用完便可，因为这个也是并行的操做，速度很快。
这里简单提一下，目前公测阶段的故障切换逻辑：首先是管控系统检测到Primary不可用(或者发起主动运维操做)，则链接上Primary(若是还能够)，kill全部用户链接，设置read_only，设置PolarStore对此IP只读(Primary节点和Replica节点必定在不一样的计算节点上)，接着，链接到即将升级的Replica上，设置PolarStore对此IP读写，MySQL从新以读写模式挂载PolarFS，最后执行Replica提高为Primary的语句。正常状况下，整个过程时间很短，30秒内便可切换完成，可是当Primary和Replica延迟比较大的时候，须要更多的时间，可是相比于以前Binlog的复制，延迟时间至少降低2个数量级。后续咱们会对这块继续进行深度优化，进一步提升实例可用性。

复制模式

传统的Binlog复制模式只有异步复制和半同步复制两种。在PolarDB中，咱们还增长了强同步复制，即要求Slave节点应用完数据才返回成功，这个特性对复制特别敏感的用户来讲，是个好消息，能保证只读实例查询出来的数据必定与读写库上查询出来的同样。此外，PolarDB还支持延迟复制功能，复制到指定事务，复制到指定时间点等，固然这几个特性主要是提供给灾备角色StandBy的。此外，为了进一步减小复制延迟，若是Replica发现自身延迟超过某个阈值，就会自动开启Boost模式(会影响实例上的读)，加速复制。若是Primary节点发现某个Replica延迟实在太大，出于安全考虑，会暂时把这个Replica踢出复制拓扑，这个时候只须要从新启动一下Replica便可(因为Replica不须要作奔溃恢复，重启操做很快)。PolarDB还支持复制过滤功能，即只复制指定的几个数据库或者指定几个表，这样因为不须要复制查询不感兴趣的数据，从而能够进一步下降复制延迟。这里提到的各类有趣的特性，在公测阶段还暂时不支持，在不久的未来，会陆续开放给你们。

日志管理

相似Binlog的日志管理，PolarDB也提供了相似的机制和工具来管理Redolog。首先，与传统MySQL循环使用Redolog不一样，与Binlog相似，PolarDB中Redolog也是以文件编号递增的方式来管理，并提供相应的删除命令给管控系统使用。PolarDB依据PolarStore的全量备份和Redolog增量日志为客户提供还原到任意时间点的功能。PolarDB还有一个专门用来解析Redolog日志的工具mysqlredolog，相似Binlog解析工具mysqlbinlog，这个工具在系统诊断中很是有用。Redolog中，PolarDB也增长了很多独特的日志类型，为了作到兼容性，Redolog也有版本管理机制。传统的MySQL仅仅数据文件支持O_DIRECT，PolarDB为了适配新的文件系统，Redolog日志也支持O_DIRECT方式写入。
此外，PolarDB对Undo日志也进行了深度的开发，目前支持Online Undo Truncate，妈妈不再用担忧个人ibdata数据文件过大啦。

监控信息

PolarDB增长了那么多功能，天然也会提供不少新的命令，例如用户可使用SHOW POLAR STATUS来查看相关信息，使用SHOW POLAR REPLICAS来查看全部已经链接的replica节点。使用START POLAR SLAVE来启动复制，使用SHOW POLAR LOGS来查看产生的Redolog文件，等等等。PolarDB在information_schema中也增长了好多表，有兴趣的读者能够去看一下，这里面到底存的是什么。

实例迁移

目前数据库内核支持(大概再过几个月会提供给用户使用)从RDS 5.6迁移到PolarDB上，流程主要以下，首先在RDS 5.6上使用xtrabackup作个全量的数据备份，接着在计算节点上，xtrabackup作恢复，成功后，经过PolarFS提供的运维工具把全部的数据文件放到PolarStore上，而后使用特定的参数启动PolarDB，PolarDB会把RDS 5.6日志文件格式转换成PolarDB的Redolog，接着可使用Binlog方式追增量数据，当追上RDS 5.6的读写库且到达用户指定的切换时间，设置RDS 5.6读写库只读，而且PolarDB作一次重启，关闭Binlog复制，最后把VIP切换到PolarDB上便可完成迁移工做。

周边工具

除了上文提到的解析Redolog日志工具外，因为对源码进行了大幅度的改动，PolarDB还对MySQL原生的TestCase Framework进行了改动，保证在共享数据日志的场景下(Local FS/Disk and PolarFS/PolarStore)全部的Testcase能经过。

性能优化

PolarDB除了拥有大量新的特性外，咱们还作了不少性能上的优化，这里简单列举一些：

1. 在高并发的场景下，PolarDB对不少latch作了优化，把有些latch分解成粒度更小的锁，把有些latch改为引用计数的方式从而避免锁竞争，例如Undo segment mutex, log system mutex等等。PolarDB还把部分热点的数据结构改为了Lock Free的结构，例如Server层的MDL锁。
2. 针对用户在SQL语句中直接指定主键的SQL语句，PolarDB也作了相应的优化，这样能够减小一些优化器的工做，从而获得更好的性能。
3. PolarDB中物理复制的性能相当重要，咱们不只经过基于数据页维度的并行提升了性能，还对复制中的必要流程进行了优化，例如在MTR日志中增长了一个长度字段，从而减小了日志Parse阶段的CPU开销，这个简单的优化就能减小60%的日志Parse时间。咱们还经过复用Dummy Index的内存数据结构，减小了其在Malloc/Free上的开销，进一步提升复制性能。
4. Redolog的顺序写性能对数据库性能的影响很大，为了减小Redolog切换时对性能的影响，咱们后台采用相似Fallocate的方式预先分配日志文件，此外，现代的SSD硬盘不少都是4K对齐，而MySQL代码仍是按照早期磁盘512字节对齐的方式刷日志的，这样会致使磁盘作不少没必要要的读操做，不能发挥出SSD盘的性能，咱们在这方面也作了优化。
5. PolarDB的Replica节点，日志目前是一批一批应用的，所以当新的一批日志被应用以前，Replica上的读请求不须要重复建立新的ReadView，可使用上次缓存下来的。这个优化也能提升Replica上的读性能。
6. PolarDB对临时表也作了一些优化，例如在临时表上能够把Change Buffer关掉，临时表的修改能够少作一些操做，例如在应用日志的时候能够不对索引加锁等。
7. PolarDB也继承了AliSQL几乎全部的性能优化点，例如，日志核心函数log_write_up_to的优化， LOCK_grant锁的优化，jemalloc内存分配库的使用，日志Group Commit的优化，Double RedoLog Buffer的优化，Buffer Pool Hazard Pointer的优化，自适应concurrency tickets的优化，只读事务的优化等等，详情能够参考GitHub上的AliSQL首页。
8. 咱们实现了一套按需应用日志的控制算法，即只有在Buffer Pool中的数据页才须要应用日志，同时，不只仅是后台线程会应用日志，用户线程也会应用日志，这两点相结合，大大减小了应用日志缓慢而形成的延迟。此外，因为使用了自研的PolarFS文件系统，刷脏的延迟和吞吐量与传统的Ext4文件系统有很大的不一样，咱们对page cleaner和double write buffer(虽然PolarFS支持原子写，但依然能够开启)都进行了优化，例如增长dblwr个数以及调整page cleaner线程的算法和优先级等。

展望将来

PolarDB目前已经公测，可是将来咱们还有不少有趣的特性能够作，在性能方面也有不少的优化点，例如：

1. 目前PolarDB高可用切换和实例可用性检测都须要依赖外部的管控系统，另一方面，因为Primary和Replica共享数据和日志，若是Replica和Primary之间的通讯中断，Replica就感知不到数据文件的状态，在这种状况下，Replica将会不可服务，为了解决这两个问题，PolarDB也会引入相似Raft协议下的自制集群机制，自动检测可用性，自动发起切换。具体实现能够参考RDS金融版三节点实例自制集群的方案。
2. 能够在Replica节点上引入相似Materialized view的特性，固然这里不是指数据库概念中的视图，而是PolarDB中的ReadView。
3. 上文提到过，目前的DDL是个强同步点，所以咱们须要进一步优化DDL，例如引入文件多版原本解决Replica读的问题。另外，Online DDL不少状况下依然须要拷贝整个数据文件，也许咱们能够参考PolarStore COW的思想，把这部分拷贝数据的IO压力分摊到后续的DML中。
4. 在阿里云，用户有不少上云迁移数据的需求，物理迁移的方式毕竟只能服务MySQL数据库，逻辑的SQL导入才是最通用的解决方法，所以咱们须要尽可能提升在导入大量数据时的性能。一个简单的优化就是数据按照主键顺序排序，咱们记录最后一次插入的BTree页节点位置，后续插入就不须要再从Root节点开始扫描了。咱们也能够在导入数据的时候，暂时关闭Redolog日志写入，也能提升性能，相似Oracle Nologging机制。
5. 在存储引擎的锁机制上，PolarDB也还能够作更多的优化，使用更多的lock free结构，减小锁冲突。咱们也考虑使用最新的Futex来取代效率低下的Spinlock，固然这些功能须要通过完善缜密的测试，才能上线。
6. 因为PolarFS/PolarStore能提供16K数据页维度的原子写支持，因此咱们不须要相似double write buffer的机制，并对写数据页的操做进一步优化，例如经过某些机制能够释放数据页在刷盘时hold住的读锁。PolarDB也可使用PolarFS提供的IO优先级功能，保证日志是以第一优先级刷入磁盘。这些改动能大幅度提高性能，可是与锁机制相似，咱们须要作充足的测试。
7. 此外，咱们也会Port官方MySQL 8.0的最新的数据字典结构，由于MySQL支持事务性DDL须要这些必要的改动。

写在最后

总之，PolarDB是阿里云数据库团队为云计算时代定制的数据库，拥有不少优秀的特性，是云计算2.0时代产品进化的关键里程碑之一，也是开源数据库生态的积极推进力。咱们将在9月下旬开放公测，期待你们的反馈。

参考文献：

http://www.infoq.com/cn/news/2017/08/ali-polardb
https://www.percona.com/live/data-performance-conference-2016/users/zhai-weixiang
https://www.percona.com/live/17/users/zhai-weixiang