百木园作者：柯煜昌 顾问软件工程师
目前从事 RadonDB 容器化研发，华中科技大学研究生毕业，有多年的数据库内核开发经验。
你将 Pick 这些内容：
背景
随着云计算的蓬勃发展，IT 应用转向云端，云服务出现如下若干特点：
根据以上特点，要求云产品需要提供一定 “弹性”（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-Nothing2. 号称全球部署3. 使用 key-value 结构与 LSM 树，以及日志复制自动机机制，天然无写放大效应4. 不需要人为分库分表，有很好的横向扩展能力 |
| 缺点 | 1. 全新开发工作量大，技术不算成熟2. 性能不佳3. 事务处理能力有限 3.1 在内存中处理事务冲突，有冲突的需要读写等待或者提交等待。 3.2 如：Spanner 对有冲突的事务 TPS 能力最大只有 1254. 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 来优化。
它对传统数据库进行了如下改造：
并且，以原有 S3 存储系统为基础，对存储进行如下改造：
存储能提供多版本物理页，用以适配多个复制实例的延迟。并且后台有历史版本页面回收线程。
持久化页存储流程图如下：
图 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 组件：
其特点如下：
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 的必由之路。
参考文献
[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 https://www.percona.com/live/18/sites/default/files/slides/polardb_p18_slides.pdf
[5]: PolarDB Architecture https://www.intel.com/content/dam/www/public/us/en/documents/solution-briefs/alibaba-polardb-solution-brief.pdf5
[6]: GDPR https://gdpr-info.eu/
[7]: \"Socrates: The New SQL Server in the Cloud\"
[8]: Taurus Database: How to be Fast, Available, and Frugal in the Cloud
[9]: 腾讯云新一代自研数据库CynosDB技术详解——架构设计https://cloud.tencent.com/developer/article/1367387
- 文中图片均来自以上参考链接
来源：https://www.cnblogs.com/radondb/p/15262700.html
图文来源于网络，如有侵权请联系删除。