作者：RadonDB 开源社区

来源：SegmentFault 思否社区

作者：柯煜昌 顾问软件工程师

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

你将 Pick 这些内容：

1. 云原生的概念
2. 云原生数据库的概念
3. 两种主流技术路线分析
4. 六种云原生数据库方案和功能介绍
5. 云原生数据库的核心功能和价值

背景

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

1. 提供按需服务；
2. 用户只愿支付运营费用而不愿支付资产费用；
3. 云服务提供商集群规模越来越大，甚至遍布全球，集群达到云级规模（Cloud-Scale）。

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

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

RDS 的挑战

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

MySQL 复制架构

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

云原生数据库简介

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

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

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

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

1 Spanner 类

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

1.1 架构

以 TiDB[3] 架构图为例：

TiDB 架构图

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

1.2 存储高可用性

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

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

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

multi-Raft 存储架构

1.3 优缺点

2 Aurora 类

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

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

2.1 架构

Aurora 架构如下：

Aurora 架构

下图绿色部分为日志流向。

Aurora 网络 IO

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

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

它对传统数据库进行了如下改造：

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

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

3. 主实例与复制实例共享存储；

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

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

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

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

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

持久化页存储流程图如下：

持久化存储流程

2.2 高可用

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

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

3 CynosDB 方案

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

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

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

4 PolarDB 方案

PolarDB 架构

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

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

5 Socrates 方案

Socrates 架构

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

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

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

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

4. Snapshot Backup/Restore 快速备份与恢复；

5. 新增 XLogService 模块。

其特点如下：

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

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

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

6 TaurasDB 方案

TaurasDB 架构

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

总结

云原生数据库的核心功能

• 计算与存储分离，计算节点保持少状态，甚至无状态；

• 基于日志的进行持久化；

• 存储分片/分块，易于扩容；

• 存储多副本与共识算法；

• 备份、恢复、快照功能下放到存储层。

知名方案的非核心功能

非核心性能支持情况

【全球部署】

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

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

云原生数据库的核心价值

【更高的性能】

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

【更好的弹性】

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

【更好的可用性】

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

【更高的资源利用率】

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

【更小的成本】

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

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

参考文献

【1】: "Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases"
【2】: "Spanner: Google’s Globally-Distributed Database"
【3】: TiDB: A Raft-based HTAP Database
【4】: PolarDB redo replication
【5】: PolarDB Architecture
【6】: GDPR 
【7】: "Socrates: The New SQL Server in the Cloud"
【8】: Taurus Database: How to be Fast, Available, and Frugal in the Cloud
【9】: 腾讯云新一代自研数据库CynosDB技术详解——架构设计

---

点击左下角阅读原文，到 SegmentFault 思否社区 和文章作者展开更多互动和交流，扫描下方”二维码“或在“公众号后台“回复“ 入群 ”即可加入我们的技术交流群，收获更多的技术文章~

- END -