文 ｜ InfoQ

作者 ｜ 万佳

从传统关系型数据库到云数据库，数据库在不断演进。与此同时，它也发挥着越来越重要的作用。从云计算、新媒体、音视频、云游戏到移动 App，几乎各行各业都离不开数据库。一方面，数据库作为 IT 基础设施的关键一环，对企业业务的发展起着支撑作用；另一方面，数字化在经济社会中不断深入，数据成为核心要素，围绕数据的生产、存储和消费均依赖数据库。

图源IDC行业报告

IDC 报告显示，数据库、AI、大数据三者消耗了最多的 IT 基础设施资源，并且在所有类型的工作负载中增长最快。由此可见，数据库已经成为云中最重要的工作负载之一。

随着企业数字化转型的深入，业务与数据的关系越来越紧密，数据库市场呈现蓬勃发展之势。根据 IDC 预测，到 2024 年，中国关系型数据库软件市场规模将达到 38．2 亿美元，未来 5 年整体市场年复合增长率为 23．3％。

除市场快速发展外，数据库自身也在变化。云计算的出现和发展，让企业 IT 基础设施云化，应用转向云端。与此同时，从单体到微服务架构再到 Serverless 架构，系统架构不断演进。这一方面为用户提供了更优秀的特性，另一方面也对云计算的组件提出更高要求。作为云计算关键技术和最基础的组件之一，数据库也需要适应这种架构变化。云数据库应运而生。

“数据库＋云”还是“云＋数据库”？

云计算自 2006 年出现后，随着企业上云进程的加速，传统数据库逐渐从私有部署转化为云上部署，但变化主要集中在部署模式的不同，并未充分利用云计算理论为大数据技术本身赋能。而云原生概念的兴起，让数据库迎来重大变革，云原生数据库开始成为行业“主角”。

经久不衰的关系型数据库

众所周知，数据库起源于 20 世纪 60 年代。在 70 年代，关系型数据库诞生，并成为沿用至今的数据库存储计算系统。即使随着移动互联网的发展，大数据技术的广泛应用，涌现出越来越多新型数据库，但关系型数据库依旧占据主导地位。

据 DB－Engines 统计，截至 2020 年 5 月，在收录的 357 种数据库中，关系型数据库占比高达 75．2％。它之所以能经久不衰，是因为其满足数据库的 ACID 特性，能帮助应用开发且简化应用开发的复杂性。同时，它采用 SQL 标准，业务人员很容易看懂开发人员写的代码，代码可读性和可维护性非常强，降低了沟通成本。

在云计算出现前，关系型数据库通常采用本地部署方式（On－Premises），其中，商业数据库代表有 Oracle、Microsoft SQL Server、IBM Db2，开源数据库代表则是 MySQL、PostgreSQL。那时，大多数企业都是自行采购硬件和租用 IDC。除服务器外，机柜、交换机、网络配置和软件安装等底层很多事情都需要专业人士负责。数据库方面，只有资金充裕的大企业（如电信、金融等）主要用 Oracle、IBM DB2 等商业关系型数据库，它们的特点是性能强大、稳定性好，但价格贵、维护成本高。

传统数据库架构依赖于高端硬件，每套数据库系统服务器少、架构相对简单，且无法支持新业务的扩展需求。如果想提升性能，主要靠采用配置更高、更先进的硬件。当然，这样的机器也更昂贵。

除了扩展性差，传统关系型数据库还面临一些挑战：一是部署成本高，维护难度大；二是由于私有化部署，数据库内核迭代升级比较缓慢。并且，它无法应对高并发读写。像以 Web 2．0 为代表的网站，其数据库负载非常高，本地部署的传统关系型数据库往往无法应对每秒上万次的读写请求，硬盘 I／O 成为性能瓶颈。

云计算兴起，关系型数据库演化到云托管关系型数据库

云计算出现后，传统关系型数据库遇到的问题部分得到缓解。借助 IaaS，企业开始将传统数据库“搬迁”到云上，因此出现了云托管关系型数据库，云厂商称之为 RDS 服务，如 Amazon RDS、阿里云 RDS 等。

与传统关系型数据库相比，云托管关系型数据库在外部交互层面上，保持了和传统“原版”数据库几乎完全一致的编程接口和使用体验。在搭建、运维和管理层面，云托管关系型数据库门槛更低，对用户更友好，且实现了相当程度的智能化和自动化。许多在传统数据库中需借额外工具或产品的功能，在云托管关系型数据库中默认内置，开箱即用。本质上，云托管是将原本部署于 IDC 机房内物理服务器（也可能是虚拟出来的服务器）上的传统数据库软件部署在云主机上。

