官网

阿里云PolarDB官网地址

是什么

POLARDB 是阿里云自研的下一代关系型分布式数据库，100%兼容MySQL，之前使用MySQL的应用程序不需要修改一行代码，即可使用POLARDB。

POLARDB在运行形态上是一个多节点集群，集群中有一个Writer节点（主节点）和多个Reader节点，他们之间节点间通过分布式文件系统（PolarFileSystem）共享底层的同一份存储（PolarStore）。

POLARDB通过内部的代理层（Proxy）对外提供服务，也就是说所有的应用程序都先经过这层代理，然后才访问到具体的数据库节点。Proxy不仅可以做安全认证（Authorization）和保护（Protection），还可以解析SQL，把写操作（比如事务、Update、Insert、Delete、DDL等）发送到Writer节点，把读操作（比如Select）均衡地分发到多个Reader节点，这个也叫读写分离。

POLARDB对外默认提供了两个数据库地址，一个是集群地址（Cluster），一个是主地址（Primary），推荐使用集群地址，因为它具备读写分离功能可以把所有节点的资源整合到一起对外提供服务。主地址是永远指向主节点，访问主地址的SQL都被发送到主节点，当发生主备切换（Failover）时，主地址也会在30秒内自动漂移到新的主节点上，确保应用程序永远连接的都是可写可读的主节点。

特点

• 容量大

  • 最高100T，不再因为单机容量的天花板而去购买多个MySQL实例做Sharding，甚至也不需要考虑分库分表，简化应用开发，降低运维负担。

• 高性价比

  • 多个节点只收取一份存储的钱，也就是说只读实例越多越划算。

• 分钟级弹性

  • 存储与计算分离的架构，再加上共享存储，使得快速升级成为现实。

• 读一致性

  • 集群的读写分离地址，利用LSN（Log Sequence Number）确保读取数据时的全局一致性，避免因为主备延迟引起的不一致问题。

• 毫秒级延迟——物理复制

  • 利用基于Redo的物理复制代替基于Binlog的逻辑复制，提升主备复制的效率和稳定性。即使是加索引、加字段的大表DDL操作，也不会对数据库造成延迟。

• 无锁备份

  • 利用存储层的快照，可以在60秒内完成2T数据量大小的数据库的备份。并且这个备份过程不需要对数据库加锁，对应用程序几乎无影响，全天24小时均可进行备份。

• 复杂SQL查询加速

  • 内置并行查询引擎，对执行时长超过1分钟的复杂分析类SQL加速效果明显。该功能需要额外连接地址。

• 一写多读

  • PolarDB采用分布式集群架构，一个集群版集群包含一个主节点和最多15个只读节点（至少一个，用于保障高可用）。主节点处理读写请求，只读节点仅处理读请求。主节点和只读节点之间采用Active-Active的Failover方式，提供数据库的高可用服务。

• 计算与存储分离

  • PolarDB采用计算与存储分离的设计理念，满足公共云计算环境下根据业务发展弹性扩展集群的刚性需求。数据库的计算节点（Database Engine Server）仅存储元数据，而将数据文件、Redo Log等存储于远端的存储节点（Database Storage Server）。各计算节点之间仅需同步Redo Log相关的元数据信息，极大地降低了主节点和只读节点间的复制延迟，而且在主节点故障时，只读节点可以快速切换为主节点。

• 读写分离

  • 读写分离是PolarDB集群版默认免费提供的一个透明、高可用、自适应的负载均衡能力。通过集群地址，SQL请求自动转发到PolarDB集群版的各个节点，提供聚合、高吞吐的并发SQL处理能力

• 高速链路互联

  • 数据库的计算节点和存储节点之间采用高速网络互联，并通过RDMA协议进行数据传输，使I/O性能不再成为瓶颈。

• 共享分布式存储

  • 多个计算节点共享一份数据，而不是每个计算节点都存储一份数据，极大地降低了用户的存储成本。基于全新打造的分布式块存储（Distributed Storage）和文件系统（Distributed Filesystem），存储容量可以在线平滑扩展，不会受到单个数据库服务器的存储容量限制，可应对上百TB级别的数据规模。

• 数据多副本、Parallel-Raft协议

  • 数据库存储节点的数据采用多副本形式，确保数据的可靠性，并通过Parallel-Raft协议保证数据的一致性。

整体架构图

自下而上来看，POLARDB由四部分组成

• 共享分布式存储PolarStore

• 分布式文件系统PolarFS

• 多节点的数据库集群PolarDB

• 提供统一入口的代理PolarProxy

分布式文件系统PolarFS

PolarFS设计中采用了如下技术以充分发挥I/O性能：

• PolarFS采用了绑定CPU的单线程有限状态机的方式处理I/O，避免了多线程I/O pipeline方式的上下文切换开销。

