盘点 | 主流云原生数据库技术方案 -6parkbbs.com

原标题：盘点 | 主流云原生数据库技术方案

作者：柯煜昌顾问软件工程师 6park.com

目前从事 RadonDB 容器化研发，华中科技大学研究生毕业，有多年的数据库内核开发经验。 6park.com

作者：柯煜昌顾问软件工程师 6park.com

目前从事 RadonDB 容器化研发，华中科技大学研究生毕业，有多年的数据库内核开发经验。 6park.com

你将 Pick 这些内容： 6park.com

云原生的概念 6park.com

云原生数据库的概念 6park.com

两种主流技术路线分析 6park.com

六种云原生数据库方案和功能介绍 6park.com

云原生数据库的核心功能和价值 6park.com

随着云计算的蓬勃发展，IT 应用转向云端，云服务出现如下若干特点： 6park.com

提供按需服务； 6park.com

用户只愿支付运营费用而不愿支付资产费用； 6park.com

云服务提供商集群规模越来越大，甚至遍布全球，集群达到云级规模（Cloud-Scale）。 6park.com

根据以上特点，要求云产品需要提供一定 “弹性”（Elastic），而且达到云级规模；节点故障如同 “噪声”一样不可避免，这又要求云服务有一定的 “自愈”（Resilience）能力。 6park.com

起初，通过借助 IaaS，直接将传统的数据库 “搬迁” 到云上，于是出现了关系型数据库服务（RDS）。这样虽然能部分实现 “弹性” 与 “自愈”，但是这种方案存在资源利用率低，维护成本高，可用性低等问题。于是，设计适应云特点的云原生数据库就至关重要。 6park.com

RDS 的挑战 6park.com

以 MySQL 为例，如果要实现高可用或者读写分离集群，则需要搭建 binlog 复制集群。 6park.com

图 1：MySQL 复制架构 6park.com

如上图所示，除了页写入与 double write，redo log 写入操作外，还有 binlog 与 relay log 的写入。 6park.com

缺陷
说明

写放大严重
如果以上架构中，FileSystem 部署在分布式文件系统中，页的写操作，会因为副本复制的机制将 IO 放大，最后 IO 延迟也会放大。

资源浪费严重
1. binlog 复制是为了适配 MySQL 所有存储引擎，属于逻辑复制。本质是将 SQL 在从实例执行（除了没有主实例的锁争用外，其他代价几乎一样），效率不高，也浪费了 CPU 与内存的资源。 2. 扩展集群的计算能力时，不得不同时扩展存储空间，导致磁盘资源的浪费。

备份恢复慢
无论是物理备份/恢复，还是逻辑备份/恢复，备份操作均会上锁，影响正常业务进行，并且，备份恢复的时间也随着存储容量的增大而线性增长。

扩展代价大
1. 新增从实例，首先要从备份中恢复数据，然后应用binlog以达到与主实例一致的状态。这个过程耗时取决于恢复的时间以及binlog日志应用的时间，数据量大、数据状态过时的情况下，耗时费力而且不保证正确。弹性能力有限。2. 存储容量受限于单机存储容量，无法自由扩展。

可用性低
Aurora [1 ] 指出，在高规模的集群环境中，软件或者硬件故障如同“背景噪声”那样不可避免，并且缩短平均故障间隔时间（MTTF）是非常困难的，可行的方法是减少平均恢复的时间（MTTR）从而达到高可用性。如上所示，RDS 仍然是传统的备份恢复的方法修复故障，如果数据量大的话，可能是数小时，超过平均故障时间间隔（Aurora 是 10s），出现更多节点故障，可能使得共识算法无效（超过半数），可用性就大大打折扣。

运维成本高
备份/恢复与扩展，均需要专业 DBA 团队运维，每个步骤出现错误需要人工检查。

6park.com

云原生数据库简介 6park.com

