ICDE:POLARDB定义云原生数据库

摘要： 4月17日（巴黎时间）阿里云POLARDB走出国门，亮相ICDE2018，并同步举办阿里云自有的POLARDB技术专场。在会上，阿里云进行了学术成果展现，从而推进Cloud Native DataBase成为行业标准。

 

4月17日（巴黎时间）阿里云POLARDB走出国门，亮相ICDE2018，并同步举办阿里云自有的POLARDB技术专场。在会上，阿里云进行了学术成果展现，从而推进Cloud Native DataBase成为行业标准。

 

如下为阿里云资深技术专家蔡松露演讲实录：

 

如今我给你们介绍一下咱们的云原生数据库-POLARDB。

你们可能要问到底什么是“云原生数据库”，云原生数据库的标准是什么，咱们是如何定义的以及为什么如此定义？如今，咱们先把这些问题放一边，咱们稍后回答。

如今咱们看一下一个云原生的数据库大概是什么样子，门槛是什么，特性是什么，首先，云原生数据库必须有优越的性能，有百万级别的QPS；其次，必须有超大规模的存储，可达到100TB的存储空间；在云上0宕机能力也是很是重要的；最后一个也是最重要的，云是一个生态系统，数据库必须兼容开源生态。

云原生数据库就像一辆跑车，一辆跑车可能有不少特性，好比外观、速度，可是一个有这样外观和速度的车不必定是跑车。因此回到咱们的问题，云原生数据库的标准是什么，在回答这个问题以前，咱们看一下数据库的发展历史。

我从4个维度来看一下数据库的发展历史，首先，从数据规模上来看，咱们生活在一个数据大爆炸的时代；其次，某些数据库理论发生了演变，尤为是CAP理论，咱们在算法理论上也有所突破；第三，用户和应用场景也在发生变化；第四，基础设施也在从传统IDC迁移到云上。

为何会有数据大爆炸呢？数据是如何爆炸的呢？这是我引用的互联网女王米克尔的报告，你能够看到，互联网历史能够总体分为三个阶段，第一阶段咱们称之为PC互联网，数据主要由PC产生，第二个阶段能够称之为移动互联网，数据主要由智能手机产生，第三个阶段是IoT，从如今开始，几乎全部的数据由物联网设备产生，多是你的手表、冰箱、家里的电灯和汽车，多是任何设备。

随着数据大爆炸，也带了不少挑战，大规模的数据意味着用于存储和分析数据的成本也大幅上升，搬运和分析数据也变得困难，总之，数据很难被利用。

最近这些年分布式系统的一些理论也有了重大变化，CAP就是其中之一，CAP理论在2000年引入，在这个理论中，C表明一致性，A表明可用性，P表明分区容错性，这个理论的核心观点是在P发生时C和A不可能同时被知足，CAP是一个伟大的理论，可是对CAP理论也存在不少误解，其中一个误解就是C和A是互斥的，因此有些系统选择放弃其中一个来知足另外一个，好比不少NoSQL数据库，可是实际上，C和A的关系不是0和1的关系，而是100%和99%的关系。

如今咱们也能够把P问题建模成A问题，P问题主要由网卡、交换机、错误的路由配置等故障引发，咱们考虑一下这样一个例子，一个节点由于网卡错误而被网络分区，到这个节点的请求会失败，若是咱们可以将这个节点自动剔除，那么请求会重试而且会被发送到一个健康的节点，事实上，当一个节点宕机的时候咱们也采用一样的处理方式，因此基本上，P和A问题在某些状况下能够看作是一类问题。

咱们如何把失败的节点自动剔除而且可以同时保障数据一致性呢？咱们能够用PAXOS算法来达到这个目的，PAXOS可以保证一致性，并且PAXOS只须要过半数的操做成功便可，因此当有网络分区、宕机、慢节点出现时，咱们能够容忍这些问题节点并作到自动剔除。若是超过半数节点被分红了若干个分区，这时咱们选择一致性牺牲可用性，可是在现实世界中这种状况极少发生，因此在大多数状况下，咱们能够经过将P问题建模成A问题来同时保证完整的C和A。

 

20年前，只有政府和一些巨头公司会选择数据库，如今从巨头到小微企业全部的业务都会跑在数据库上，并且对数据库的需求也在发生变化。

首先，数据库必须灵活，有时咱们须要作一个市场活动，好比黑色星期五，咱们不知道当天的真实流量，有时会有突发的热点信息，这时流量会有一个飙涨而且是不可预测的，咱们但愿数据库可以灵活地进行扩展；其次，随着全球化的发展，贸易也愈来愈透明，不少用户的业务规模比较小，意味着利润也不多，他们须要更经济的解决方案；目前的客户要求也比较严格而且对延迟很敏感，数据库延迟越低带给客户的损失会越小；最后，数据库必须对每个潜在的问题作到反应迅速，并能从问题状态中快速恢复过来。