• PolarFS优化了内存的分配，采用MemoryPool减少内存对象构造和析构的开销，采用巨页来降低分页和TLB更新的开销。

• PolarFS通过中心加局部自治的结构，所有元数据均缓存在系统各部件的内存中，基本完全避免了额外的元数据I/O。

• PolarFS采用了全用户空间I/O栈，包括RDMA和SPDK，避免了内核网络栈和存储栈的开销。

在相同硬件环境下的对比测试，PolarFS中数据块3副本写入性能接近于单副本本地SSD的延迟性能。从而在保障数据可靠性的同时，极大地提升POLARDB的单实例TPS性能。

多接点数据库集群PolarDB

在数据库PolarDB中开创性地引入了物理日志（Redo Log）代替了传统的逻辑日志，不仅极大地提升了复制的效率和准确性，还节省了50%的 I/O 操作，对于有频繁写入或更新的数据库，性能可提升50%以上。

统一代理入口PolarProxy

PolarProxy存在的意义是可以把底层的多个计算节点的资源整合到一起，提供一个统一的入口，让应用程序访问，极大地降低了应用程序使用数据库的成本，也方便了从老系统到POLARDB的迁移和切换。本质上，PolarProxy是一个容量自适应的分布式无状态数据库代理集群，动态的横向扩展能力，可以将POLARDB快速增减读节点的优势发挥到极致，提升整个数据库集群的吞吐，访问它的ECS越多，并发越高，优势越明显。

存储与计算分离

POLARDB一个最大的特点是存储与计算分离，所谓分离就是计算节点（DB Engine）和存储节点（DB Store）在不同的物理服务器上，任何落地到存储设备的I/O操作均为网络I/O。

POLARDB的存储与计算分离的架构，除了可以降低存储成本，保证主备数据强一致、不丢数据之外，还带来了一个巨大的优势，就是让数据库的『弹性伸缩』变得极为简单、便捷。

做数据库弹性的挑战

• 首先，横向扩展难。数据库往往是业务系统的核心。数据必须流动、共享才有价值，因此在规模还不算很大的时候，数据库一般都是集中式部署，这样用起来简单，比如多个业务库的查询，一个SQL就出来了。所以，对于数据库很难通过横向增加服务器数量，达到线性的扩展能力。

• 其次，0宕机要求。数据库的核心地位决定了一旦数据库故障，整个业务就会瘫痪。因此数据库是一定要做高可用，屏蔽任何的硬件故障，来保障业务不间断。既要保障高可用，又要做弹性伸缩，就好像在高速飞行的飞机上换引擎，难度可想而知。

• 再次，数据比计算。数据库的本质是存数据，但数据本质上是存储在存储设备上的，当你发现存储设备I/O性能不够时，升级存储设备并不是一件容易的事。同样，假如数据和计算在同一台物理机时，这台物理机的CPU核数和主频，就决定了计算力的上限，很难扩容。

现在，当突破了存储与计算分离的性能瓶颈后，结合多节点共享同一份数据的架构设计，终于可以在数据库的弹性伸缩领域有了新的进展。

POLARDB的弹性优势

如上图，POLARDB是一个分层架构，从上层的代理PolarProxy提供了读写分离、SQL加速等功能，到中间的数据库引擎节点PolarDB构造了一写多读的数据库集群，再到底层的分布式存储PolarStore为上层提供多节点挂载的数据共享，每一层各司其职，共同构建了POLARDB云数据库集群。

从POLARDB产品定义上看，用户购买的节点数和规格大小（比如4核16G）指的是中间这一层PolarDB的配置，上层PolarProxy可以根据PolarDB的配置自适应调整，用户不需购买也不用关心性能和容量。底层PolarStore的容量是自动扩容，只须按照实际使用容量付费。

通常意义的扩展性，一般有纵向（Scale up）和横向（Scale out）和两种方式，纵向是指提升配置，横向是指配置不变，但增加节点。对于数据库来说，都是先纵向，比如4核不够升到8核。但终归会遇到瓶颈，一方面性能提升非线性，跟数据库引擎自身的设计和应用访问模型有关（比如MySQL的多线程设计，如果只有一个session，那么很难体现出多核的优势），另一方面，计算物理服务器配置有上限，存在天花板。因此终极手段还是横向扩展，增加节点数。

一句话概括，POLARDB横向最多可以到16个节点，纵向最高可到88核 ，存储容量动态扩展，毋须配置。

纵向扩展（升级/降级配置）

得益于存储与计算分离，我们可以单独升级或降级POLARDB数据库节点的配置，如果当前服务器资源不足，还可以快速地迁移到其他服务器，整个过程只需要5-10分钟（持续优化中），中间不需要任何的数据搬迁，只是如果涉及到跨机迁移，可能会有几十秒的连接闪断（未来，这个影响可以通过PolarProxy消除掉，升级对业务应用完全无影响）。

