本文通过描述关系型数据库发展的背景以及云计算的时代特征，分享了数据库计算力的螺旋式上升的进化理念。并且结合阿里云 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也采用了存储和计算分离的设计理念。
