本文通过描述关系型数据库发展的背景以及云计算的时代特征，分享了数据库计算力的螺旋式上升的进化理念，另外结合阿里云 RDS 产品的发展路径，阐述了自主研发的新一代云托管关系型数据库 PolarDB 的产品整体设计思想，对一些关键技术点进行了解读。
关系型数据库
谈到关系型数据库，在这个知识日新月异的 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，成为世界上最流行的关系型数据库。
云计算当前的阶段
如果说关系型数据库是 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 设计的关系型数据库是如何应孕而生的。
为什么阿里云研发 PolarDB ?
在我们回顾了关系型数据库以及云计算的背景之后，我们不难发现, 云计算 1.0 虽然解决了用户和计算的连接的问题，但是还需要进一步解决在一个共享计算的环境下，传统关系型数据库和公有云服务环境的融合问题。
云计算 1.0 用低廉的成本，灵活快速的部署、弹性和扩展能力，获得了传统 IT 计算上云的转换动力。在低成本享受普惠科技成为常态之后，随着用户业务的增长，用户新的痛点开始出现，例如，如何从根本上解决用持续低的成本，享受和传统 IT 计算力一样，甚至更好的云服务，成为迫切需要。
这初看起来像伪命题，仔细分析之后，却淋漓尽致的体现了螺旋式上升的哲学思想。就好像在 PC 服务器涌现的时代，PC 服务器首先用低廉的价格提供了和小型服务器接近的计算能力，然后在保持成本和性价比优势的基础上，实现了超越小型服务器的性能优势，直至终结了小型服务器时代，开始了 PC 服务器时代。
所以说云计算时代还远远没有到达鼎盛时期，除非它通过自身进化演变，在不断保持性价比优势的同时，在具有快速灵活弹性的内在属性基础上，拥有超过传统 IT 计算力的能力之后，云计算才会真正进入它所主宰的时代，这只是个时间问题。
也就是说今天不只是阿里云要做这样一款关系型数据库，而是所有的云计算厂商都不可避免的要经历这样一个阶段。那就是云计算时代传统 IT 计算力的重建和进化!只不过 Amazon 走在了最前面，而阿里云紧跟其后，都需要经历这进化到蜕变的过程。
在这个过程中，新一代关系型数据库是关键的里程碑之一。同理，接下来应该有更多更加高级的云服务，比如智能云操作系统出现，来融合为云时代设计的硬件芯片和网络互联等等。
在 IT 时代，传统的计算力(例如用关系型数据库来处理结构化数据等)是服务于系统硬件隔离环境下的多用户使用场景的。而云计算时代是多客户 Self-Service 租用环境，各种计算负载场景更加复杂，在这种计算负载变迁的环境下，如何解决 IT 时代的技术产物和云计算时代应用环境的适配矛盾，正是云计算自我进化的内在推动力。
例如，在公有云环境下，随着用户的增多，以及用户业务和数据的增长，备份、性能、迁移、升级、只读实例、磁盘容量、Binlog 延迟等相关问题渐渐显现出来。这背后大部分原因是由于 I/O 瓶颈(存储和网络)导致，亟须通过技术革新以及新的产品架构解决这个问题。另一方面，从产品形态来讲，阿里云 RDS 目前的产品形态各具优势，在下一节会详细介绍。
但是从产品架构的发展来看，除去数据库存储引擎的类型之外，对于关系型数据库，考虑到工程效率以及运维成本，最好有一种通用的产品技术架构能兼顾不同用户场景的需求，而不是针对每一个场景都实现一种对应的技术架构。
在接下来的内容，通过讲述阿里云 RDS 的不同产品形态的特点，我们会更加清晰的了解到，PolarDB 的产品形态正是在吸收了之前几种产品形态的优点而孕育而生的。
PolarDB 的设计思想
用户需求和公有云自身发展的选择
作为云托管的关系型数据，除了关系型数据库的核心特征之外。PoalrDB 更多的关注于如何提供满足用户业务需求的云服务，并且通过技术革新，不断进化，在提供更好的数据库计算力的同时，满足用户以下业务需求：上云成本、OLTP 性能、业务连续性、在线业务扩展、数据安全。
另一方面云计算除了成本优势之外，弹性和可扩展性也是云计算的天然属性。为了用户业务的扩展，更好的 Scale Up 以及故障恢复，计算和存储分离的架构成为云资源环境更好的选择。这一点将在下一节 RDS 产品架构的演进中得到进一步的诠释。
阿里云 RDS 产品架构的演进
如上所述，阿里云 PolarDB 和 Amazon Aurora 数据库进化的方向是一致的，然而进化的路径各有不同。本身来讲，这是由于各自的数据库云服务实现方式不同所决定的。阿里云 RDS MySQL 有如下几个版本。这些产品形态满足不同的用户业务场景，具有不同的特点，可以进行优势互补。
MySQL 基础版
MySQL 基础版采用数据库计算节点和存储节点分离的方式，利用云盘数据本身的可靠性和多副本的特性，同时也利用了 ECS 云服务器虚拟化来提升标准化部署、版本和运维的管理效率，能够满足低端用户不太注重高可用服务的业务场景。
同时这种架构对于数据库的迁移，数据容量的扩容，计算节点的 Scale Up，计算节点故障恢复都有天然的优势，根本原因就是计算和存储的分离。后面也会讲到，PolarDB 也采用了存储和计算分离的设计理念。
MySQL 高可用版
MySQL 高可用版则是针对企业级用户提供的高可用数据库版本，提供 99.95% 的 SLA 保障。采用 Active-Standby 的高可用架构，主节点和备节点之间通过 MySQL Binlog 进行数据的 Replication。当主节点发生故障，备节点接管服务。
同时还支持多个只读节点，支持负载均衡的数据读写分离的访问方式。采用 Shared-Nothing 架构，计算和数据位于同一个节点，最大程度保障性能的同时又通过数据的多副本带来可靠性。
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 在云时代必将大放异彩。
PolarDB 产品关键技术点剖析
在讲述了阿里云 RDS 的不同产品形态之后，我们再从整体上看一看 PolarDB 的产品架构。下图勾画了 PolarDB 产品的主要模块，包括数据库服务器，文件系统，共享块存储等。
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 的性能有了质的飞跃。
【本文为51CTO专栏作者“阿里巴巴官方技术”原创稿件，转载请联系原作者】