因为目前同一集群内的所有节点必须绑定升级，因此我们会采用非常柔和的Rolling Upgrade滚动升级的方式，通过控制升级的节奏、搭配主备切换来进一步减少不可用时间。

横向扩展（增/减节点）

由于存储是共享的，因此可以快速增加节点，而不需要任何的数据COPY。整个过程也只需要5-10分钟（持续优化中），如果是增加节点，对业务应用没有任何影响，如果是减少节点，那么仅对落到该节点执行的连接有影响，重练即可。

当增加节点之后，PolarProxy可以动态感知并自动加入到读写分离后端的读节点中，对于使用集群访问地址（读写分离地址）连接POLARDB的应用程序可以立马享受到更好的性能和吞吐。

毋须管理的存储空间

POLARDB的存储空间不需要关心，用多少付多少钱，每小时自动结算。

对于I/O能力，目前的设计是跟数据库节点的规格有关系，规格越大，IOPS和I/O吞吐量越高，在节点上对I/O有隔离和限制，避免多个数据库集群之间的I/O争抢。

本质上，数据是被保存在由大量服务器构成的存储池中，由于可靠性要求，每个数据块复制出3个副本，保存在不同机架的不同服务器上。存储池能够进行自我管理，动态扩容、平衡，避免存储碎片和数据热点。

典型场景

某位于北京的在线教育公司在云上部署了一个小学生在线答题考试系统，平时有5万到10万人在线，周末有20万，考试高峰期能达到50万到100万，数据规模500G以内。主要难点在于高用户并发访问，读写争用，I/O较高，如果一直买最高配置，成本又接受不了。通过使用POLARDB，借助快速弹性的能力，在高峰期临时增加数据库配置和集群规模，与之前的方案相比整体成本下降了70%。

物理复制

日志是数据库的重要组成部份，按顺序以增量的方式记录了数据库上所有的操作，日志模块的设计对于数据库的可靠性、稳定性和性能都非常重要。

• 可靠性方面，在有一个数据文件的基础全量备份后，对运行中的数据库来说，日志文件的重要性大于数据文件，只要操作记录到日志中并完成落盘，就等于操作完成，无须等待数据文件落盘。因为日志的顺序和增量方式，使得数据库的增量实时备份（包括备库）成为可能，更可以使用异步、同步或Raft多数等方式通过保护日志来保护所有的数据。

• 稳定性方面，日志的增量模式减少了需要写出的数据量，日志的顺序写对于IO操作十分友好，可以充分节约寻道时间（机械硬盘）和写入缓存，使得日志的写操作可以十分平稳，在面对高并发的事务时，不易出现剧烈的抖动，从而得到高的稳定性和性能。按照日志的组织形式，可以分为物理日志和逻辑日志，物理日志使用更偏向底层数据块操作的方式来描述变更，逻辑日志则偏向于使用记录镜像或SQL语句的方式来描述变更，事务引挚一般使用物理日志的模式来记录事务的底层操作，而非事务引挚则一般使用逻辑日志的方式。

用编程语言来打比方的话，物理日志相当于使用汇编语言来记录了操作，而逻辑日志则相当于使用Go/Python等级别的语言来记录操作，物理日志相比逻辑日志具有更高的可靠性、稳定性和性能。回顾数据库的历史，商业数据库都只支持物理日志，从来没有逻辑日志的说法。MySQL因为其上下分层（SQL层和引挚层）的设计导致事务存贮引挚层必须有独立的物理日志，以及多引挚支持的原因，必须在SQL层设计逻辑日志以透明化不同存储引挚（主备可以不同引挚）的支持，形成了一个双日志的现状，对MySQL的稳定性和性能带来了极大的困难和挑战。

物理日志因其格式比较底层，使其非常难以创建只读实例，并且从只读实例切换为读写实例需要比较长的时间，可以参考Oracel数据库的发展历程，长久以来一直没有支持随时只读的备库，将备库切换为主库需要极其严格的步骤，需要比较长的时间，比较难以实现自动化，无法轻松实现互联网读扩展流量扩展的需求。而逻辑日志因其格式比较上层，使其非常容易创建只读实例，从只读实例转换为读写实例可以在秒级完成，并形成了一整套的增量数据订阅消费。MySQL在享受逻辑复制好处时，也承受了逻辑复制带来的一些限制：

• 存储引挚层难以直接产生逻辑日志，为了数据的一致性，在物理日志和逻辑日志之间引入了XA（2PC）机制，给稳定性和性能带来了极大的限制和挑战，导致事务处理性能和传统商业数据库相比有较大差距，基于物理日志则差距极小。

