云计算大潮来袭，传统数据库市场正面临重新洗牌，包括云数据库在内的一批新生力量崛起，动摇了传统数据库的垄断地位，而由云厂商主导的云原生数据库则将这种“改变”推向了高潮。

　　云时代的数据库将面临怎样的变革?云原生数据库有哪些独特优势?在日前的DTCC 2019大会上，阿里巴巴集团副总裁、达摩院数据库首席科学家、阿里云智能事业群数据库产品事业部总负责人李飞飞博士就《下一代云原生数据库技术与趋势》进行了精彩分享。他表示，云原生数据库因其突出优势，应用趋势不断上升。

　　李飞飞(花名：飞刀)，阿里巴巴集团副总裁，高级研究员，达摩院首席数据科学家，阿里云智能事业群数据库产品事业部负责人，ACM杰出科学家。

　　大势所趋 云数据库市场份额增速迅猛

　　如下图所示的是Gartner关于全球数据库市场份额的报告，该报告指出目前全球数据库市场份额大约为400亿美金，其中中国数据库市场份额占比为3.7%，大约为14亿美金。

　　具体到数据库市场分布，传统五大数据库厂商Oracle、Microsoft、IBM、SAP、Teradata占比达到了80%，云数据库的份额占比接近10%，并且云数据库市场份额占比每年也在快速增长，因此Oracle、MongoDB等也在大力布局其在云数据库市场的竞争态势。

　　根据DB-Engines数据库市场分析显示，数据库系统正朝着多样化、多元化的方向发展，从传统的TP关系型数据库发展到今天的多源异构的数据库形态。目前处于主流位置的还是大家耳熟能详的数据库系统，比如商业数据库Oracle、SQL Server以及开源的MySQL、PostgreSQL等。而一些比较新的数据库系统，比如MongoDB、Redis则开辟了一个新的赛道。数据库License的传统销售方式在逐渐走下坡路，而开源以及云上数据库License的流行程度却在不断提升。

　　数据库: 云上应用关键一环

　　正如AWS创始人Jeff Bezos所说：“The real battle will be in databases”。因为云最早是从IaaS做起来的，从虚拟机、存储、网络，到现在如火如荼的语音识别、计算机视觉以及机器人等智能化应用，都是基于IaaS的，而数据库就是连接IaaS与智能化应用SaaS最为关键的一环。从数据产生、存储到消费的各个环节，数据库都至关重要。

　　数据库主要包括四大板块，即OLTP、OLAP、NoSQL以及数据库服务和管理类工具，也是云数据库厂商发力的四个方向。对于OLTP而言，技术发展已经历经了40年，而到如今大家还在做的一件事情就是“加10元和减10元”，也就是所谓的事务处理。当数据量变得越来越大和读写冲突的原因，对数据进行在线实时分析的需求衍生出了OLAP。由于需要Scale out，而数据强一致性不能够得到保证，就有了NoSQL。而最近又出现了一个新名词——NewSQL，这是因为NoSQL也有所不足，故将传统OLTP的ACID保证与NoSQL的Scale out能力进行了整合，变成了NewSQL。

　　数据库系统架构演进：All depends on what is shared

　　纵观数据库40年来的发展历史，从最早的关系型数据库时期，衍生出了SQL、OLTP等技术;到数据量急剧增长，需要避免读写冲突，通过ETL、数据仓库以及Data Cube等技术实现了OLAP;再到今天，面对异构多源的数据结构，从图到时序、时空到向量等，也就诞生了NoSQL、NewSQL等数据库，同时也出现了一些新的技术，比如Multi-Model和HTAP等。

　　数据库系统最为主流的架构是Shared Memory：共享处理器内核，共享内存并且具有共享的本地磁盘，这样的单机架构属于非常主流的架构，传统的数据库厂商基本采用的也是这样的架构。

　　而随着互联网企业的大规模发展，如Google、Amazon以及阿里巴巴，大家发现原来的单机架构有很多限制，其可扩展性以及吞吐量无法满足业务发展需求，于是就衍生出了Shared Disk/Storage架构，即共享存储架构。也就是说数据库底层可能是分布式存储，通过利用RDMA这样的快速网络让上层的数据库内核看起来像是在使用本地的磁盘，但实际上是分布式存储。上面可以有多个独立计算节点，一般是一写多读，但是也可以做多写多读，这就是共享存储架构，其中比较典型的代表就是阿里云的PolarDB数据库。