总之，目前对数据库的潜在需求是：弹性、低成本、高性能、业务永续。

 

如今，全部的一切都是时刻在线的，在云时代之前，数据散落在IDC中，如今数据都位于数据湖中，数据会在线产生而且同时被应用到训练模型中，因此这些数据是在线产生、在线分析并在线应用；咱们的生活如今也是时刻在线的，好比衣食住行、工做、社交、娱乐等都是能够在线解决的，你能够用一部手机足不出户就能活下来；如今你的客户也是时刻在线的，他们遍及世界各地，不管白天仍是黑夜，一直在线。

 

在目前的中国，70%的新型企业都因数据挑战而对业务产生了影响，他们面临的问题主要有：高成本，他们负担不起商业license和专业的工程师；他们有很强的发展的意愿可是数据能力不够强；对他们来讲数据备份、数据挖掘和问题排查都是很是困难的事情；他们的数据目前像孤岛同样散落分隔在多个地方，数据没法作到在线并被浪费，可是数据在持续增加爆炸，这些数据很难被存储、转移、分析并使用

根据上述演变趋势和接踵而来的数据挑战，咱们认为一个云原生的数据库应该符合如下标准。

 

首先，一个云原生数据库不只是一个TP数据库，也是一个AP数据库，TP和AP融合在一块儿，咱们称之为HTAP，咱们从这种架构中获益良多；其次，云原生数据库必须是serverless的，有了serverless，咱们能够大幅削减成本；最后，云原生数据库必须是智能的，就像一个顾问，能够承担不少诊断和管理工做，经过这些工做咱们能够提高用户体验并让用户没必要再关心这些枯燥棘手的事情。

接下来咱们详细阐述一下。

在HTAP中TP和AP共享一份存储，对于分析来讲不存在任何数据延迟，因为不须要数据同步，咱们也没必要把数据从主节点同步到一个只读节点，这时数据是实时的，对于时延要求比较苛刻的应用来讲很是有益；当TP和AP共享一个存储以后，至少会省去1个副本的成本，对于计算层，AP和TP经过容器来进行隔离，因此AP对TP没有任何影响，并且有了这层隔离以后，TP和AP能够轻松作到分别扩展。

有了serverless，产品规格或版本升级时能够作到0成本，计算节点会跑在一个轻量的容器中，客户端会话的生命周期比较短，因此当咱们进行滚动升级时，客户端几乎感知不到任何变化；有了serverless能够轻松作到按需使用，按存储付费，计算成本也很低，而且你能够为不一样的业务模型指定不一样的存储策略，对于忙的业务，可使用更多的内存和SSD，对于闲置的业务，能够把数据放到HDD盘上，这样能够大幅缩减成本。

提到智能，智能顾问会分析实例产生的如CPU/存储/内存使用率和水位线等数据给你一个SQL或索引优化建议，在外人看来智能顾问就像是一个DBA，并把用户也武装成一个专业的DBA；当数据链路上有问题发生时，因为数据链路又长又复杂，因此咱们不清楚问题到底出在哪里，当咱们有一个监控和诊断系统后，咱们能够轻松地去诊断整个链路并迅速给出根本缘由；智能顾问也能负责其余如成本控制、安全、审计等职能。

在上述若干标准和门槛的指导下，咱们打造了一个全新的云原生数据库-POLARDB，我会从架构、产品设计、将来工做等几个方面全方位阐述一下POLARDB。

这是一个POLARDB的架构大图，上层是计算层，下层的存储层，存储和计算分离，他们中间经过RDMA高速网络相链接，全部的逻辑都运行在用户态，绕过了linux内核，在用户路径上，咱们实现了0拷贝，咱们同时实现了一个RAFT的变种ParellelRaft，它支持乱序提交，比传统的Raft速度要快不少；咱们同时使用了大量新硬件，既能够提高性能又能下降成本，POLARDB也是面向下一代硬件而设计。

对于计算节点，只有一个写入口，R/W节点负责全部类型的请求，包括读和写请求，其余节点都是只读节点，只能处理读请求，对于存储节点，咱们经过ParellelRaft算法来实现三副本一致性写。咱们为什么要作存储计算分离呢？首先，咱们能够为存储和计算阶段选取不一样类型的硬件，对于计算层，咱们主要关注CPU和内存性能，对于存储层，咱们主要关注低成本的存储实现，这样存储和计算节点都能作到定制化和针对性优化；分离以后计算节点是无状态的，变得易于迁移和failover，存储的复制和HA也能够获得针对性的提高；存储如今能够方便地池化，以块为单位进行管理，因此再也不会有碎片问题、不均衡问题，而且易于扩展；在这种架构下，也很容易实现serverless，当你的业务比较空闲时你甚至能够不须要任何计算节点。

 