为了解决以上问题，需要针对云上服务的特点，改造或者开发新一代云数据库，这便是云原生数据库。 6park.com

特点
说明

计算存储分离
对存储与计算进行解耦合，实现存储与计算分离。

无状态
计算节点无状态或较少状态。

存储集群灵巧化
采用小存储块方式组织副本，用以减少平均恢复时间，多副本共识算法，实现存储的高可用与故障“自愈”能力。

6park.com

通过解耦合与少状态，计算节点扩展就会很轻量，扩展速度近乎进程启动的速度。避免扩展计算资源的时候，不得不浪费存储资源的窘境。 6park.com

解耦合也使得存储节点也少了一定的约束，可以使用成熟的分布式存储技术实现灵巧化，降低运维成本提高可用性。 6park.com

接下来将介绍目前两种主流的技术路线和几种知名的方案。 6park.com

1 Spanner 类 6park.com

以 Google 的 Spanner [2 ] 为代表，基于云原生开发全新的数据库。受其影响，产生了CockrochDB、TiDB、YugabyteDB 等产品。 6park.com

1.1 架构 6park.com

以 TiDB [3 ] 架构图为例： 6park.com

图 2：TiDB 架构图 6park.com

总体来说，此类产品其特点都是在 key-value 存储基础上包装一层分布式 SQL 执行引擎，使用 2PC 提交或者其变种方案实现事务处理能力。计算节点是 SQL 执行引擎，可以彻底实现无状态，本质是一个分布式数据库。 6park.com

1.2 存储高可用性 6park.com

Spanner 将表拆分为 tablet，以 tablet 为单位使用多副本 + Paxos 算法实现。 6park.com

TiDB 为 Region 为单位使用多副本 + Multi-Raft 算法，而 CockroachDB 则采用 Range 为单位进行多副本，共识算法也是使用 Raft。 6park.com

Spanner 中 key-value 持久化方案，逻辑上仍然是基于日志复制的状态机模型（log-replicated state machines）上再加共识算法实现。 6park.com

图 3：multi-Raft 存储架构 6park.com

1.3 优缺点 6park.com

说明

优点

彻底的 Share-Nothing
号称全球部署
使用 key-value 结构与 LSM 树，以及日志复制自动机机制，天然无写放大效应
不需要人为分库分表，有很好的横向扩展能力

缺点

全新开发工作量大，技术不算成熟
性能不佳
事务处理能力有限

在内存中处理事务冲突，有冲突的需要读写等待或者提交等待。
如：Spanner 对有冲突的事务 TPS 能力最大只有 125

SQL 支持能力有限

如：YugabyteDB 不支持 Join 语句

6park.com

2 Aurora 类 6park.com

Aurora 是亚马逊推出的云原生数据库。与 Google 的技术路线不同，Aurora 是传统的 MySQL（PostgreSQL）等数据库进行计算与存储分离改造，进而实现云原生的需求，但其本质仍然是单体数据库的读写分离集群。 6park.com

Aurora 论文对 Spanner 的事务处理能力并不满意，认为它是为 Google 重读（read-heavy）负载定制的数据库系统 [1 ] 。这种方案得到一些数据库厂商的认同，出现了微软 Socrates、阿里PolarDB、腾讯 CynosDB、极数云舟 ArkDB 以及华为 TarusDB 云原生数据库等。 6park.com

2.1 架构 6park.com

Aurora 架构如下： 6park.com

图 4：Aurora 架构 6park.com

下图绿色部分为日志流向。 6park.com

图 5：Aurora 网络 IO 6park.com

由于传统数据库持久化最小单位是一个物理页，哪怕修改一行，持久化仍然是一个页，加上需要写 redo 日志与 undo 记录，本身就存在一定的写放大问题。如果机械的将文件系统替换成使用分布式文件系统，并且为了实现高可用采用多副本，则写放大效应进一步放大，导致存储网络成为瓶颈而性能无法接受。 6park.com

