云原生时代，需要什么样的数据库？

2021 年 12 月 28 日
本文字数：6104 字
阅读完需：约 20 分钟

互联网业务的飞速发展带来急剧膨胀的数据规模，多样化的数据类型、更复杂的业务特征和对数据实时洞察的需求，推动了传统数据库技术向可扩展、高可用、实时弹性等方向发展。

而云计算技术的发展为解决这些问题带来了新方法，大规模资源池化为上层应用带来良好的抽象和足够的弹性，根据负载实时匹配和调度资源也最大化地提升了资源的使用效率，数据库不再受制于单个物理机器的资源使用限制，从原来独立部署模式进化到云服务模式，可利用更大规模的算力、存储和网络。

数据库向云服务的演进过程不仅仅是商业模式上的转变，更推动了技术上的变革，将数据库部署在云计算基础设施上，用户可以不再关心具体的物理服务器位置，云平台得以利用庞大的资源池和虚拟化技术提供数据库的高可用、资源扩展、数据备份与迁移、监控告警等一系列服务，减轻用户的运维负担。

而更进一步，是利用云原生技术将数据库进行了彻底重构，通过分层解耦，构造出实时细粒度弹性，根据用户负载匹配资源的云原生数据库服务，用户可以像使用 SaaS 服务一样使用数据库这种基础系统，使用门槛大大降低，服务会自动根据用户业务的扩展进行伸缩，因此用户无须事先预留容量余量，只需支持最小使用成本。

现今，“云原生”已成为耳熟能详的热门词汇，因云而生的软件、硬件、架构，共同构成了广义的云原生概念。全球知名咨询机构 Gartner 指出，到 2022 年，75%的数据库将被部署或迁移至云平台，只有 5%的数据库会考虑部署在本地。

云平台利用容器化、虚拟化、编排调度等技术为各种组件构建了一个新型的操作系统。如何利用云平台提供的资源虚拟化和弹性资源分配能力，实现高可用的、高性能的、智能的云数据库系统成了一个新的挑战。经过长期的发展，云数据库系统与传统数据库系统相比已经具有了鲜明的特征。

数据库在云时代的发展

在云计算兴起之前，对于大多数企业而言，自行采购硬件和租用互联网数据中心（Internet Data Center）机房是主流的 IT 基础设施构建方式。

除了服务器本身，机柜、带宽、交换机、网络配置、软件安装和虚拟化等底层诸多事项需要相当专业的人士负责，发生调整时的反应周期也比较长，需要经过一系列采购、供应链、上架、部署、服务等流程。

对于企业来讲，必须提早预测自身业务发展的需求，做好预算规划。为了避免系统容量跟不上业务发展的速度，往往会提前留一定的余量。但企业对业务发展的预测往往与实际有偏差，进入互联网时代后尤其如此，要么业务超出预期，系统过载；要么不及预期，大量资源被闲置。

云计算为上述问题提供了一个解决方案，即把信息化需要的基础设施作为一种服务来提供（Infrastructure as a Service，IaaS），就像生活领域的水电煤气服务一样，企业或家庭用户无须为获取这些资源而进行基础设施建设，比如自己挖井或自己用发电机发电，只要接入政府提供的生活服务网络，根据需要随时取用即可。

同样地，企业用户需要计算资源时无须自行购买硬件、搭建 IDC，而是根据需要向云计算服务提供商购买即可。

2006 年，Google 首席执行官 Eric Schmidt 在搜索引擎大会（SES SanJose 2006）上首次提出了云计算（Cloud Computing）的概念。

同年，亚马逊推出了公有云服务（Amazon Web Service），国外的一些互联网巨头，例如 Microsoft、VMWare 和 Google，国内的阿里巴巴、腾讯和华为也相继推出了云服务，一时间云计算从崭露头角很快就变得炙手可热，成为企业 IT 服务的首选。

对于企业用户而言，IT 服务建设不再意味着持有重资产，只需要根据自身的业务需要向云计算厂商购买计算资源或服务。对云厂商而言，把众多的需求汇聚在一起，能产生足够的规模效应，通过建立超大规模的资源池，并在此之上提供统一的、虚拟化的抽象界面。

云实际上就是利用容器、虚拟化、编排调度和微服务等技术在多样化硬件上建立了一个庞大的操作系统，使得用户不再需要关注硬件差异化、生命周期管理、网络、高可用、负载均衡和安全等细节，同时利用资源池化的能力，如同一个庞大的算力蓄水池，利用不同业务在不同时段对算力的不同需求，辅以充分灵活的调度策略，为云上用户提供一个巨大的独特优势——弹性。

数据库作为一种服务

有了 IaaS 层作为基础，云计算服务提供商在此之上建立了更加丰富的层次，如平台即服务（Platform as a Service，PaaS）和软件即服务（Software as a Service，SaaS），为各种应用场景在云上找到了合适的舞台。

数据库作为重要的基础软件，很早就开始了上云之路，与操作系统、存储、中间件等组成了云上 PaaS 标准服务体系。各大云厂商大多都提供了云数据库服务，根据不同的服务形态，大体上可分为云托管、云服务和云原生三种形态。