　　另外一种架构是Shared Nothing。共享存储虽然有诸多优点，其解决了很多问题，但是RDMA网络也存在很多的限制，比如其跨越Switch甚至是跨AZ和Region的时候性能都会有所损失。分布式的共享存储达到一定的节点数量之后，性能会出现一定的损耗，所以不能保证访问远程数据和访问本地数据的性能完全相同，所以共享存储的架构当扩展到十几个节点之后就达到了scale out扩展的上限了。此时，如果应用需要继续扩展怎么办呢?那就需要实现分布式架构了，比较典型的就是Google Spanner，其利用原子钟技术能够实现跨数据中心的数据一致性和事务一致性。而在阿里云，基于PolarDB实现的分布式版本POLARDB-X采用的也是Shared Nothing架构。

　　这里需要注意的一点就是：Shared Nothing和Shared Storage可以结合。可以在上层做Shared Nothing，而对于下层的Shard分片采用Shared Storage架构。这样混合架构的好处在于能够减轻分出太多Shard的痛点问题，减少分布式事务distributed commit的概率，因为distributed commit的代价非常昂贵。

　　总结三种架构设计，如果在Shared Storage架构上做到多写多读而不是一写多读，实际上也就实现了Shared Everything。将Shared nothing和Shared storage架构进行结合的hybrid架构应该是后续数据库系统发展方向的一个重要突破点。

　　云原生数据库核心四要素

　　上面从架构方面分析了云时代的主流数据库架构。从技术上来讲，除了架构上的不同，云原生时代还有一些不同点。

　　多模(Multi-model)

　　其一是多模(Multi-model)，多模主要有两种，即北向和南向。南向表示存储结构是多种多样的，数据结构可以是结构化的也可以是非结构化的，可以是图、向量、文档等，但对于用户只提供一个SQL的查询接口或者SQL-Like的接口，这部分业界比较典型的就是各种各样的数据湖服务。而北向的多模就是存储只有一种，一般是通过KV存储数据形态来支持结构化、半结构化以及非结构化数据，但希望能够提供不同的查询接口，比如SPARQL、SQL、GQL等。业界典型的代表是微软Azure的CosmosDB。

　　数据库智能化+自动化管控平台

　　数据库的自治化也是非常重要的发展方向，从数据库的内核以及管控平台两个角度都有很多技术点可以做。在数据库自治化部分，阿里巴巴认为，需要做到自感知、自决策、自恢复以及自优化。自优化比较简单，就是在内核中利用机器学习的方法来进行优化。而自感知、自决策、自恢复更多的是针对管控平台的，比如如何保证实例的巡检，当出现问题后如何能够自动快速修复或者自动切换等。

　　新硬件: 软硬件一体化设计

　　云原生数据库的第三大核心点是软硬件一体化设计。数据库首先是一个系统，而系统就需要能够安全高效的使用有限的硬件资源。所以数据库系统的设计和发展一定是和硬件性能和发展紧密相关的，我们不能够面对硬件的变化而坚持旧有数据库设计不改变，比如NVM出来之后就可能对传统的数据库设计有一些冲击。而新硬件所带来的变化也是数据库系统设计需要考虑的。RDMA、NVM以及GPU/FPGA等新硬件或者架构的出现，对于数据库的设计都会提供新的思路。

　　高可用

　　高可用是云原生最基本的要求之一，上云的用户势必不希望业务出现中断。高可用最简单的解决方案就是冗余，可以做Table级别的冗余，也可以做Partition级别的冗余。无论是使用哪一种，基本上都是三副本，甚至更多的时候需要做四副本或者五副本，比如金融级别的高可用可能需要做两地三中心或者两地四中心。

　　对于高可用的多副本而言，如何保证副本之间的数据一致性?在数据库里面有一个经典的CAP理论，其理论结果是在Consistency、Availability和Partition Tolerant三者之间只能选择两个。现在大家的一般选择都是C+P，同时对于A而言，通过三副本技术和分布式一致性协议，使得A达到6个9或者7个9，这样基本上就做到了100%的CAP。

　　云原生数据库PolarDB：极致弹性+兼容性 为海量数据和海量并发而生

　　前面介绍了数据库市场背景和云原生数据库的基本要素，接下来我将结合阿里云PolarDB以及AnalyticDB两款数据库系统，分享以上技术的具体落地情况。PolarDB是阿里云的云原生数据库，目前已有非常深厚的技术积累。我们在VLDB 2018，SIGMOD 2019等国际学术会议上发表了相关论文，主要介绍存储引擎等方面的技术创新。

