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

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

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

你将 Pick 这些内容：

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

背景

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

1. 提供按需服务；
2. 用户只愿支付运营费用而不愿支付资产费用；
3. 云服务提供商集群规模越来越大，甚至遍布全球，集群达到云级规模（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），出现更多节点故障，可能使得共识算