1．云托管

云托管是最接近传统数据库系统的部署模式。

本质上，云托管是将原本部署于 IDC 机房内物理服务器（也可能是虚拟出来的服务器）上的传统数据库软件部署在了云主机上。在这种部署模式下，数据库用户仅仅是将云服务供应商当成了一个 IDC 机房供应商，使用的是云服务供应商提供的以云主机为载体的“计算+存储”资源。

在这种模式下，用户要自己负责整个数据库系统的可用性、安全性和性能。因此，客户拥有的数据库系统所必需付出的成本与在 IDC 中自建没有本质的区别，客户依然需要拥有自己的 IT 运维团队，需要有自己的数据库管理员，才能正常地使用数据库。

在云托管模式下，客户必须凭借自己的技术能力才能获得一些企业级数据库管理系统能力，例如高可用、异地灾备、备份恢复、数据安全、SQL 审计、性能优化和状态监测等，而这些企业级能力依赖客户的数据库管理员团队来提供。

因此，采用云托管模式的客户在核算总体拥有成本（Total Cost of Ownership，TCO）时，需要将这部分人力投入成本考虑在内，并需要具备管理数据库管理员团队的能力。

2．云服务

云服务比云托管模式更近一步，用户可以直接使用云服务厂商提供的数据库服务，而不用关心数据库管理软件具体的部署方式。

在通常情况下，云服务厂商会提供多种传统的数据库服务，例如 MySQL、SQL Server 和 PostgreSQL，等等。用户可以直接使用云数据库服务的链接地址，采用 JDBC 或 ODBC 接口直接访问数据库。

以云服务模式对外提供服务的数据库管理系统通常也将企业级特性包括在内。云服务厂商在提供云数据库服务时，通常会提供对应的企业级特性，包括但不限于高可用、异地灾备、备份恢复、数据安全、SQL 审计、性能优化和状态监测等。

此外，云数据库服务通常也会提供在线升级、缩扩容等服务，本质上这是一种云服务厂商提供的针对云数据库服务的资源管理能力。

云服务模式相比云托管模式的另一个改进在于用户无须拥有自己的数据库管理员或团队，通常由云服务提供商提供数据库的运维服务，比较优质的服务供应商甚至会提供包括数据模型设计、SQL 语句优化和性能压测等在内的专家服务。

3．云原生

云服务模式通过规模化的数据库运维服务、供应链管理能力，降低了单个客户对于数据库系统的总体拥有成本，使得传统的数据库用户得以享受到云计算带来的便利。

然而，传统的数据库系统由于其架构的局限性，并不能完全发挥出云计算的优势。例如，云计算带来的资源按需使用、快速弹性扩展、高性能、高可用等，都受限于传统的数据库系统架构，而无法在云服务模式下充分对外提供。因此，云原生数据库应运而生。

云原生的概念最早由 Pivotal 公司在 2014 年提出，并在 2015 年组织成立了云原生计算基金会。

关于云原生，至今并没有明确的定义。云原生是云计算时代新的团队文化、新的技术架构和新的工程方式。

云原生指的是一个灵活的工程团队，遵循敏捷的研发原则，使用高度自动化的研发工具，开发专门基于并部署在云基础设施上的应用，以满足快速变化的客户需求。这些应用采用自动化的、可扩展的和高可用的架构。工程团队通过高效的云计算平台的运维来提供应用服务，并且根据线上反馈对服务进行不断的改进。

对应数据库领域，云原生的数据库服务应该包括基于云基础设施构建的数据库管理系统、高度灵活的数据库 DevOps（Software Development and IT Operations）团队，以及与之配套的云原生生态工具。

从用户视角来看，云原生的数据库服务应该具备“计算存储分离”“极致弹性”“高可用”“高安全”“高性能”等核心能力；数据库服务具备智能化的自省能力，具体包括自感知、自诊断、自优化和自恢复等；借助云原生生态工具，能够实现数据的高安全、可监控和可流动；有一支遵循 DevOps 规约的数据库技术团队实现数据库服务的快速迭代与功能演进。

数据库在云原生时代面临的挑战

传统数据库架构依赖于高端硬件，每套数据库系统服务器少、架构相对简单，且无法支持新业务的扩展需求。

云原生数据库采用分布式数据库架构，可实现大规模扩展，由于每套数据库系统横跨多台服务器和虚拟机，因此带来了全新的系统管理挑战。

其中，最核心的挑战就是如何实现弹性及高可用，即实现按需按量使用，让资源高效利用。

更重要的是，虽然传统的大数据处理牺牲部分 ACID 换来的分布式水平拓展满足了很多场景中的需求，但是应用对 ACID 的需求一直存在，即使是在分布式并行计算的场景中，应用对 ACID 的需求也变得越来越强。

因此，云数据库在分布式事务的协调、分布式查询的优化和强 ACID 特性的保证等方面，具有非常大的挑战。