Aurora 继承了 Spanner 的日志持久化的思想，甚至激进提出“日志即数据库”的口号，其核心思想是存储网络尽量传输日志流，对于读操作，存储网络传输数据页在所难免，但是计算节点可以通过 buffer pool 来优化。 6park.com

它对传统数据库进行了如下改造： 6park.com

数据库主实例变成计算节点，数据库主实例不再进行刷脏页动作，仅仅向存储写日志，存储应用日志实现持久化，即日志应用下沉到存储。数据库主实例没有后台写动作，没有 cache 强制刷脏替换，没有检查点； 6park.com

数据库复制实例获取日志内容，通过日志应用更新自身的 buffer/cache 等内存对象； 6park.com

主实例与复制实例共享存储； 6park.com

将崩溃恢复，备份、恢复、快照功能下放到存储层。 6park.com

并且，以原有 S3 存储系统为基础，对存储进行如下改造： 6park.com

将存储分段（Segment），以 10G 作为分段单位大小, 每个分段共六个副本，部署于三个可用区（Available Zone），每个可用区两个副本，Aurora 将这六个分段称为一个保护组（Protection Group，PG），实现高可用。 6park.com

存储节点能接收日志记录应用来实现数据库物理页的持久化，并且使用 Gossip 协议同步各个副本间的日志。 6park.com

存储能提供多版本物理页，用以适配多个复制实例的延迟。并且后台有历史版本页面回收线程。 6park.com

持久化页存储流程图如下： 6park.com

图 6：持久化存储流程 6park.com

2.2 高可用 6park.com

Aurora 采用仲裁协议（Quorum）多数派投票方式来检测故障节点。这种高可用的前提是，10G 分段恢复时间为 10 秒，而 10 秒内出现第二个节点故障的可能性几乎为 0。 6park.com

它采用 3 个可用区，可以形成 4/6 仲裁协议（6 个节点，写需 4 个投票，读需 3 个投票）。最坏情况是某个可用区出现灾害（地震，水灾，恐怖袭击等）时，同时随机出现一个节点故障，此时仍然有 3 个副本，可以使用 2/3 仲裁协议（3 个节点，写需 2 个投票，读需 2 个投票）继续保持高可用性（AZ+1 高可用）。 6park.com

说明

优点

在成熟的数据库系统进行改造，技术相对成熟稳定、工作量小
事务处理能力，性能能保持传统数据库的优势

缺点

本质仍然是改良的读写分离集群
有修改一行写一个页的写放大问题，需要小心处理
需要 proxy 等组件才能支持分布式事务

6park.com

3 CynosDB 方案 6park.com

CynosDB [9 ] 几乎复刻了 Aurora 的实现方式，但是有其自身的特点： 6park.com

存储多副本之间用 Raft 算法保证高可用，Raft 算法包含了 Quorum 仲裁算法，而且更加灵活； 6park.com

与 Aurora 一样，主从计算节点通过网络传输 redo 日志，同步双方的 buffer cache 以及其他内存对象。 6park.com

存储多副本之间用 Raft 算法保证高可用，Raft 算法包含了 Quorum 仲裁算法，而且更加灵活； 6park.com

与 Aurora 一样，主从计算节点通过网络传输 redo 日志，同步双方的 buffer cache 以及其他内存对象。 6park.com

图 7：PolarDB 架构 6park.com

PolarDB [5 ] 也是存储与计算分离架构，但与 Aurora 最大的不同，就是没有将 redo 日志下放到存储进行处理，计算节点仍然要向存储写物理页，仅主实例与复制实例之间使用 redo 日志进行物理复制同步 buffer pool [4 ] 、事务等其他内存对象，使用现有的分布式文件系统，不对其进行改造。 6park.com

PolarDB 目前集中于分布式文件系统优化（PolarFS），以及查询加速优化（FPGA 加速）。 6park.com

5 Socrates 方案 6park.com

