达摩院首席数据库科学家李飞飞：云原生新战场，我们如何把握先机？_多模 李飞飞

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

云时代的数据库将面临怎样的变革？云原生数据库有哪些独特优势？在 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 架构上做到多写多读而不是一写多读，实际上也就实现了 SharedEverything 。将 Shared nothing 和 Sharedstorage 架构进行结合的 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 是一个资源池，需要消耗内存，因此希望做到弹性自动调配每个实例里的 BufferSize。比如淘宝商品库的数据库实例晚上不需要那么大的 Buffer，那么就可以自动将其 Buffer Size 弹下来，到早上再自动弹上去，同时要求不影响其 RT。为了满足上述需求并进行自动Buffer 优化，阿里云数据库团队构建了 iBTune 系统，目前监控近 7000个数据库实例，通过长期运营，可平均节省20TB 内存。介绍 iBTune 项目的核心技术论文也发表在了今年的 VLDB 2019大会上。

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

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

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

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

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

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

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

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

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

原文链接
本文为云栖社区原创内容，未经允许不得转载。