在POLARDB中，任何逻辑都跑在用户态，一个请求从数据库引擎发出，而后PFS会把它映射成一组IO请求，而后PolarSwitch会把这些请求经过RDMA发送到存储层，而后ParellelRaft leader处理这些请求并经过SPDK持久化到磁盘上，同时再经过RDMA同步两份数据到两个followers，在整个路径上没有系统调用，也就没有上下文切换，同时也没有多余的数据拷贝，没有上下文切换加0拷贝使得POLARDB成为一个极快的数据库。

 

这是POALRDB文件系统-PFS的详细说明，PFS具备POSIX API，对数据库引擎侵入性很低，PFS是一个静态库并被连接到数据库进程中，PFS是一个分布式文件系统，文件系统的元数据经过PAXOS算法进行同步，因此PFS容许并行读写，为了访问加速，在数据库进程中有元数据的缓存，缓存经过版本控制来进行失效操做，为了便于你们理解PFS，这是PFS和传统文件系统的一个类比。

 

咱们使用ParellelRaft来同步三份数据，ParellelRaft是Raft的变种之一，Raft不容许乱序提交和日志空洞，这些限制让Raft性能比较低、吞吐比较小，在ParellelRaft中，咱们容许乱序提交、确认、和应用，事务的语义和串行化由数据库引擎层来负责，对于空洞咱们有一整套完整的catch-up机制，这是一个很是复杂的过程，在VLDB 2018的论文中，咱们有详细论述，这篇论文刚被接收。

 

在POLARDB中，咱们使用了一些新硬件并最大化利用这些硬件的能力，除了RDMA，咱们还在研究open-channel来最大化SSD的价值，咱们也在经过3D XPoint技术在加速存储层。

 

 

这是POLARDB和RDS的对比压测结果，咱们使用sysbench来进行压测，紫色的柱子表明POLARDB，粉色的表明RDS，经过这些数字能够看出，在使用相同资源的状况下，POLARDB的平均读性能是RDS的6倍，平均写性能是RDS的3倍，因此这个提高是巨大的。

 

咱们接下来看一下POLARDB的产品特色，性能上，很容易扩展到100W QPS，而且延迟小于2ms；存储最大支持100TB；弹性上，能够很方便作横向和纵向扩展，而且在规格升级时0宕机无干扰；对于兼容性，会100%兼容MySQL；在可用性上，当有错误发生时，咱们会选择一致性牺牲可用性，因此目前咱们承诺3个9的可用性，在数据可靠性上，咱们承诺5个9。

 

在POLARDB中，读和写被分离到不一样的节点上，只有一个写节点，写节点能够处理读写请求，能够有多个只读节点，写QPS最多可达13W，读QPS能够很方便地扩展到几百万。

 

对于可扩展性，全部节点均可以作纵向扩展，只读节点能够作横向扩展，实例的存储能够作纵向扩展，存储集群能够作横向扩展，当读写节点和只读节点之间作failover时能够作到0宕机。

 

 

对于数据迁移，你能够经过加载一个OSS（相似AWS S3）上的备份来启动你的数据库，也能够经过将POLARDB当成RDS的slave来从RDS实时复制数据，也能够利用DTS（data transfer service数据传输服务）来从RDS和其余数据库迁移到POLARDB。

 

对于数据可靠性，咱们能够作到1个region内可用区内多个可用区之间的failover，你能够在其余可用区启动一个standby实例而且使用redolog来进行复制，也能够在多个region之间failover，咱们一般使用binlog进行复制，对于备份，咱们能够秒级打出一个snapshot而后传输到OSS上。

 

下面是POLARDB的一些将来工做，目前POLARDB还只是个婴儿，咱们仍然有大量工做须要去作，在引擎层咱们将会支持多写，目前POLARDB是一个共享磁盘的架构，将来会是一个共享全部资源的架构，好比在计算层咱们会引入一个集中化Cache的角色来提高咱们的查询性能，咱们也在移植更多的数据库到POLARDB，好比更多的MySQL版本、PostgreSQL、DocumentDB等。在存储层，咱们会使用3D XPoint技术来提高IO性能，咱们也会经过open-channel技术在提高SSD性能，未来咱们也会将更多引擎层的逻辑进行下推，尽可能减小更多的IO，让计算层更加简单。

 

关于学术咱们的基本思想是：学术要在工程落地，工程要有学术产出，没有单纯的工程或者学术。咱们团队已经向Sigmod和VLDB提交了数篇论文，最近这些论文将会出版，你们会看到更多的关于POLARDB和它的分布式存储的详细的信息，咱们也正在欧洲进行招聘，咱们在巴黎和德国都设有办公室。

 

原文连接

阅读更多干货好文，请关注扫描如下二维码：