图 8：Socrates 架构 6park.com

Socrates [7 ] 是微软新研发的 DaaS 架构。与 Aurora 类似，使用存储与计算分离架构，强调日志的作用。但是 Socrates 采用的复用已有 SQL Server 组件： 6park.com

SQL Server 为了支持 Snapshot 隔离级，提供了多版本数据页（Page Version Store）的功能； 6park.com

使用 SSD 存储作为 buffer pool 的扩展（Reslilient Cache），可以加速故障崩溃恢复过程； 6park.com

RBIO Protocol 是扩展的网络协议，用以进行远程数据页读取； 6park.com

Snapshot Backup/Restore 快速备份与恢复； 6park.com

新增 XLogService 模块。 6park.com

其特点如下： 6park.com

尽量复用了原有 SQL Server 的特性，使用 SQL Server 组件充当 Page Server，模拟 Aurora 的存储节点； 6park.com

Socrates 有一个很大的创新，日志与页面存储分离。它认为持久性（durability）不需要使用快速存储设备中的副本，而可用性（availability）不需要有固定数量的复制节点。因此 XLog 和 XStore 负责 durability，计算节点和 page server 仅用于可用性（它们失效的时候不会丢数据，仅仅是不可用）； 6park.com

redo 日志传递均借助 Xlog Service，而不是通过主从计算节点通过网络传输。主实例节点不需要额外进行日志缓存来适应从实例节点。 6park.com

图 9：TaurasDB 架构 6park.com

TaurasDB [8 ] 架构如上图，它继承了 Aurora 的日志下沉存储的思想，也继承了 Socrates 的日志与页面存储分离的思想，并且在计算节点添加了存储抽象层（SAL）。LogStore 与 PageStore 采用与 Aurora 类似的 Quorum 仲裁算法实现高可用。 6park.com

总结云原生数据库的核心功能 6park.com

计算与存储分离，计算节点保持少状态，甚至无状态； 6park.com

基于日志的进行持久化； 6park.com

存储分片/分块，易于扩容； 6park.com

存储多副本与共识算法； 6park.com

备份、恢复、快照功能下放到存储层。 6park.com

计算与存储分离，计算节点保持少状态，甚至无状态； 6park.com

基于日志的进行持久化； 6park.com

存储分片/分块，易于扩容； 6park.com

存储多副本与共识算法； 6park.com

备份、恢复、快照功能下放到存储层。 6park.com

图 10：非核心性能支持情况 6park.com

【全球部署】 6park.com

多机房升级版，需要考虑全球可用性，全球分布式事务能力，以及 GDPR 合规要求的地理分区（Geo-Partitioning）特性。 6park.com

由于欧盟出台通用数据保护条例（GDPR） [6 ] ，使得数据不得随意跨境转移。违者最高罚款 2000 万欧元，或者全球营收 4%。原有分布式库处理技术，例如使用复制表进行 Jion 优化，就存在违规风险。此外，国内以及其他国家均有类似的数据保护法规，合规性将来也会是重要的需求。 6park.com

【更高的性能】 6park.com

基于日志进行持久化与复制更轻量，避免写放大效应，各大厂商均号称比原版 MySQL 有 5～7 倍性能。 6park.com

【更好的弹性】 6park.com

计算节点无状态或少状态，计算节点与存储扩展灵活。 6park.com

【更好的可用性】 6park.com

将数据库持久文件分片，以小粒度方式副本方式降低 MTTR，以及共识算法来实现高可用。 6park.com

【更高的资源利用率】 6park.com

计算能力与存储容量按需伸缩，减少资源浪费。 6park.com

【更小的成本】 6park.com

更少的资源、更少的浪费、更少的维护，最终达到更小的成本。 6park.com

云原生数据库本质是用现有技术组合，实现云原生需求，而且也是数据库实现 serverless 的必由之路。 6park.com

参考文献 6park.com