图由作者绘制

以 Amazon RDS 为例。其架构类似在底层的数据库上构建了一个中间层。这个中间层负责路由客户端的 SQL 请求发往实际的数据库存储节点。因为将业务端的请求通过中间层代理，所以可对底层的数据库实例进行很多运维工作。这些工作由于隐藏在中间层后边，业务层可以做到基本无感知。另外，这个中间路由层基本只是简单的转发请求，所以底层可以连接各种类型的数据库。其缺点在于，它本质上还是一个单机主从架构，无法适用超过最大配置物理机容量、CPU 负载和 IO 的场景。尤其是移动互联网时代，很多企业业务快速增长，数据库并发量越来越高，也愈加重视可扩展性。

云托管关系型数据库虽然能部分实现“弹性”与“自愈”，但是这种方案存在资源利用率低、维护成本高、可用性低等问题。

以阿里云为例，阿里 PolarDB 之所以会诞生，原因之一是阿里云数据库团队在业务中遇到很大挑战：它们在云上维护了庞大的 MySQL 云服务（RDS）集群，包含成千上万个实例，面临很多棘手问题：

• 云服务一般使用云硬盘，导致数据库的性能没物理机实例好，比如 I／O 延时过高；

• RDS 实例集群很大，可能同时有很多实例在备份，从而占用云服务巨大的网络和 I／O 带宽，导致云服务不稳定；

• 大实例恢复需重建时，耗时太长，影响服务可用性；

• 对需要读写分离，且要求部署多个只读节点的用户，最明显的感觉是每增加一个只读实例，成本是线性增长。

针对这些问题，可选解决方案是基于共享存储，即数据库共享存储方案：RDS 实例（一般指一主一从的高可用实例）和只读实例共享同一份数据。好处是实例故障或只读扩展时，不用拷贝数据，只需新建只读计算节点或把故障节点重新拉起来。并且，通过快照技术和写时拷贝解决数据备份和误操作恢复问题。不过，业内可用的共享存储方案非常少，即使可用，性能也达不到要求。

因此，想解决云托管关系型数据库服务面临的问题，必须改变思路，从架构入手。

架构“革命”，云原生数据库出现

要知道，过去三四十年，传统关系型数据库架构并未发生很大改变。

图源亚马逊云科技博客

虽然在数据库扩展方面存在不同的常规方法（如分区、无共享或共享磁盘等），但这些方法都基于同样的基本数据库架构。

正如亚马逊云科技在博客中写道：“这些方法无法解决大规模性能、弹性和爆炸半径问题，因为严密耦合型整体式堆栈的基本局限性依然存在。”

为解决云托管关系型数据库面临的问题，适应云特性的云原生数据库就此诞生。云原生数据库完全为云设计，能充分发挥云的特点和优势。

具体说来，云原生数据库有三大特点：第一，计算、存储分离，由于对存储与计算进行解耦合，实现了存储与计算分离；第二，无状态，计算节点无状态或较少状态；第三，存储节点灵巧化，因采用小存储块方式组织副本，用以减少平均恢复时间，多副本共识算法，实现存储的高可用与故障“自愈”能力。

目前，业内云原生数据库的代表有亚马逊云科技 Aurora、阿里 PolarDB、Azure CosmosDB、腾讯 TDSQL－C 等。

从上述各种云原生数据库的实践和发展来看，我们总结出数据库技术的几个发展趋势：第一，从 scale up 到 scale out。打个比方，这就像从传统火车到动车一样，scale out 不仅可以降低用户 TCO，而且该架构可以支撑系统扩展。尤其是如今的网络已经从百兆迈向 100G、200G，协议从 socket 迈向 RDMA，因此 scale out 架构已经完全成为可能。其次，从物理机到云原生。正如英特尔大数据首席工程师程从超所言，“我们原来的数据库从物理机逐步走向云平台，充分利用云平台底层的分布式存储，以及计算资源池、存储资源池的无限扩展能力，让数据库关注上层业务逻辑，与云平台充分地结合，形成云原生。”第三，从计算存储分离到逻辑和执行引擎分离，走向 Serverless 架构。好处在于 CPU 可以动态扩展或缩容，为用户提供 on demand 服务。第四，数据计算将放在内存里，数据存储可能采用块存储、对象存储。这样，在计算过程中，避免和底层存储“打交道”。最后是 AIOps。通过 AI 技术自动的对前端业务系统进行调优。这可以在提高性能的同时，降低成本、预防 IT 事故，并提高业务的敏捷性。

