背景

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

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

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

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

RDS 的挑战

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

图 1：MySQL 复制架构

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

云原生数据库简介

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

通过解耦合与少状态，计算节点扩大就会很轻量，扩大速度近乎过程启动的速度。防止扩大计算资源的时候，不得不节约存储资源的困境。

解耦合也使得存储节点也少了肯定的束缚，能够应用成熟的分布式存储技术实现乖巧化，升高运维老本进步可用性。

接下来将介绍目前两种支流的技术路线和几种出名的计划。

1.Spanner 类

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

1.1 架构

以 TiDB[3] 架构图为例：

图 2：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）上再加共识算法实现。

图 3：multi-Raft 存储架构

1.3 优缺点

• SQL 反对能力无限

  • 如：YugabyteDB 不反对 Join 语句

2.Aurora 类

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

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

2.1 架构

Aurora 架构如下：

图 4：Aurora 架构

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

图 5：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 协定同步各个正本间的日志。

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

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

图 6：长久化存储流程

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 计划

图 7：PolarDB 架构

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

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

5.Socrates 计划

图 8：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 计划

图 9：TaurasDB 架构

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

总结

云原生数据库的外围性能

• 计算与存储拆散，计算节点放弃少状态，甚至无状态；
• 基于日志的进行长久化；
• 存储分片 / 分块，易于扩容；
• 存储多正本与共识算法；
• 备份、复原、快照性能下放到存储层。

出名计划的非核心性能

图 10：非核心性能反对状况

【寰球部署】

多机房升级版，须要思考寰球可用性，寰球分布式事务能力，以及 GDPR 合规要求的天文分区（Geo-Partitioning）个性。

因为欧盟出台通用数据保护条例（GDPR）[6]，使得数据不得随便跨境转移。违者最高罚款 2000 万欧元，或者寰球营收 4%。原有分布式库解决技术，例如应用复制表进行 Jion 优化，就存在违规危险。此外，国内以及其余国家均有相似的数据保护法规，合规性未来也会是重要的需要。

云原生数据库的外围价值

【更高的性能】

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

【更好的弹性】

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

【更好的可用性】

将数据库长久文件分片，以小粒度形式正本形式升高 MTTR，以及共识算法来实现高可用。

【更高的资源利用率】

计算能力与存储容量按需伸缩，缩小资源节约。

【更小的老本】

更少的资源、更少的节约、更少的保护，最终达到更小的老本。

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

参考文献

• 文中图片均来自以上参考链接

作者

柯煜昌 青云科技数据库参谋软件工程师

本文由博客一文多发平台 OpenWrite 公布！