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

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

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

你将 Pick 这些内容

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

背景

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

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

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

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

RDS 的挑战

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

盘点 | 主流云原生数据库技术方案_第1张图片
图 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张图片
图 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张图片
图 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张图片
图 4:Aurora 架构
下图绿色部分为日志流向。
盘点 | 主流云原生数据库技术方案_第5张图片
图 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张图片
图 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张图片
图 7:PolarDB 架构

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

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

5 Socrates 方案

盘点 | 主流云原生数据库技术方案_第8张图片
图 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张图片
图 9:TaurasDB 架构

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

总结

云原生数据库的核心功能

计算与存储分离,计算节点保持少状态,甚至无状态;
基于日志的进行持久化;
存储分片/分块,易于扩容;
存储多副本与共识算法;
备份、恢复、快照功能下放到存储层。

知名方案的非核心功能

盘点 | 主流云原生数据库技术方案_第10张图片
图 10:非核心性能支持情况

【全球部署】

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

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

云原生数据库的核心价值

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

【更好的弹性】
计算节点无状态或少状态,计算节点与存储扩展灵活。

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

【更高的资源利用率】
计算能力与存储容量按需伸缩,减少资源浪费。

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

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

参考文献

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

你可能感兴趣的