发挥极致性能，云原生数据库的创新实践

如今人工智能、低代码、即时数据分析等技术的加速创新意味着云上工作负载日趋多元化、动态化。如何应对这种变化，对云原生数据库是非常大的考验。

在架构设计上，现有云原生数据库最显著的特点是将原本一体运行的数据库拆解，让计算、存储资源完全解耦，使用分布式云存储替代本地存储，将计算层变成无状态。云原生数据库将承载每层服务的资源池化，独立、实时地伸缩资源池的大小，以匹配实时的工作负载，使得资源利用率最大化。

图由作者绘制

如上图所示，大部分云原生数据库将 SQL 语句解析、物理计划执行、事务处理等都放在一层，统称为计算层。而将事务产生的日志、数据的存储放在共享存储层，统称为存储层。在存储层，数据采用多副本确保数据的可靠性，并通过 Raft 等协议保证数据的一致性。由此可见，高性能的分布式存储是云原生数据库实现的关键。

此外，计算节点与存储节点之间采用高速网络互联，并通过 RDMA 协议传输数据，让 I／O 性能不再成为瓶颈。值得注意的是，Amazon Aurora 并未使用 RDMA。

除架构外，云原生数据库还需要与硬件搭配，软硬协同，才能发挥出最大潜力。新硬件的发展为数据库技术注入了更多的可能性，充分发挥硬件性能成了所有数据库系统提升效率的重要手段。云原生数据库拆解了计算、存储，并利用网络发挥分布式的能力，在这三个层面都充分结合新硬件的特性进行设计。

通过腾讯云 TDSQL－C 的实践，我们可以深入了解云原生数据库的创新思路。

TDSQL－C 是腾讯云自研的新一代云原生关系型数据库，采用计算和存储分离的架构，所有计算节点共享一份数据，存储容量高达 128TB，单库最高可扩展至 16 节点，提供秒级的配置升降级、秒级的故障恢复和数据备份容灾服务，兼具商用的性能和稳定性以及开源的灵活和低成本。

大体上，TDSQL－C 核心技术创新表现在两方面：一方面是架构创新，另一方面是性能优化。

TDSQL－C 云原生架构（图由作者绘制）

在架构上，TDSQL－C 存算分离，把计算层和存储层进行解耦，做分层处理，分层过后通过池化让计算、存储的能力变得无限大。存算分离后，存储可以使用集群化的云存储，大大提升存储上限，计算资源可以跨实例、跨物理机调度，按需使用，弹性大大增加。

图源InfoQ官网

其次，TDSQL－C 共享存储。如上图所示，传统上，Master 和 RO 虽然对应的是同一份数据，但实际存储时有六份数据。而每增加一个 RO 节点，就会多出三份数据，这也让整个集群的存储副本数近一步放大。并且，高吞吐的数量使网络问题成为瓶颈，在共享存储侧也有大量网络浪费。而 TDSQL－C 采用共享存储方式，如下图所示，Master 和 RO 是基于一份数据放在共享存储中，RO 只从共享存储中读取所需的 page，不需要写入存储，并且 RO 可以从主库接收 WAL 在缓存中重放，以此保持缓存中 Page 持续更新。如此，TDSQL－C 就解决了业务容量和计算节点的扩容问题。

图源InfoQ官网

第三，TDSQL－C 使用“log is database”方案，把一部分数据库计算逻辑下沉到存储层完成， 实现网络数据传输减少 90％＋，计算层资源更聚焦于 SQL 处理，提升系统性能，分布式刷脏基本上规避 BP 刷脏的影响，加快了系统启动速度。

除了架构创新，TDSQL－C 在性能优化方面，不仅很好地利用云原生数据库自身特点，而且充分结合英特尔产品和技术，实现极致性能。

具体而言，腾讯云 TDSQL－C 团队首次深入底层软件的设计层面，利用英特尔 oneAPI 收集软件运行过程中的函数开销等，通过反馈优化技术进行再编译。这样，TDSQL－C 性能得到进一步提升，在大部分用户场景下都有更好的效果，甚至在某个方面，性能提升可以达到 85％。

在这个过程中，英特尔 oneAPI 发挥着重要作用。作为一种开放、统一的编程模型，oneAPI 用于 CPU 和加速器，并支持多个厂商的计算机架构。

