共计 5230 个字符，预计需要花费 14 分钟才能阅读完成。
作者：柯煜昌 参谋软件工程师
目前从事 RadonDB 容器化研发，华中科技大学研究生毕业，有多年的数据库内核开发教训。
你将 Pick 这些内容：
- 云原生的概念
- 云原生数据库的概念
- 两种支流技术路线剖析
- 六种云原生数据库计划和性能介绍
- 云原生数据库的外围性能和价值
背景
随着云计算的蓬勃发展，IT 利用转向云端，云服务呈现如下若干特点：
- 提供按需服务；
- 用户只愿领取经营费用而不愿领取资产费用；
- 云服务提供商集群规模越来越大，甚至遍布寰球，集群达到云级规模（Cloud-Scale）。
依据以上特点，要求云产品须要提供肯定“弹性 ”（Elastic），而且达到云级规模；节点故障如同 噪声 ”一样不可避免，这又要求云服务有肯定的“ 自愈”（Resilience）能力。
起初，通过借助 IaaS，间接将传统的数据库“搬迁”到云上，于是呈现了关系型数据库服务（RDS）。这样尽管能局部实现“弹性”与“自愈”，然而这种计划存在资源利用率低，保护老本高，可用性低等问题。于是，设计适应云特点的云原生数据库就至关重要。
RDS 的挑战
以 MySQL 为例，如果要实现高可用或者读写拆散集群，则须要搭建 binlog 复制集群。
图 1：MySQL 复制架构
如上图所示，除了页写入与 double write，redo log 写入操作外，还有 binlog 与 relay log 的写入。
| 缺点 | 阐明 |
|---|---|
| 写放大重大 | 如果以上架构中，FileSystem 部署在分布式文件系统中，页的写操作，会因为正本复制的机制将 IO 放大，最初 IO 提早也会放大。 |
| 资源节约重大 | 1. binlog 复制是为了适配 MySQL 所有存储引擎，属于逻辑复制。实质是将 SQL 在从实例执行（除了没有主实例的锁争用外，其余代价简直一样），效率不高，也节约了 CPU 与内存的资源。
2. 扩大集群的计算能力时，不得不同时扩大存储空间，导致磁盘资源的节约。 |
| 备份复原慢 | 无论是物理备份 / 复原，还是逻辑备份 / 复原，备份操作均会上锁，影响失常业务进行，并且，备份复原的工夫也随着存储容量的增大而线性增长。 |
| 扩大代价大 | 1. 新增从实例，首先要从备份中复原数据，而后利用 binlog 以达到与主实例统一的状态。这个过程耗时取决于复原的工夫以及 binlog 日志利用的工夫，数据量大、数据状态过期的状况下，耗时费劲而且不保障正确。弹性能力无限。
2. 存储容量受限于单机存储容量，无奈自在扩大。 |
| 可用性低 | Aurora[1]指出，在高规模的集群环境中，软件或者硬件故障如同“背景噪声”那样不可避免，并且缩短均匀故障间隔时间（MTTF）是十分艰难的，可行的办法是缩小均匀复原的工夫（MTTR）从而达到高可用性。
如上所示，RDS 依然是传统的备份复原的办法修复故障，如果数据量大的话，可能是数小时，超过均匀故障工夫距离（Aurora 是 10s），呈现更多节点故障，可能使得共识算法有效（超过半数），可用性就大大打折扣。 |
| 运维老本高 | 备份 / 复原与扩大，均须要业余 DBA 团队运维，每个步骤呈现谬误须要人工查看。 |
云原生数据库简介
为了解决以上问题，须要针对云上服务的特点，革新或者开发新一代云数据库，这便是云原生数据库。
| 特点 | 阐明 |
|---|---|
| 计算存储拆散 | 对存储与计算进行解耦合，实现存储与计算拆散。 |
| 无状态 | 计算节点无状态或较少状态。 |
| 存储集群乖巧化 | 采纳小存储块形式组织正本，用以缩小均匀复原工夫，多正本共识算法，实现存储的高可用与故障“自愈”能力。 |
通过解耦合与少状态，计算节点扩大就会很轻量，扩大速度近乎过程启动的速度。防止扩大计算资源的时候，不得不节约存储资源的困境。
解耦合也使得存储节点也少了肯定的束缚，能够应用成熟的分布式存储技术实现乖巧化，升高运维老本进步可用性。
接下来将介绍目前两种支流的技术路线和几种出名的计划。
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 优缺点
| 阐明 | |
|---|---|
| 长处 | 1. 彻底的 Share-Nothing 2. 号称寰球部署 3. 应用 key-value 构造与 LSM 树，以及日志复制自动机机制，人造无写放大效应 4. 不须要人为分库分表，有很好的横向扩大能力 |
| 毛病 | 1. 全新开发工作量大，技术不算成熟 2. 性能不佳 3. 事务处理能力无限 3.1 在内存中处理事务抵触，有抵触的须要读写期待或者提交期待。 3.2 如：Spanner 对有抵触的事务 TPS 能力最大只有 125 4. SQL 反对能力无限 4.1 如：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 来优化。
它对传统数据库进行了如下革新：
- 数据库主实例变成计算节点，数据库主实例不再进行刷脏页动作，仅仅向存储写日志，存储利用日志实现长久化，即日志利用下沉到存储。数据库主实例没有后盾写动作，没有 cache 强制刷脏替换，没有检查点；
- 数据库复制实例获取日志内容，通过日志利用更新本身的 buffer/cache 等内存对象；
- 主实例与复制实例共享存储；
- 将解体复原，备份、复原、快照性能下放到存储层。
并且，以原有 S3 存储系统为根底，对存储进行如下革新：
- 将存储分段（Segment），以 10G 作为分段单位大小, 每个分段共六个正本，部署于三个可用区（Available Zone），每个可用区两个正本，Aurora 将这六个分段称为一个爱护组（Protection Group，PG），实现高可用。
- 存储节点能接管日志记录利用来实现数据库物理页的长久化，并且应用 Gossip 协定同步各个正本间的日志。
存储能提供多版本物理页，用以适配多个复制实例的提早。并且后盾有历史版本页面回收线程。
长久化页存储流程图如下：
图 6：长久化存储流程
2.2 高可用
Aurora 采纳仲裁协定（Quorum）多数派投票形式来检测故障节点。这种高可用的前提是，10G 分段复原工夫为 10 秒，而 10 秒内呈现第二个节点故障的可能性简直为 0。
它采纳 3 个可用区，能够造成 4/6 仲裁协定（6 个节点，写需 4 个投票，读需 3 个投票）。最坏状况是某个可用区呈现灾祸（地震，旱灾，恐怖袭击等）时，同时随机呈现一个节点故障，此时依然有 3 个正本，能够应用 2/3 仲裁协定（3 个节点，写需 2 个投票，读需 2 个投票）持续放弃高可用性（AZ+1 高可用）。
| 阐明 | |
|---|---|
| 长处 | 1. 在成熟的数据库系统进行革新，技术绝对成熟稳固、工作量小 2. 事务处理能力，性能能放弃传统数据库的劣势 |
| 毛病 | 1. 实质依然是改进的读写拆散集群 2. 有批改一行写一个页的写放大问题，须要小心解决 3. 须要 proxy 等组件能力反对分布式事务 |
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 组件：
- SQL Server 为了反对 Snapshot 隔离级，提供了多版本数据页（Page Version Store）的性能；
- 应用 SSD 存储作为 buffer pool 的扩大（Reslilient Cache），能够减速故障解体复原过程；
- RBIO Protocol 是扩大的网络协议，用以进行近程数据页读取；
- Snapshot Backup/Restore 疾速备份与复原；
- 新增 XLogService 模块。
其特点如下：
- 尽量复用了原有 SQL Server 的个性，应用 SQL Server 组件充当 Page Server，模仿 Aurora 的存储节点；
- Socrates 有一个很大的翻新，日志与页面存储拆散。它认为持久性（durability）不须要应用疾速存储设备中的正本，而可用性（availability）不须要有固定数量的复制节点。因而 XLog 和 XStore 负责 durability，计算节点和 page server 仅用于可用性（它们生效的时候不会丢数据，仅仅是不可用）；
- 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 的必由之路。
参考文献
- 文中图片均来自以上参考链接