本文介绍了关系型数据库的发展背景和云计算时代的特点，分享了数据库算力螺旋式增长的演进理念。发展路径阐述了自主研发的新一代云托管关系型数据库PolarDB的整体产品设计思路，并对部分关键技术点进行了解读。关系型数据库说到关系型数据库，在这个知识日新月异的TMT时代，听起来有点“古董”。这项IT技术起源于半个世纪前，其实一直处于现代社会科技的核心，支撑着当今世界。大多数商业技术文明。CPU、操作系统、数据库这三个核心领域基本上是IT时代的缩影，也是一切信息处理、计算能力、智能的基石。从1970年E.F.Codd发表里程碑式的论文“ARelationalModelofDataforLargeSharedDataBanks”，到20世纪80年代初期支持SQL的商业关系数据库DB2，Oracle的面世，SQL-Server的诞生在20世纪90年代初，是关系数据库成功的代表。今天，随着全球互联网的发展和大数据技术的广泛应用，越来越多的新型数据库应运而生，但关系型数据库仍然占据主导地位。主要原因之一是关系数据库采用SQL标准。这种先进的非过程编程接口语言将计算机科学和数据管理方法完美地联系起来，这些方法易于人类理解和识别。还是很难超越。SQL语言SQL（StructuredQueryLanguage）语言是一种介于关系代数和关系演算之间的结构化查询语言，由Boyce和Chamberlin于1974年提出，其本质是使用类似于自然语言的关键字和语法来定义和操作数据，执行可编程数据存储、查询和管理。这种抽象的编程接口将具体的数据问题从数据存储和查询实现的细节中解耦出来，使得信息管理的商业业务逻辑和计算模型能够被大量复制和应用，解放了生产力，极大地促进了商业关系数据库本身的发展.从SQL的不断发展和丰富来看，SQL已经成为关系数据库语言的标准和王者。时至今日，没有比这门编程语言更完美的替代品了。OLTP1976年，JimGray发表了一篇名为“GranularityofLocksandDegreesofConsistencyinaSharedDataBase”的论文，正式定义了数据库事务的概念和数据一致性的机制。OLTP是关系型数据库的典型应用，涉及到事务处理，主要是基本的、日常的事务处理，比如银行交易。事务处理需要遵循ACID的四个要素来保证数据的正确性，包括原子性、一致性、隔离性和持久性。衡量OLTP处理能力的性能指标主要有响应时间和吞吐量。开源数据库生态我们简单回顾一下关系型数据库的历史、现状和发展阶段，不难看出Oracle、SQL-Server、DB2等关系型数据库在全球商业数据库中依然占据主导地位。Informix和Sybase已经淡出了公众的视线。然而，从1990年代开始，另一种倡导知识共享和自由开放的软件精神成为一种趋势和趋势，尤其是以Linux、MySQL、PostgreSQL等为代表的开源软件，以强大的生命力不断发展壮大，发布这些无偿分享的技术红利，催生并推动了全球互联网高科技企业的快速发展。这就是整个人类社会的进步。我们要感谢那些开源软件的斗士，RichardStallman、LinusTorvalds、MichaelWidenius等。当然，近年来，越来越多积极参与主流开源社区的中国企业在中国涌现，他们也在不断地把技术分享回开源世界。根据DB-engines网站的最新统计，不难发现，开源数据库MySQL和PostgreSQL加在一起，开源数据库已经超越商业数据库Oracle，成为目前最流行的关系型数据库。世界。在云计算的现阶段，如果关系数据库是IT时代的产物。那么在互联网时代的云计算中，关系型数据库处于什么阶段呢？某种程度上，IT时代创造了更多的算力，互联网时代的云计算注重用户与算力的连接，提供了无处不在的算力。这其实就是云计算商业模式的成功，可以称之为1.0版本。云计算2.0版本需要在云环境下进行计算能力的再进化和升级。这种演进体现了社会算力的融合和计算资源能效的提升。为顺应绿色计算和共享经济的发展趋势，不仅需要云服务器、云数据库、网络互联、硬件芯片等软硬件系统的融合、演进和升级，更要坚持以需求为导向的技术和以用户为导向的服务。科技造福大众的理念进一步推动了计算效率和计算智能的提升。我们正处于蓬勃发展的云计算2.0阶段。这一阶段，关系型数据库在云托管环境中逐渐暴露出一些问题。作为云计算时代的先行者，亚马逊在2014年11月12日的AWSre:Invent2014大会上发布了Aurora云托管关系型数据库，解决了这些问题。这一新一代数据库的发布也预示着云计算时代的到来，传统IT技术的核心产品将拉开自我进化的序幕。在2017年SIGMOD数据大会上，亚马逊发布了论文《AmazonAurora:DesignConsiderationsforHighThroughputCloudNativeRelationalDatabases》，更加坦诚地解释了基于云的Cloud-Native设计的关系数据库是如何诞生的。.阿里云为什么要开发PolarDB？回顾关系数据库和云计算的背景，不难发现，云计算1.0虽然解决了连接用户和计算的问题，但还需要进一步解决共享计算环境下的问题。在此背景下，传统关系型数据库与公有云服务环境的融合。云计算1.0利用低成本、灵活快速的部署、弹性和扩展能力，获得从传统IT计算向云迁移的动力。在低成本享受普惠技术成为常态后，随着用户业务的增长，用户新的痛点开始显现，例如如何从根本上解决享受与传统IT同等甚至更好算力的问题以持续的低成本。云服务已成为迫切需求。这乍看像是一个伪命题，但仔细分析后，却淋漓尽致地体现了螺旋式上升的哲学思想。就像PC服务器出现的时代一样，PC服务器首先以低廉的价格提供了接近小型服务器的计算能力，然后在保持成本和性价比优势的基础上取得了超越小型服务器的性能优势，直到小型服务器的终结。服务器时代开启了PC服务器时代。因此，云计算时代还远未达到全盛时期，除非它通过自身的进化，在持续保持性价比优势的同时，基于快速、灵活、弹性的固有属性，拥有超越传统IT的能力计算能力、云计算真正进入它称霸的时代只是时间问题。也就是说，今天不仅仅是阿里云要做这样的关系型数据库，所有的云计算厂商都不可避免地要经历这样一个阶段。那就是传统IT算力在云计算时代的重构与进化！只是亚马逊走在前列，阿里云紧随其后，都需要经历进化到转型的过程。在这个过程中，新一代的关系型数据库是关键的里程碑之一。同理，未来应该会有越来越多更先进的云服务，比如智能云操作系统的出现，集成了为云时代设计的硬件芯片和网络互联。IT时代，传统算力（如使用关系型数据库处理结构化数据等）服务于系统硬件隔离环境下的多用户使用场景。云计算时代是多客户端Self-Service租用环境，各种计算负载场景更加复杂。在这种计算负载不断变化的环境下，如何解决IT时代的技术产品与云计算时代的应用环境之间的适配矛盾是一个难题。它是云计算自我进化的内在驱动力。例如，在公有云环境中，随着用户的增加，以及用户业务和数据的增长，备份、性能、迁移、升级、只读实例、磁盘容量、Binlog延迟等相关问题逐渐出现出现。这背后的大部分原因是由于I/O瓶颈（存储和网络），迫切需要通过技术创新和新的产品架构来解决。另一方面，在产品形态上，阿里云RDS目前的产品形态也有自己的优势，下节会详细介绍。但从产品架构开发的角度来看，除了数据库存储引擎的类型，对于关系型数据库，考虑工程效率和运维成本，最好有一个通用的产品技术架构，能够兼顾需求不同的用户场景。并不是每个场景都有对应的技术架构。在接下来的内容中，通过描述阿里云RDS不同产品形态的特点，我们会更加清楚的了解到，PolarDB的产品形态是在吸收了以往产品形态优点的基础上构思出来的。PolarDB的设计理念是基于用户需求和选择公有云自身开发为云托管关系型数据，以及关系型数据库的核心特性。PoalrDB更专注于如何提供满足用户业务需求的云服务，通过技术创新，不断演进，在提供更好的数据库计算能力的同时，满足用户的以下业务需求：上云成本，OLTP性能、业务连续性安全、在线业务扩展和数据安全。另一方面，除了云计算的成本优势，弹性和可扩展性也是云计算的天然属性。为了用户业务的扩展，更好的ScaleUp和故障恢复，计算和存储分离的架构成为云资源环境更好的选择。这一点在下一节RDS产品架构的演进中会进一步说明。阿里云RDS产品架构的演进如前所述，阿里云PolarDB和AmazonAurora数据库的演进方向相同，只是演进路径不同。这本身就是由各个数据库云服务的不同实现方式决定的。阿里云RDSMySQL有以下版本。这些产品形态满足不同的用户业务场景，具有不同的特点，可以相互补充。MySQL基础版MySQL基础版采用数据库计算节点和存储节点分离的方式，利用云盘数据本身的可靠性和多副本的特点，同时利用ECS云服务器虚拟化，提高标准化部署、版本和运行，维护。管理效率可以满足低端用户不太关注高可用服务的业务场景。同时，该架构在数据库迁移、数据扩容、计算节点扩容、计算节点故障恢复等方面具有天然优势。根本原因是计算和存储的分离。后面会提到，PolarDB也采用了存储和计算分离的设计理念。MySQL高可用版MySQL高可用版是面向企业用户的高可用数据库版本，提供99.95%的SLA保证。采用Active-Standby高可用架构，主备节点之间通过MySQLBinlog进行数据复制。当主节点出现故障时，备节点接管服务。同时还支持多个只读节点，支持负载均衡的数据读写分离访问方式。使用Shared-Nothing架构，计算和数据位于同一个节点上，通过数据的多副本确保最大性能，同时带来可靠性。MySQL金融版MySQL金融版可以说是一款专为金融行业高端用户设计的高可用、高可靠的云服务产品。它使用分布式Raft协议来保证数据的强一致性。容灾、备份等业务场景需求。PolarDB的演进PolarDB采用了存储和计算分离的技术架构，可以支持更多的只读节点。主节点和只读节点之间采用Active-ActiveFailover模式，充分利用计算节点资源。由于使用共享存储，相同的数据被共享，进一步降低了用户的使用成本。在下一节中，我们将更详细地描述PolarDB的主要特性。PolarDB在设计理念上有几大创新。一种是通过重新设计特定的文件系统来访问redolog特定的WALI/O数据，另一种是通过高速网络和高效协议将数据库文件和redolog文件放置在共享存储设备上，避免多次重复操作长路径I/O比Binlog更巧妙。此外，在DBServer的设计上，采用了完全兼容MySQL的思想，全面拥抱开源生态，从SQL编译、性能优化器、执行计划等方面都保留了传统关系型数据库的特性。并且针对Redolog的I/O路径，专门设计了一个多副本的共享存储块设备。我们知道，分布式数据库一直是数据库领域的热点，实现难度非常大。不管是遵循CAP理论还是BASE思想，一个通用的分布式关系数据库基本上很难在技术和商业上达到完美的平衡。兼容SQL标准和主流数据库，100%支持OLTPACID事务，99.99%高可用，高性能低延迟并发处理能力，弹性scaleup，scaleout扩展性，备份容灾和低成本迁移等.,能够完美平衡所有这些特性的商业关系型数据库还没有出现。阿里云PolarDB和AmazonAurora一个共同的设计理念是放弃对OLTP这种通用分布式数据库的多通道并发写入的支持，采用一次写入多次读取的架构设计，简化了理论模型，即在分布式系统中难以平衡，能够满足大部分OLTP的应用场景和性能需求。总之，100%的MySQL兼容性，加上专用的文件系统和共享存储块设备设计，以及下文提到的多项先进技术的应用，将使新一代关系型数据库PoalrDB在云时代大放异彩。.PolarDB产品技术要点分析介绍完阿里云RDS的不同产品形态，我们再来看一下PolarDB的产品架构。下图概括了PolarDB产品的主要模块，包括数据库服务器、文件系统、共享块存储等。PoalrDB产品架构如图所示，PolarDB产品是分布式集群架构设计。它融合了多项先进技术，实现了数据库OLTP处理性能的质的飞跃。PoalrDB采用存储计算分离的设计理念，满足公有云计算环境下用户业务弹性扩展的刚性需求。数据库计算节点和存储节点通过高速网络互联，通过RDMA协议进行数据传输，I/O性能不再是瓶颈。数据库节点采用完全兼容MySQL的设计。主节点和只读节点之间采用Active-ActiveFailover的方式提供DB的高可用服务。DB数据文件、redolog等通过User-Space用户态文件系统，通过块设备数据管理路由，依托高速网络和RDMA协议传输到远程ChunkServer。同时DBServer之间只需要同步Redolog相关的元数据信息。ChunkServer的数据采用多副本的方式保证数据的可靠性，通过Parallel-Raft协议保证数据的一致性。在描述了PolarDB的产品架构之后，我们将从分布式架构、数据库高可用、网络协议、存储块设备、文件系统和虚拟化等方面一一介绍PolarDB使用的关键技术点。SharedDisk架构分布式系统的本质在于拆分和组合。有时为了并发性能会拆分数据，但有时为了数据状态一致性又不得不合并，又或者因为分布式锁而不得不同步等待。PolarDB采用SharedDisk架构，根本原因就是上述计算和存储分离的需求。从逻辑上讲，DB数据是放在数据块存储服务器上的，所有DB服务器都可以共享和访问。在存储服务中，实际上是将数据切块，以达到通过多台服务器并发访问I/O的目的。PhysicalReplication我们知道MySQLBinlog记录的是Tuple行级别的数据变化。在InnoDB引擎层，需要支持事务ACID，同时维护一个redolog，根据文件的物理页存储修改。这样MySQL的一次事务处理默认至少需要调用两次fsync()进行日志持久化操作，直接影响事务处理的系统响应时间和吞吐性能。MySQL虽然通过GroupCommit机制提高了高并发下的吞吐量，但并不能完全消除I/O瓶颈。此外，由于单个数据库实例的计算和网络带宽有限，典型的做法是通过构建多个只读实例来分担读取负载。PolarDB通过将数据库文件和Redolog存储在共享存储设备上，非常巧妙地解决了只读节点和主节点的数据复制问题。由于数据共享，增加只读节点不需要全量数据复制，共享全量数据和redolog，只需要同步元数据信息，支持基本MVCC，保证数据读取的一致性。这使得系统在主节点故障并进行故障转移时，将切换到只读节点的故障转移时间缩短到30秒以内。进一步增强了系统的高可用能力。而且，只读节点和主节点之间的数据延迟也可以降低到毫秒级。从并发的角度来看，使用Binlog复制只能进行表级的并行复制，而物理复制只是基于数据页维度，粒度更细，并行效率更高。最后，引入Redolog实现Replication的好处是可以关闭Binlog减少对性能的影响，除非逻辑容灾备份或者数据迁移需要Binlog。总之，在I/O路径中，通常层次越低，越容易与上层的业务逻辑和状态解耦，降低系统的复杂度。而且，这种读写大文件的WALRedologI/O方式也非常适合分布式文件系统的并发机制，提高了PolarDB的并发读取性能。高速网络下的RDMA协议RDMA在HPC领域已经应用多年，现在正在云计算领域应用，这也印证了我的一个判断。云计算2.0时代，人们对??云计算的认知将被重建，云也能创造出超越传统IT技术的计算能力。这将是一个越来越严格的工业实现。RDMA通常需要支持高速网络连接的网络设备（如交换机、网卡等）通过特定的编程接口与NICDriver通信，然后通常使用Zero-Copy技术实现NIC中的数据与远程应用程序内存之间的高效低延迟传输不需要中断CPU将数据从内核态复制到应用程序态，这大大降低了性能抖动，提高了整个系统的处理能力。快照物理备份快照是一种流行的基于存储块设备的备份方案。其本质是利用Copy-On-Write机制记录块设备的元数据变化，对发生写操作的块设备进行写时复制，将写操作的内容更改为新复制的块设备实现回收。截至快照时间点的数据用途。快照是一种典型的基于时间和写入负载模型的后处理机制。也就是说，在创建Snapshot时，不备份数据，而是将备份数据的负载平均分配到Snapshot创建后实际写入数据的时间窗口，从而实现快速响应备份和恢复。PolarDB提供了一种基于Snapshot和Redolog的机制，比起传统的全量数据结合Binlog增量数据的恢复方式，更高效的按时间点恢复用户数据。Parallel-Raft算法谈到分布式数据库的事务一致性，我们很容易想到2PC（2PhasesCommit）和3PC（3PhasesCommit）协议。说到数据状态一致性，就不得不提LeslieLamport发明的Paxos协议。Paxos被Google等互联网厂商广泛应用于多个分布式系统后，Paxos成为最受关注的数据状态一致性算法之一。但由于Paxos算法论文理论和实现的复杂性，难以快速应用到工程技术中。Paxos解决的一个问题是，在多台机器的集合中，集合中任意一台初始状态相同的机器是否可以通过相同的命令序列到达相同的状态点，形成一个一致的收敛状态机。另一个问题是作为集群中的一员，通过微观时间串行通信的方式，需要找到一个永远有效的协议。当一台机器的某个数据状态需要发生变化时，需要与整个集群（包括其他机器）进行通信，依靠通信和协议来实现相同的认知，并在本机上认同某个状态的变化。基于这两点，基本解决了分布式集群架构下不同角色的机器达到一致状态机的问题。也可以进一步设计大多数分布式系统的框架。Paxos可以称为P2P（PeertoPeer）点对点设计，比较抽象和笼统，也比较难理解。Raft则是选举一个leader，然后通过leader发起其他角色的状态一致性更新，这样更容易理解。协议本身的实现过程与Paxos类似。Parallel-Raft是基于Raft协议改进的共识算法，针对PolarDBchunkServer的I/O模型。Raft协议基于连续日志。如果不提交log#n，则不允许提交后续日志。PolarDB实现的Parallel-Raft允许并行提交，打破了Raft的日志是连续的假设，提高并发性，通过额外的限制保证一致性。Docker容器虚拟化技术最早出现是Linux内核解决了操作系统之间或者进程运行过程中进程的迁移问题。通过进程与操作系统的解耦，可以实现进程的上下文和状态。用于保存、复制和恢复目的。然而，LXC的实现导致了曾经红极一时的Docker的诞生。原则上，容器虚拟化的实现比KVM等虚拟化技术更轻量级。如果用户不需要感知整个操作系统的功能，那么理论上容器虚拟化技术应该可以获得更好的计算能效比。事实上，LXC加Cgroup的进程虚拟化和资源隔离方式已经沿用多年，在HPC领域经常被应用在MPI超级任务的checkpoint和restartrecovery上。PolarDB采用Docker环境运行DB计算节点，采用更轻量级的虚拟化方式解决资源隔离和性能隔离，同时也节省了系统资源。User-Spacefilesystem说到文件系统就不得不提IEEE发明的POSIX语义（POSIX.1已经被ISO接受），就像谈数据库时谈SQL标准一样。实现通用分布式文件系统最大的挑战是在完全兼容POSIX标准的基础上，提供强大的并发文件读写性能。但是POSIX兼容性必然会牺牲一些性能来获得对该标准的全面支持，同时系统实现的复杂度也会大大增加。归根结底，是通用设计与专有设计的取舍与区别，以及易用性和性能的平衡。这是一个经典问题。分布式文件系统是IT行业最经久不衰的技术。从HPC时代、云计算时代、互联网时代、大数据时代，它一直在创新。其实更严格的说，针对不同的应用I/O场景，应该会有很多的定制。实现现代化，说白了就是不支持POSIX标准。在这一点上只能说是退无可退，但是当它只服务于特殊的I/O场景时，POSIX不适用并不是问题。这与从SQL到NoSQL的发展如出一辙。支持POSIX的文件系统需要实现兼容标准文件读写操作的系统调用接口，这样用户就不需要修改POSIX接口实现的文件操作应用程序。这就需要通过LinuxVFS层来铆接具体的文件系统内核实现。这也是增加文件系统工程难度的原因之一。对于分布式文件系统，内核模块还必须与用户态Daemon交换数据，实现数据分片，通过Daemon进程传递给其他机器。用户空间文件系统为用户提供专用的API。它不需要完全兼容POSIX标准，也不需要在操作系统内核中进行系统调用的1:1映射，直接在用户态实现文件系统元数据管理和数据读写访问。支持够了，实现难度大大降低，更有利于分布式系统中的进程间通信。总结：通过上面的介绍不难发现，PolarDB从计算虚拟化、高速网络互联、存储块设备、分布式文件系统、数据库物理复制等全方位的技术手段，可以是据说是众多热门技术中的第一个。集。正是这些关键技术的融合与创新，使得PolarDB的性能有了质的飞跃。【本文为专栏作者《阿里巴巴官方技术》原创稿件，转载请联系原作者】点此查看作者更多好文