• 同一事务的MySQL逻辑日志需要连续写出，因此无法支持较大的事务操作，过大的事务会导致操作失败。基于物理日志，同一个操作的日志可以分段（事务开始、操作1、操作2、事务提交）写出，因此可以支持大事务操作。

• MySQL现有逻辑日志保存了整条记录的前后镜象，造成逻辑日志写入量较大增加IO压力，易引起性能下降和抖动。物理日志只记录变化字段，格式紧凑以减少总日志量，具备较好的IO性能，不易引起性能下降和抖动，肯有更高的性能和稳定性。

• MySQL逻辑日志，在回入时需要重新经过SQL层代码，执行路径较长，并且不易并行处理，易造成备库时延，即逻辑日志产生的速度超过回放的速度；物理日志因包含完整事务信息，更易用事务一致性实现并行回放，可极大提升备库恢复的速度，做到高压力下主备ms级时延。如下图：

• MySQL逻辑日志，不包含事务信息，无法做连续性检测，可以从任意点开始恢复，不熟悉不专业的操作容易造成问题；物理日志包含完整事务信息，可以做连续性检测，会自动识别上一次的中断点，减少人工判断操作，可有效防止人为误操作。

因此基于逻辑复制的MySQL在大表加字段、建索引等操作上，主备复制的体验非常不够好。POLARDB在充分认识到MySQL逻辑复制的优缺点后，选择以物理复制为基础实现复制节点（Replica），提升了主备复制的效率和体验，为广大客户提供了稳定、可靠、高性能能的只读节点，引领了新一代复制技术的发展。

MySQL读写分离解决和引入的问题

用过MySQL的都知道，MySQL的主从复制简单易用，非常流行，通过把主库的Binlog异步地传输到备库并实时应用，一方面可以实现高可用，另一方面备库也可以提供查询，来减轻对主库的压力。

虽然备库可以提供查询，但存在两个问题：

• 一是主库和备库一般提供两个不同的访问地址，应用程序端需要选择使用哪一个，对应用有侵入。

• 二来MySQL的复制是异步的，即使是半同步也没办法做到100%强同步，因此备库的数据并不是最新的，有延迟，无法保证查询的一致性。

为了解决第一个问题，引入了读写分离代理，如下图，对应用程序非常友好。一般的实现是，代理会伪造成MySQL与应用程序建立好连接，解析发送进来的每一条SQL，如果是UPDATE、DELETE、INSERT、CREATE等写操作则直接发往主库，如果是SELECT则发送到备库。

但是第二个问题——延迟导致的查询不一致——还是没有解决，使用时，就不可避免地会遇到备库SELECT查询数据不一致的现象（因为主备有延迟）。MySQL负载低的时候延迟可以控制在5秒内，但当负载很高时，尤其是对大表做DDL（比如加字段）或者大批量插入的时候，延迟会非常严重。

POLARDB读写分离的会话读一致性

POLARDB是读写分离的架构，传统的读写分离都只提供最终一致性的保证，主从复制延迟会导致从不同节点查询到的结果不同，比如一个会话内连续执行以下QUERY：

INSERT INTO t1(id, price) VALUES(111, 96);
UPDATE t1 SET price = 100 WHERE id=111;
SELECT price FROM t1;

在读写分离的下，最后一个查询的结果是不确定的，因为读会发到只读库，在执行SELECT时之前的更新是否同步到了只读库时不确定的，因此结果也是不确定的；因为有这个问题，所以就要求应用程序去适应最终一致性，而一般的解决方法是： 将业务做拆分，有高一致性要求的请求直连到主库，可以接受最终一致性的部分走读写分离；显然这样会增加应用开发的负担，还会增大主库的压力，影响读写分离的效果；

为了解决这个问题，在POLARDB中我们提供了会话一致性或者说因果一致性的保证，会话一致性即保证同一个会话内，后面的请求一定能够看到此前更新所产生版本的数据或者比这个版本更新的数据，保证单调性，就很好的解决了上面这个例子里的问题；

实现原理

在POLARDB的链路中间层做读写分离的同时，中间层会track各个节点已经apply了的redolog位点即LSN，同时每次更新时会记录此次更新的位点为Session LSN, 当有新请求到来时我们会比较Session LSN 和当前各个节点的LSN，仅将请求发往LSN >= Session LSN的节点，从而保证了会话一致性；表面上看该方案可能导致主库压力大，但是因为POLARDB是物理复制，速度极快，在上述场景中，当更新完成后，返回客户端结果时复制就同步在进行，而当下一个读请求到来时主从极有可能已经完成，然后大多数应用场景都是读多写少，所以经验证在该机制下即保证了会话一致性，也保证了读写分离负载均衡的效果