　　PolarDB采用共享存储架构，一写多读。共享存储架构有多个优势，首先是计算和存储分离，计算节点和存储节点可以分开实现弹性缩扩容;其次，PolarDB突破了MySQL、PG等数据库对于单节点规格和可扩展性的限定，能够实现100TB存储容量以及每个节点100万QPS的性能; 此外，PolarDB能够提供极致的弹性能力，备份恢复能力也有很大提升。在存储层，每个数据块都采用三副本高可用技术，同时对于Raft协议进行了修改，通过实现并行式的Raft协议保证了三副本数据块之间的数据一致性，提供了金融级高可用。PolarDB还能做到100%兼容MySQL 以及PG等数据库生态，可以帮助用户实现无感知的应用迁移。

　　由于底层是共享的分布式存储，PolarDB属于Active-Active的架构，主节点负责写入数据，从节点负责读取数据，因此对于进入数据库的事务而言，主备节点都处于Active状态，其好处在于通过一份物理存储避免了在主从之间不停地做数据同步。

　　具体而言，PolarDB有一个PolarProxy，也就是前面的网关代理，下面有PolarDB的内核以及PolarFS，最下面对接的是PolarStore，利用RDMA网络管理底层的分布式共享存储。PolarProxy会对客户需求做分发，将写请求分配到主节点，而对于读请求而言，则会根据负载均衡以及读节点的状态实现对于读请求的分配，这样就能够尽可能地实现资源的最大化利用以及性能的提升。

　　PolarDB共享存储采用分布式+三副本。其中Primary节点负责写，其他节点负责读，其下层是PolarStore，每部分都会有三副本的备份，通过分布式一致性协议保证数据一致性。这样设计的优势在于能够实现存储与计算分离，同时能够做到无锁备份，所以备份可做到秒级。

　　在一写多读的情况下，PolarDB能够实现快速伸缩。举例而言，从2核vCPU升级到32核或者从两个节点扩展到4个节点，都能够在5分钟之内生效。存储和计算分离能够带来的另一大好处是降低成本，因为存储和计算节点可以独立地进行弹性伸缩，充分体现成本优势。

　　下图展示了PolarDB如何利用物理日志实现持续恢复。左侧是传统数据库的架构，而在PolarDB里面，由于采用了共享存储，因此可基本保留类似传统数据库利用物理日志进行恢复的过程，通过共享存储实现持续恢复，做事务的Snapshot恢复。

　　对比一下，如果MySQL做主备架构，首先需要在主库里面有一个逻辑日志和物理日志，在备库里面要重放主库的逻辑日志，然后再按照主库的方式做逻辑日志和物理日志。而在PolarDB里面，因为是共享存储，可直接通过一份日志实现数据恢复，备库能够直接将所需要的数据恢复出来，而不需要去重放主库的逻辑日志。

　　PolarDB一写多读集群的另一大优势是动态DDL的支持。在MySQL架构下，如要对数据的Schema进行修改，需要通过Binlog去Replay到备库，因此备库会存在Blocking的阶段，需要一定时间Replay动态的DDL。而在PolarDB共享存储架构下，所有Schema信息以及metadata均以表的形式直接存储在存储引擎里面，只要主库改完了，那么备库的元信息也实时同步更新，因此不会存在Blocking的过程。

　　PolarDB的Proxy最主要的作用就是做读写分离、负载均衡、高可用切换以及安全防护等。PolarDB是一写多读架构，当请求进来之后，需要进行读写的判断，将写请求分发到写节点，将读请求分发到读节点上去，并且对于读请求做一定的负载均衡。这样就能保证会话的一致性，并且彻底解决了读不到最新数据的问题。

　　无损弹性是PolarDB监控的模块之一。分布式存储需要知道分配多少磁盘量/Chunk，PolarDB会监控未使用的Chunk量。比如当可用量低于30%的时候，就会在后台自动地对其进行扩容，这使得应用基本不受影响，可连续写数据。

　　对于云数据库PolarDB而言，以上技术带来的最大优势是极致的弹性。这里我们以一个具体的客户案例进行说明。如下图所示，红线部分指离线资源的消耗情况，这些成本是客户无论如何都需要付出的，而其上面的部分则是计算资源的需求。

　　比如客户在3、4月有新品上市，5月还有促销活动，这两个时期计算需求会非常大。如按照传统架构方式，可能需要在新品上市之前就将容量弹到更大的规模，并且保持这样的水位，到了后面的促销阶段又需要弹到更高的规格，成本非常高昂。但如果能够做到极致弹性，比如PolarDB的存储与计算分离，实现快速弹性扩容，那么用户就只需在蓝色方块出现之前将容量弹上去，之后再弹下来即可，这样就能大幅降低成本。

