| 本文通过描述关系型数据库发展的背景以及云计算的时代特征，分享了数据库计算力的螺旋式上升的进化理念。并且结合阿里云
RDS 产品的发展路径，阐述了自主研发的新一代云托管关系型数据库 PolarDB 的产品整体设计思想，同时也对一些关键技术点进行了解读。
1. 背景
关系型数据库
谈到关系型数据库，在这个知识日新月异的TMT时代，听起来有些“古董”，这个起源于半个世纪以前的IT技术，事实上一直处于现代社会科技的核心，支撑着当今世界绝大多数的商业科技文明。CPU、操作系统、数据库这三大核心领域，基本上就是IT时代的缩影，同时也是一切信息化处理、计算力和智能化的基石。从1970年E.F.Codd发表了一篇里程碑论文“A
Relational Model of Data for Large Shared Data Banks”，到80年代初期支持SQL的商用关系型数据库DB2，Oracle的面市，以及90年代初SQL-Server的诞生，都是关系型数据库成功的代表。
时至今日，随着全球互联网的发展，大数据技术的广泛应用，涌现出越来越多的新型数据库，然而关系型数据库仍然占据主导地位。最主要的原因之一就是关系型数据库采用了SQL标准，这种高级的非过程化编程接口语言，将计算机科学和易于人类理解认知的数据管理方式完美的衔接在了一起，目前还难以超越。
SQL语言
SQL(Structured Query Language)语言是1974年由Boyce和Chamberlin提出的一种介于关系代数与关系演算之间的结构化查询语言，其本质是用一种类似于自然语言的关键字和语法来定义和操作数据，进行可编程的数据存储、查询以及管理。这种抽象编程接口，将具体的数据问题与数据的存放、查询实现的细节解耦开来，使得商业业务逻辑以及信息管理的计算模式能够被大量复制和应用，解放了生产力，也极大的促进了商业化关系型数据库自身的发展。从SQL后来不断发展和丰富来看，SQL已经成为关系型数据库语言的标准和王者。到今天这种编程语言还没有更加完美的替代品。
OLTP
1976年，Jim Gray发表了名为"Granularity of Locks and
Degrees of Consistency in a Shared DataBase"的论文，正式定义了数据库事务的概念和数据一致性的机制。而OLTP是关系型数据库涉及事务处理的典型应用，主要是基本的、日常的事务处理，例如银行交易。事务处理需要遵循ACID四个要素来保证数据的正确性，包括原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。而衡量OLTP处理能力的性能指标主要有响应时间、吞吐率等。
开源数据库生态
在我们简要的回顾了关系型数据库的历史、地位和发展阶段后，我们不难看到Oracle、SQL-Server、DB2等关系型数据库仍然占据着全球商业数据库的主导地位，虽然曾经耳熟能详的Informix、Sybase已经淡出大众的视线。然而，从20世纪90年代开始，另一股推崇知识分享、自由开放的软件精神成为趋势和潮流，尤其以Linux、MySQL、PostgreSQL等为代表的开源软件，开始以强大的生命力不断发展壮大，释放出巨大的社会进步力量，这些被自由分享的科技红利，孕育和促进了全球互联网高科技公司的飞速发展。这是整个人类社会的进步，我们要感谢那些开源软件的斗士们，Richard
Stallman，Linus Torvalds，Michael Widenius等。当然，最近几年国内涌现出越来越多积极参与到开源主流社区的中国公司，也在不断地将技术分享回馈给开源世界。
根据DB-engines网站的最新统计，不难发现，当把开源数据库MySQL和PostgreSQL加在一起，开源数据库就已经超越了商业数据库Oracle，成为世界上最流行的关系型数据库。
2. 云计算当前的阶段
如果说关系型数据库是IT时代的产物。那么在互联网时代的云计算，关系型数据库目前正处于一个什么阶段呢？IT时代从某种程度上讲，更多是创造了计算力，那么进入互联网时代的云计算，则是专注于用户和计算力的连接，提供无处不在的计算力，这个其实是云计算商业模式的成功所在，可以称之为1.0版本。而云计算2.0版本，需要在云环境下，重新进化和升级计算力，这种进化体现了社会计算力的整合以及计算资源能效的进步。为了顺应绿色计算以及共享经济的发展潮流，不仅仅需要云服务器，云数据库，网络互联，硬件芯片等等各个软硬件系统领域的融合以及演进升级，还需要坚持科技以需求为本、服务以用户为根的科技普惠大众的理念来进一步促进计算效率和计算智能的提高。
我们正处在一个蓬勃发展的云计算2.0阶段。在这个阶段，关系型数据库在云托管环境逐渐暴露出一些问题，作为在云计算时代的先行者，Amazon于2014年11月12日
的AWS re:Invent 2014大会，发布Aurora云托管关系型数据库就是为了解决这些问题。这个新一代的数据库的发布，也昭示着云计算时代，传统的IT技术核心产品将揭开自我进化的序幕。而2017年SIGMOD数据大会，
Amazon 发布了论文”Amazon Aurora: Design Considerations
for High Throughput Cloud Native Relational Databases”,更加开放的解释了基于云环境的Cloud-Native设计的关系型数据库是如何应孕而生的。
3. 为什么阿里云要研发新一代的关系型数据库PolarDB ?
在我们回顾了关系型数据库以及云计算的背景之后，我们不难发现, 云计算1.0虽然解决了用户和计算的连接的问题，但是还需要进一步解决在一个共享计算的环境下，传统关系型数据库和公有云服务环境的融合问题。
云计算1.0用低廉的成本，灵活快速的部署、弹性和扩展能力，获得了传统IT计算上云的转换动力。在低成本享受普惠科技成为常态之后，随着用户业务的增长，用户新的痛点开始出现，例如，如何从根本上解决用持续低的成本，享受和传统IT计算力一样，甚至更好的云服务，成为迫切需要。这初看起来像伪命题，仔细分析之后，却淋漓尽致的体现了螺旋式上升的哲学思想。就好像在PC服务器涌现的时代，PC服务器首先用低廉的价格提供了和小型服务器接近的计算能力，然后在保持成本和性价比优势的基础上，实现了超越小型服务器的性能优势，直至终结了小型服务器时代，开始了PC服务器时代。
所以说云计算时代还远远没有到达鼎盛时期，除非它通过自身进化演变，在不断保持性价比优势的同时，在具有快速灵活弹性的内在属性基础上，拥有超过传统IT计算力的能力之后，云计算才会真正进入它所主宰的时代，这只是个时间问题。
也就是说今天不只是阿里云要做这样一款关系型数据库，而是所有的云计算厂商都不可避免的要经历这样一个阶段。那就是云计算时代传统IT计算力的重建和进化！只不过Amazon走在了最前面，而阿里云紧跟其后，都需要经历这进化到蜕变的过程。在这个过程中，新一代关系型数据库是关键的里程碑之一。同理，接下来应该有更多更加高级的云服务，比如智能云操作系统出现，来融合为云时代设计的硬件芯片和网络互联等等。
在IT时代，传统的计算力（例如用关系型数据库来处理结构化数据等）是服务于系统硬件隔离环境下的多用户使用场景的。而云计算时代是多客户Self-Service租用环境，各种计算负载场景更加复杂，在这种计算负载变迁的环境下，如何解决IT时代的技术产物和云计算时代应用环境的适配矛盾，正是云计算自我进化的内在推动力。
例如，在公有云环境下，随着用户的增多，以及用户业务和数据的增长，备份、性能、迁移、升级、只读实例、磁盘容量、Binlog延迟等相关问题渐渐显现出来。这背后大部分原因是由于I/O瓶颈（存储和网络）导致，亟须通过技术革新以及新的产品架构解决这个问题。另一方面，从产品形态来讲，阿里云RDS目前的产品形态各具优势，在下一节会详细介绍。但是从产品架构的发展来看，除去数据库存储引擎的类型之外，对于关系型数据库，考虑到工程效率以及运维成本，最好有一种通用的产品技术架构能兼顾不同用户场景的需求，而不是针对每一个场景都实现一种对应的技术架构。
在接下来的内容，通过讲述阿里云RDS的不同产品形态的特点，我们会更加清晰的了解到，PolarDB的产品形态正是在吸收了之前几种产品形态的优点而孕育而生的。
4. PolarDB的设计思想
用户需求和公有云自身发展的选择
作为云托管的关系型数据，除了关系型数据库的核心特征之外。PoalrDB更多的关注于如何提供满足用户业务需求的云服务，并且通过技术革新，不断进化，在提供更好的数据库计算力的同时，满足用户的如下业务需求：
上云成本
OLTP性能
业务连续性
在线业务扩展
数据安全
另一方面云计算除了成本优势之外，弹性和可扩展性也是云计算的天然属性。为了用户业务的扩展，更好的Scale
Up以及故障恢复，计算和存储分离的架构成为云资源环境更好的选择。这一点将在下一节RDS产品架构的演进中得到进一步的诠释。
阿里云RDS产品架构的演进
如上所述，阿里云PolarDB和Amazon Aurora数据库进化的方向是一致的，然而进化的路径各有不同。本身来讲，这是由于各自的数据库云服务实现方式不同所决定的。阿里云RDS
MySQL有如下几个版本。这些产品形态满足不同的用户业务场景，具有不同的特点，可以进行优势互补。
1. MySQL基础版
MySQL基础版采用数据库计算节点和存储节点分离的方式，利用云盘数据本身的可靠性和多副本的特性，同时也利用了ECS云服务器虚拟化来提升标准化部署、版本和运维的管理效率，能够满足低端用户不太注重高可用服务的业务场景。同时这种架构对于数据库的迁移，数据容量的扩容，计算节点的Scale
Up，计算节点故障恢复都有天然的优势，根本原因就是计算和存储的分离。后面也会讲到，PolarDB也采用了存储和计算分离的设计理念。
2. MySQL高可用版
MySQL高可用版则是针对企业级用户提供的高可用数据库版本，提供99.95%的SLA保障。采用Active-Standby的高可用架构，主节点和备节点之间通过MySQL
Binlog进行数据的Replication。当主节点发生故障，备节点接管服务。同时还支持多个只读节点，支持负载均衡的数据读写分离的访问方式。采用Shared-Nothing架构，计算和数据位于同一个节点，最大程度保障性能的同时又通过数据的多副本带来可靠性。
3. MySQL金融版
MySQL金融版可以说是针对金融行业等高端用户设计的高可用、高可靠云服务产品，采用分布式Raft协议来保证数据的强一致性，拥有更加优异的故障恢复时间，更加满足数据容灾备份等业务场景的需求。
PolarDB的进化
PolarDB采用存储与计算分离的技术架构，同时可以支持更多的只读节点。主节点和只读节点之间是Active-Active的Failover方式，计算节点资源得到充分利用，由于使用共享存储，共享同一份数据，进一步降低了用户的使用成本。下一节我们将进一步从细节上描述PolarDB的关键特性。
PolarDB的设计思想有几个大的革新。一是通过重新设计特定的文件系统来存取Redo log这种特定的WAL
I/O数据，二是通过高速网络和高效协议将数据库文件和Redo log文件放在共享存储设备上，避免了多次长路径I/O的重复操作，相比较Binlog这种方式更加巧妙。另外在DB
Server设计上，采用MySQL完全兼容的思路，完全拥抱开源生态，从SQL的编译、性能优化器和执行计划等等都保留了传统关系型数据库的特色。并且针对Redolog的I/O路径，专门设计了多副本共享存储块设备。
我们知道，分布式数据库一直是数据库领域的热点，具有非常大的实现难度。不管是遵循CAP理论，还是BASE思想，通用的分布式关系型数据库基本上很难做到技术和商用的完美平衡。与SQL标准以及主流数据库兼容，OLTP
ACID事务100%支持，99.99%的高可用，高性能低延迟并发处理能力，弹性Scale Up，Scale
out可扩展性，备份容灾和低成本迁移等等，能够完美兼顾所有这些特点的商用关系型数据库还没有出现。
阿里云PolarDB和Amazon Aurora的一个共同设计哲学就是，放弃了通用分布式数据库OLTP多路并发写的支持，采用一写多读的架构设计，简化了分布式系统难以兼顾的理论模型，又能满足绝大多数OLTP的应用场景和性能要求。总之，100%
MySQL的兼容性，加上专用的文件系统和共享存储块设备设计，以及在下文中提到的多项高级技术的应用，使得新一代关系型数据库PoalrDB在云时代必将大放异彩。
5. PolarDB产品关键技术点剖析
在讲述了阿里云RDS的不同产品形态之后，我们再从整体上看一看PolarDB的产品架构。下图勾画了PolarDB产品的主要模块，包括数据库服务器，文件系统，共享块存储等。
PoalrDB产品架构
阿里云关系型数据库PoalrDB集群
如图所示，PolarDB产品是一个分布式集群架构的设计。它集众多高级的技术实现于一身，使得数据库OLTP处理性能有了质的飞跃。PoalrDB采用了存储与计算分离的设计理念，满足公有云计算环境下用户业务弹性扩展的刚性需求。数据库计算节点和存储节点之间采用高速网络互联，并通过RDMA协议进行数据传输，使得I/O性能不在成为瓶颈。
数据库节点采用和MySQL完全兼容的设计。主节点和只读节点之间采用Active-Active的Failover方式，提供DB的高可用服务。DB的数据文件、redolog等通过User-Space用户态文件系统，经过块设备数据管理路由，依靠高速网络和RDMA协议传输到远端的Chunk
Server。同时DB Server之间仅需同步Redo log相关的元数据信息。Chunk Server的数据采用多副本确保数据的可靠性，并通过Parallel-Raft协议保证数据的一致性。
在描述了PolarDB的产品架构之后，我们再分别从分布式架构，数据库高可用，网络协议，存储块设备，文件系统和虚拟化等方面逐一介绍下PolarDB使用的关键技术点。
Shared Disk架构
分布式系统的精髓就在于分分合合，有时候为了并发性能进行数据切分，而有时候为了数据状态的一致性而不得不合，或者由于分布式锁而不得不同步等待。
PolarDB采用Shared Disk架构，其根本原因是上述的计算与存储分离的需要。逻辑上DB数据都放在所有DB
server都能够共享访问的数据chunk存储服务器上。而在存储服务内部，实际上数据被切块成chunk来达到通过多个服务器并发访问I/O的目的。
物理Replication
我们知道，MySQL Binlog记录的是Tuple行级别的数据变更。而在InnoDB引擎层，需要支持事务ACID，也维持了一份Redo日志，存储的是基于文件物理页面的修改。这样MySQL的一个事务处理默认至少需要调用两次fsync()进行日志的持久化操作，这对事务处理的系统响应时间和吞吐性能造成了直接的影响。尽管MySQL采用了Group
Commit的机制来提升高并发下的吞吐量，但并不能完全消除I/O瓶颈。
此外，由于单个数据库实例的计算和网络带宽有限，一种典型的做法是通过搭建多个只读实例分担读负载来实现Scale
out。PolarDB通过将数据库文件以及Redolog等存放在共享存储设备上，非常讨巧的解决了只读节点和主节点的数据Replication问题。由于数据共享，只读节点的增加无需再进行数据的完全复制，共用一份全量数据和Redo
log，只需要同步元数据信息，支持基本的MVCC，保证数据读取的一致性即可。这使得系统在主节点发生故障进行Failover时候，切换到只读节点的故障恢复时间能缩短到30秒以内。系统的高可用能力进一步得到增强。而且，只读节点和主节点之间的数据延迟也可以降低到毫秒级别。
从并发的角度来看，使用Binlog复制现在只能按照表级别并行复制，而物理复制只按照数据页维度，粒度更细，并行效率更加高。
最后一点，引入Redolog来实现Replication的好处是，Binlog是可以关闭来减少对性能的影响，除非需要Binlog来用于逻辑上的容灾备份或者数据迁移。
总之，在I/O路径中，通常越往底层做，越容易和上层的业务逻辑和状态解耦而降低系统复杂度。而且这种WAL
Redo log大文件读写的I/O方式也非常适用于分布式文件系统的并发机制，为PolarDB带来并发读性能的提高。
高速网络下的RDMA协议
RDMA之前是在HPC领域被使用多年的技术手段，现在开始被使用到云计算领域，也证实我的一个判断。云计算2.0时代，将重建人们对于云计算的认识，云端也能够创造超越传统IT技术的计算力，这将是一个越来越严谨的工业实现。
RDMA通常是需要有支持高速网络连接的网络设备（如交换机，NIC等），通过特定的编程接口，来和NIC
Driver进行通讯，然后通常以Zero-Copy的技术以达到数据在NIC和远端应用内存之间高效率低延迟传递，而不用通过中断CPU的方式来进行数据从内核态到应用态的拷贝，极大的降低了性能的抖动，提高了整体系统的处理能力。
Snapshot物理备份
Snapshot是一种流行的基于存储块设备的备份方案。其本质是采用Copy-On-Write的机制，通过记录块设备的元数据变化，对于发生写操作的块设备进行写时复制，将写操作内容改动到新复制出的块设备上，来实现恢复到快照时间点的数据的目的。Snapshot是一个典型的基于时间以及写负载模型的后置处理机制。也就是说创建Snapshot时，并没有备份数据，而是把备份数据的负载均分到创建Snapshot之后的实际数据写发生的时间窗口，以此实现备份、恢复的快速响应。PolarDB提供基于Snapshot以及Redo
log的机制，在按时间点恢复用户数据的功能上，比传统的全量数据结合Binlog增量数据的恢复方式更加高效。
Parallel-Raft算法
谈到分布式数据库的事务一致性，我们很容易想到2PC（2 Phases Commit），3PC（3
Phases Commit）协议。而论数据状态一致性，我们就不得不提到Leslie Lamport发明的Paxos协议，在Paxos为Google等互联网厂商所广泛应用到多个分布式系统实现之后，Paxos成为了最受关注的数据状态一致性算法之一。可是由于Paxos算法论文的理论和实现过于复杂，导致难以被快速应用到工程技术上。Paxos解决的问题之一是，在多个机器的集合中，集合中初始状态相同的任何机器能否通过相同的命令序列到达同样相同的状态点，形成一个一致的收敛的状态机。另一个问题是，作为集群中的一员，通过微观的时间串行通讯方式，需要找到一个始终有效的协议，当一个机器的某个数据状态需要改变时，需要和整个集群（包括其他机器）靠通讯和协议达成相同的认知，一起认同这个机器上的某个状态的改变。
基于这两点，基本上就解决了分布式集群架构中，不同角色的机器，达成一致性状态机的问题。也就可以进一步设计出绝大多数分布式系统的框架。Paxos可以堪称是P2P（Peer
to Peer）的对等设计，更加抽象和通用，也更难以理解。而Raft则是选举出Leader，再经由Leader发起对其他角色进行状态一致性更新的实现，更容易理解。而协议本身的实现流程和Paxos有相似之处。
Parallel-Raft是在Raft协议的基础上，针对PolarDB chunk Server的I/O模型，进行改良的一致性算法。Raft协议基于Log是连续的，log#n没有提交的话，后面的Log不允许提交。而PolarDB实现的Parallel-Raft允许并行的提交，打破了Raft的log是连续的假设，提高并发度，通过额外的限制来确保一致性。
Docker
容器虚拟化技术最早的出现是Linux内核为了解决进程在操作系统之间，或者在进程运行过程当中做迁移，通过进程和操作系统之间的解耦，来达到进程运行时的上下文和状态能够保存，复制和恢复的目的。可是LXC的实现，却促成了曾红极一时的Docker的诞生。
从原理上讲，容器虚拟化的实现相对于KVM等虚拟化技术而言，更加轻量级。如果用户不需要感知整个操作系统的功能，那么用容器虚拟化技术理论上应该能够获得更好的计算能效比。其实LXC加上Cgroup这种进程虚拟和资源隔离的方式已经被使用很多年，在HPC领域就常被应用到MPI超级任务的checkpoint和restart恢复上。PolarDB采用Docker环境来运行DB计算节点，用更轻量的虚拟化方式，解决了资源的隔离和性能的隔离，也节省了系统资源。
User-Space文件系统
谈到文件系统，就不得不提一下IEEE发明的POSIX语义（POSIX.1已经被ISO所接受），就像说到数据库要谈到SQL标准。通用分布式文件系统实现的最大挑战就是在完全兼容POSIX标准的基础上提供强劲的并发文件读写性能。可是POSIX的兼容势必会牺牲一部分性能来获得对于标准的完全支持，同时系统实现的复杂度也极大的增加。说到底是通用设计和专有设计的取舍和区别，也是易用性和性能之间的平衡，这是个经典问题。分布式文件系统是IT行业最经久不衰的技术，从HPC时代，云计算时代，互联网时代，大数据时代一直在推陈出新，其实更严格的说应该是针对不同应用I/O场景涌现出很多定制化的实现，再说白点，就是不去支持POSIX标准。
这一点上，只能说知难而退，不过只服务于专门的I/O场景时，不适用POSIX也不是什么问题。这一点，和从SQL到NoSQL的发展如出一辙。支持POSIX的文件系统，需要实现兼容标准的文件读写操作的系统调用接口，这样对于用户而言，就无需修改POSIX接口实现的文件操作应用程序。这样一来就要求通过Linux
VFS层来铆接具体的文件系统内核实现。这也是导致文件系统工程实现难度加大的原因之一。
对于分布式文件系统而言，内核模块还必须和用户态的Daemon进行数据交换，以达到数据分片以及通过Daemon进程传送到其他机器上的目的。而User-Space文件系统提供用户使用的专用API，不用完全兼容POSIX标准，也无需在操作系统内核进行系统调用的1:1mapping对接，直接在用户态实现文件系统的元数据管理和数据读写访问支持即可，实现难度大大降低，并且更加有利于分布式系统的进程间通讯。
小结：通过以上的介绍，我们不难发现，PolarDB采用了从计算虚拟化，高速网络互联，存储块设备，分布式文件系统，数据库物理Replication等全方位的技术手段，可以说是众多热点技术的集大成。正式这些关键技术的整合创新，才使得PolarDB的性能有了质的飞跃。 |