除此之外，云原生数据库面临的其他挑战有：

多服务器安装部署、自动化扩容带来的运维挑战。
复杂云环境下的实时监控、节点故障和性能问题的安全审计挑战。
多种数据库系统与其业务系统的管理挑战。
海量数据数据迁移的挑战。

云原生数据库具有的主要技术特点

1. 分层架构

云原生数据库在架构设计上最显著的特点，即将原本一体运行的数据库拆解为计算服务层、存储服务层和共享存储层。

其中，计算服务层负责解析 SQL 请求，并转化为物理执行计划。存储服务层负责数据缓存管理与事务处理，保证数据的更新和读取符合事务的 ACID 语义，在实现中不一定是物理分离的，可能一部分集成在计算服务层，一部分集成在共享存储层。共享存储层负责数据的持久化存储，利用分布式一致性协议保证数据的一致性与可靠性。

2. 资源解耦与池化

在云原生时代，云基础设施通过虚拟化的技术实现资源池化。基于分层架构，云原生数据库可以有效地将计算和存储资源解耦，从而分别扩展。因此在资源池化之后，云原生数据库可以按需按量使用、弹性调度资源。

在资源解耦进展上，目前业界是将 CPU 和内存绑在一起，和 SSD 持久化存储分开。但随着非易失存储技术和 RDMA 技术的成熟，下一步甚至会将 CPU 和内存进行隔离，内存再进行池化，形成三层池化，更好地帮助客户实现按需按量使用资源。

3. 弹性伸缩能力

传统的中间件分库分表的方案和企业级的透明分布式数据库都会面临一个挑战：在分布式架构下，数据只能按照一个逻辑进行分片（Sharding）和分区（Partition），业务逻辑和分库逻辑不是完美一致的，一定会产生跨库事务和跨分片处理，每当 ACID 要求较高时，分布式架构会带来较高的系统性能挑战。例如在高隔离级别下，如果分布式事务占比超过整个事务的 5%，那么系统吞吐量会有明显的损耗。

完美的分库策略是不存在的，这是分布式业务需要解决的核心挑战，同时需要保证在这个架构数据的高一致性。

云原生的架构，在本质上，下层是分布式共享存储，上层是分布式共享计算池，中间层用于计算存储解耦，这样可以非常好地提供弹性高可用能力，做到分布式技术集中式部署，从而对应用透明。

4. 高可用与数据一致性

分布式系统的多个节点通过消息传递进行通信和协调，其不可避免地会出现节点故障、通信异常和网络分区等问题。采用一致性协议可以保证在可能发生上述异常的分布式系统中的多个节点就某个值达成一致。

在分布式领域中，CAP 理论认为任何基于网络的数据共享系统最多只能满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）三个特性中的两个。

其中，一致性指更新操作完成后，各个节点可以同时看到数据的最新版本，各节点的数据完全一致；可用性指在集群的部分节点发生故障时，系统可以在正常响应时间内对外提供服务；分区容忍性指在遇到节点故障或网络分区时，系统能够保证服务的一致性和可用性。

由于是分布式系统，网络分区一定会发生，天然地需要满足分区容忍性，因此需要在一致性和可用性之间做出权衡。

在实际应用中，云原生数据库通常采用异步多副本复制的方式，例如 Paxos、Raft 等一致性协议，保证系统的可用性和最终一致性，以牺牲强一致性的代价换取系统可用性的提升。

在线上使用时，云原生数据库会提供不同的高可用策略。

高可用策略是根据用户自身业务的特点，采用服务优先级和数据复制方式之间的不同组合，组合出适合自身业务特点的高可用策略。

服务优先级有以下两种策略，可以方便用户在可用性和一致性之间做出权衡。

RTO（Recovery Time Objective）优先：数据库应该尽快恢复服务，即可用时间最长。对于数据库在线时间要求比较高的用户，应该使用 RTO 优先策略。
RPO（Recovery Point Objective）优先：数据库应该尽可能保障数据的可靠性，即数据丢失量最少。对于数据一致性要求比较高的用户，应该使用 RPO 优先策略。

5. 多租户与资源隔离

多租户指一套系统能够支撑多个租户。一个租户通常是具有相似的访问模式和权限的一组用户，典型的租户是同一个组织或者公司的若干用户。

要实现多租户，首先需要考虑的是数据层面的多租户。数据库层的多租户模型对上层服务和应用的多租户实现有突出影响。

多租户通常有某种形式的资源共享，需要避免某个租户的业务“吃掉”系统资源，影响其他租户业务的响应时间。

一般实现多租户会采用一租户一数据库系统，或者多租户共享同一个数据库系统，通过命名空间等方式隔离，但是这种模式运维和管理比较复杂。在云原生场景下，数据库可以为不同的租户绑定相应的计算和存储节点以实现资源的隔离和面向不同租户的资源调度。

6. 智能化运维

智能化运维技术是云原生数据库的重要特性。云原生数据库一般通过简易的操作界面和自动化流程帮助用户快速完成常见的运维任务，并可以在多数任务下执行自动化操作：