　　除了云原生数据库PolarDB，阿里云数据库团队在其他方向还有众多探索。

　　分布式版本POLARDB-X: 高并发+跨域高可用 支持水平拓展

　　如果企业需要极致的Scale out能力，像阿里巴巴以及传统行业中的银行、电力等对高并发、海量数据支撑要求极高的用户，共享存储架构只能支持弹至十几个节点，肯定是不够的。因此，阿里云数据库团队也采用Shared Nothing做水平拓展，将Shared Nothing与Shared Storage相结合，形成POLARDB-X。POLARDB-X支持金融级跨可用区数据强一致, 对支持海量数据下的高并发事务处理有着极好的性能表现。目前，POLARDB-X在阿里内部已上线应用，利用存储计算分离、硬件加速、分布式事务处理和分布式查询优化等技术，成功支持了在双11这样的场景下阿里巴巴所有业务核心链路数据库洪峰的挑战，我们后续将推出商业化版本，敬请期待。

　　OLAP数据库标杆——AnalyticDB：海量数据 实时高并发在线分析

　　此外在OLAP分析型数据库方向，阿里云数据库团队自主研发了数据库产品——AnalyticDB，在阿里云的公有云和专有云上均有售卖。AnalyticDB拥有几大核心架构特点：

　　行列混存引擎，能够支持高吞吐写入和高并发查询;

　　支持海量数据处理，对于海量数据能实现秒级分析，完美支持多表、中文以及复杂分析;

　　利用向量化技术，支持结构化数据和非结构化数据的融合处理。。

　　近日，AnalyticDB打榜TPC-DS，在性价比方面达到了全球先进，通过了TPC官方的严苛认证。同时，介绍AnalyticDB系统的论文即将在VLDB 2019会议上展现。AnalyticDB的常用应用场景是从OLTP应用我们的数据传输与同步工具DTS至AnalyticDB进行实时的数据分析。

　　自治数据库平台：智能调参上线iBTune (individualized Buffer Tuning)

　　云原生数据库的特点之一是自治化，阿里云内部有个平台叫SDDP(Self-Driving Database Platform——自治化数据库平台)，SDDP会对各个数据库实例进行实时的性能数据采集，并使用机器学习方法建模进行实时调配。

　　iBTune的基本思想是，每个数据库实例都包含一个Buffer Size，传统数据库里面的Buffer Size是提前分配好的，不能变化。而在大型企业里，Buffer是一个资源池，需要消耗内存，因此希望做到弹性自动调配每个实例里的Buffer Size。比如淘宝商品库的数据库实例晚上不需要那么大的Buffer，那么就可以自动将其Buffer Size弹下来，到早上再自动弹上去，同时要求不影响其RT。为了满足上述需求并进行自动Buffer优化，阿里云数据库团队构建了iBTune系统，目前监控近7000个数据库实例，通过长期运营，可平均节省20TB内存。介绍iBTune项目的核心技术论文也发表在了今年的VLDB 2019大会上。

　　安全上云是关键 多重加密护航数据安全

　　云上的数据安全是非常重要的内容，阿里云数据库团队在数据安全方面也做了大量的工作。首先，数据落盘加密，在数据存储的时候就进行加密。此外，阿里云数据库也支持BYOK，用户可以将自己的密钥拿到云上来实现落盘加密以及传输级别的加密。未来，阿里云数据库还将在内存处理时实现全程加密，对日志实现可信验证等。

　　阿里云企业级数据库云服务：全方位运维 全链路布局

　　阿里云数据库按照工具产品、引擎产品以及运营管控的全程数据库产品分类提供服务。下图展现的是阿里云——云数据库常用链路，通过DTS工具将线下数据库迁移到线上，基于数据需求/分类，分发至关系型数据库、图数据库以及AnalyticDB等。

　　阿里云数据库：客户第一 一切价值来自于服务用户

　　目前PolarDB数据库的增势迅猛，已经服务于通用行业、互联网金融、游戏、教育、新零售、多媒体等多个领域的龙头企业。

　　而AnalyticDB在分析型数据库市场也有非常出众的表现，支持实时分析以及可视化应用。

　　基于阿里云数据库技术，阿里巴巴支持了城市大脑等一系列关键项目及云上云下的大量客户。截止目前为止，阿里云数据库已经累计支持了近40万数据库实例成功上云。

　　云原生是数据库的新战场，它为发展了40多年的数据库行业带来了许多令人激动的新挑战和新机遇，阿里巴巴希望与国内外数据库行业的各位技术同仁一起，将数据库技术推向更高的境界。