其次，为优化读取性能和写入性能，腾讯云 TDSQL－C 团队基于英特尔傲腾持久化内存设计了一个二级缓存方案，因为由计算和存储分离带来的远程 I／O 成为不小的挑战。同时，根据数据温度，智能存储分层：热数据放在内存，冷数据放在磁盘。在使用傲腾持久化内存后，团队重新定义温数据，实行低冗余度存储。在计算节点，通过对温数据进行缓存，团队极大提高了数据库在 IO 密集型场景下的访问速度。

图由作者绘制

如上图所示，TDSQL－C 团队在远程存储和 buffer pool 之间实现了二级缓存层，它使用本地存储介质。从 buffer pool 中淘汰的页面缓存在该层——实际上并非淘汰，而是把从buffer pool 移出的数据缓存到本地的 SSD存储或AEP存储。下次访问该数据时，满足一定的条件下，可以直接从本地读取，这样就能最大限度地降低网络 I／O 的消耗。

通过与 英特尔 技术团队的联合创新，结合最新一代英特尔? 至强? 可扩展处理器以及英特尔? 傲腾? 持久内存（PMem）的硬件特性，TDSQL－C 团队重构了二级缓存设计方案，在IO bound 场景中的读写性能提升2倍以上。

同时，TDSQL－C 团队携手英特尔多方位优化存储方案设计，如加入轮询、算法优化、消除锁等机制，优化存储引擎等，并引入由英特尔提供的 SPDK 开发套件，优化 NVMe 固态盘的 IOPS 和时延性能。并且，对网络架构全面升级，TDSQL－C 新版本采用全链路 RDMA 网络，依靠零拷贝、内核旁路、无 CPU 干预等特性，进一步优化了存储层与计算层以及存储层多副本间关键路径的系统性能，降低请求延迟最高达 80％，使 I／O 性能不再成为瓶颈。

简言之，TDSQL－C 新版本对云原生数据库场景进行了大量优化，极大提升了数据库性能，能更好地满足企业对数据库性能的极致追求。

从腾讯云与英特尔合作的创新实践中，我们发现未来的数据库将步入全栈优化时代，从硬件平台优化到架构层优化再到上面的应用层优化。所谓“软件优化三年不如硬件更新一代”，比如算力上，一定是充分利用 CPU 最底层的指令集和最新的加速器。据悉，最新的英特尔? 至强? 可扩展处理器（Sapphire Rapids）一代，已经从单纯的提高主频和增加核数逐步走向更多的加速器，包括 QAT 和 SGX 以及 DSA 等。在英特尔大数据首席工程师程从超看来，这些新的加速器会对数据库的整个优化设计带来很大的影响，这也是未来需要充分重视的。

以硬件到基础设施的优化为例，算力优化方面，需采用最新的处理器和最新的软件版本，并选择高主频的核。同时，还要避免 NUMA，即非一致性内存访问，因为它对数据库的性能影响较大。并且，可以充分利用底层 CPU 最新的指令集，如 SIMD。在存储优化方面，实行数据封层存放，把 redo log 和 binlog 等日志存储在低延时设备上，以及通过 PMEM 在物理存储（HDD、SSD、NAND）和内存间增加一个 cache 层，作为应用的热数据存储，从而扩展内容容量，弥补存储性能。为进一步优化存储，企业还可以利用 LSM 的多版本管理机制增强系统的性能。网络优化上，可以采用 ADQ，通过 SPDK／DPDK 等技术提高网络性能，绕过 kernel space 的性能瓶颈。

写在最后

随着数字化不断发展，数据的价值正不断显现。毫无疑问，围绕数据的生产、存储和消费构成的系列服务，将成为数字经济社会的核心价值链条，而其背后的支撑正是数据库。这也意味着，数据库将比以前发挥更大的作用。

从传统关系型数据库到云托管关系型数据库再到云原生数据库，数据库不断变革。我们看到，当企业业务从本地到上云再到原生发展时，云原生数据库也将成为云时代数据库的主角之一。作为支撑企业业务的关键 IT 基础设施，云原生数据库只有发挥出最大的价值，才能推动业务发展。而这需要不断创新，不仅是先进的架构设计，而且与其他前沿的软硬件产品和技术搭配，软硬协同，从而实现最佳效用。

       原文标题 : 数据库“变调”：云原生数据库如何实现架构“再创新”？