终于有人把云原生数据库讲明白了

背景

随着云计算的蓬勃发展，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 执行引擎，可以彻底实现无状态，本质是一个分布式数据库。