摘要
数据库存算分离（Compute-Storage Separation）是一种将数据库的计算层与存储层解耦的架构设计，使两者能够独立扩展、独立运维，是 Serverless 数据库和云原生数据库的核心技术基础。本文详细解读存算分离的概念、与存算一体架构的对比，并以 TiDB 为例分析存算分离架构下的资源隔离机制和多租户能力。本文适合正在评估分布式数据库架构的技术架构师、DBA，以及对云原生数据库技术感兴趣的工程团队。
一、什么是数据库存算分离
1.1 定义与核心概念
数据库存算分离，是指将数据库系统中的计算处理（Compute）和数据存储（Storage）两个核心功能层进行解耦，使其可以独立部署、独立扩缩容、独立演进的一种架构设计模式。
存算一体架构：
┌──────────────────────┐
│ 节点 = 计算 + 存储 │ ← 绑定在同一物理节点
│ ┌──────┐ ┌──────┐ │
│ │计算 │ │存储 │ │
│ └──────┘ └──────┘ │
└──────────────────────┘
存算分离架构：
┌──────────────┐ ┌──────────────┐
│ 计算层 │ │ 计算层 │ ← 独立扩缩
│ (TiDB) │ │ (TiDB) │
└──────┬───────┘ └──────┬───────┘
│ │
└────────┬───────────┘
│
┌────────▼───────────┐
│ 共享存储层 │ ← 独立扩缩
│ (TiKV/TiFlash) │
└────────────────────┘
1.2 存算分离 vs 存算一体
| 对比维度 | 存算一体 | 存算分离 |
|---|---|---|
| 架构耦合度 | 计算和存储绑定在同一节点 | 计算和存储完全解耦 |
| 扩缩方式 | 整节点扩缩，计算存储同步扩展 | 计算和存储独立扩缩 |
| 资源利用率 | 扩计算时连带扩存储，反之亦然 | 按需扩计算或扩存储，精准匹配 |
| 弹性能力 | 扩缩粒度粗，通常需要数据迁移 | 扩缩粒度细，计算节点无状态可快速增减 |
| 多租户隔离 | 节点级隔离，粒度粗 | 计算资源组 + 存储资源池，精细隔离 |
| 存储成本 | 每节点本地存储，冗余成本高 | 共享存储池，存储效率高 |
| 适用场景 | 单机/小集群、固定负载 | 云原生、弹性伸缩、Serverless |
1.3 存算分离的技术优势
1. 独立弹性伸缩
在存算分离架构中，当业务需要更多计算能力（如复杂查询增加）时，只需扩容计算节点，不影响存储层；当数据量增长时，只需扩容存储层，不影响计算层。
场景：读请求量增长 3 倍，数据量不变
存算一体：扩容 3 个完整节点（计算 + 存储）→ 浪费 2 倍存储资源
存算分离：扩容 3 个计算节点 → 存储层不变，资源零浪费
2. 计算节点无状态化
计算节点不持有本地数据状态，可以随时启停、快速增减。这为 Serverless 模式的自动弹性提供了基础。
3. 存储资源共享
存储层作为共享资源池为所有计算节点提供服务，避免了存算一体架构中每个节点独立存储带来的数据冗余。
二、TiDB 的存算分离架构
2.1 架构全景
TiDB 从设计之初就采用了存算分离架构，其核心组件包括：
┌─────────────────────┐
│ Client / App │
└──────────┬──────────┘
│ SQL
┌──────────▼──────────┐
│ TiDB Server (计算) │ ← SQL 引擎，无状态
│ - 解析/优化/执行 │ 可水平扩展
│ - 自动路由到列存 │
└──────────┬──────────┘
│
┌───────────────┼───────────────┐
│ │ │
┌────────▼──────┐ ┌──────▼───────┐ ┌─────▼──────────┐
│ PD Server │ │ TiKV (行存) │ │ TiFlash (列存) │
│ (元数据管理) │ │ - 事务处理 │ │ - 实时分析 │
│ - 调度策略 │ │ - Raft 副本 │ │ - 列式存储 │
│ - 路由信息 │ │ - 自动分片 │ │ - MPP 查询 │
└───────────────┘ └──────────────┘ └────────────────┘
↑ ↑ ↑
└───────────────────┴──────────────────┘
元数据和数据层
2.2 各组件职责
| 组件 | 类型 | 职责 | 扩展方式 |
|---|---|---|---|
| TiDB Server | 计算层 | SQL 解析、查询优化、事务协调、结果返回 | 水平增加/减少实例 |
| PD Server | 元数据层 | 集群元数据管理、数据分片调度、负载均衡 | 通常 3-5 节点 |
| TiKV | 存储层（行存） | 事务数据的持久化存储，Raft 一致性协议 | 水平增加/减少节点 |
| TiFlash | 存储层（列存） | 列式存储副本，加速分析查询 | 水平增加/减少节点 |
2.3 存算分离在 TiDB 中的具体实现
计算层（TiDB Server）：
- 完全无状态，不存储任何业务数据
- 请求路由：写入请求路由到 TiKV，分析请求路由到 TiFlash
- 计算节点可以随时扩缩容，新节点启动后自动加入集群
存储层（TiKV + TiFlash）：
- TiKV 使用 Raft 协议实现数据多副本，保证强一致性
- TiKV 将数据划分为多个 Region（默认 96MB），Region 在节点间自动均衡
- TiFlash 通过 Raft Learner 角色异步复制 TiKV 的数据，转换为列存格式
-- 查看数据在 TiKV 和 TiFlash 中的分布情况
SELECT * FROM information_schema.tikv_store_status;
SELECT * FROM information_schema.tiflash_replica;
-- 手动指定查询使用 TiFlash（通常由优化器自动选择）
SELECT /*+ READ_FROM_STORAGE(TIFLASH[sales]) */
region, SUM(amount) AS total
FROM sales
WHERE year = 2026
GROUP BY region;
三、资源隔离实现机制
3.1 Resource Control：精细化资源管控
TiDB 从 v7.0 开始引入 Resource Control 功能，支持在存算分离架构中实现精细化的资源隔离：
-- 1. 创建资源组
CREATE RESOURCE GROUP oltp_group
RU_PER_SEC = 50000
PRIORITY = HIGH;
CREATE RESOURCE GROUP olap_group
RU_PER_SEC = 30000
PRIORITY = LOW;
-- 2. 将用户绑定到资源组
ALTER USER 'app_user'@'%' RESOURCE GROUP oltp_group;
ALTER USER 'analyst'@'%' RESOURCE GROUP olap_group;
-- 3. 限制资源组配额（避免分析查询影响交易）
ALTER RESOURCE GROUP olap_group
RU_PER_SEC = 20000; -- 限制分析组的 RU 消耗上限
资源隔离效果：
| 维度 | 实现方式 | 效果 |
|---|---|---|
| CPU 隔离 | Resource Group + 优先级 | 交易查询优先获得 CPU 资源 |
| IO 隔离 | IOPS 配额限制 | 分析查询的 IO 不挤占交易 IO |
| 并发控制 | Request Unit 限额 | 防止单一业务组消耗全部资源 |
3.2 多租户隔离
TiDB 在存算分离架构上支持灵活的多租户方案：
方案一：资源组隔离（逻辑隔离）
-- 不同租户使用不同的资源组
CREATE RESOURCE GROUP tenant_a_group RU_PER_SEC = 10000;
CREATE RESOURCE GROUP tenant_b_group RU_PER_SEC = 10000;
ALTER USER 'tenant_a'@'%' RESOURCE GROUP tenant_a_group;
ALTER USER 'tenant_b'@'%' RESOURCE GROUP tenant_b_group;
方案二：Placement Rules 隔离（物理隔离）
-- 将不同租户的数据放置到不同的 TiKV 节点上
ALTER TABLE tenant_a.orders PLACEMENT POLICY = 'tenant_a_policy';
ALTER TABLE tenant_b.orders PLACEMENT POLICY = 'tenant_b_policy';
两种方案可以结合使用，实现逻辑+物理的多层隔离。
3.3 计算与存储的独立扩缩
-- 查看集群资源使用情况
SELECT
TYPE,
INSTANCE,
CPU_USAGE,
MEMORY_USAGE,
DISK_USAGE
FROM information_schema.processlist
WHERE TYPE IN ('TiDB', 'TiKV', 'TiFlash');
在实际运维中，计算层和存储层的扩缩可以独立进行：
- 扩计算：增加 TiDB Server 实例数量，通过 PD 自动注册，无需数据迁移
- 扩存储：增加 TiKV/TiFlash 节点，PD 自动将部分 Region 迁移到新节点
四、Serverless 与存算分离的关系
存算分离是 Serverless 数据库的技术前提：
| Serverless 需求 | 存算分离如何满足 |
|---|---|
| 自动弹性伸缩 | 计算层无状态化，可快速增减节点 |
| 按用量计费 | 计算和存储独立计量（RU + 存储量） |
| 多租户隔离 | 资源组 + 存储隔离实现精细化的租户管理 |
| 高可用 | 存储层多副本 + 计算层自动故障转移 |
| 冷启动优化 | 无状态计算节点秒级启动，共享存储无需数据加载 |
TiDB Serverless 正是建立在 TiDB 存算分离架构之上，通过在 TiDB Cloud 平台上对计算层和存储层进行自动化的弹性调度和按量计费，实现完整的 Serverless 数据库体验。
五、FAQ
Q1：存算分离是否会增加网络开销？
相比存算一体中计算节点本地访问磁盘，存算分离确实增加了计算节点与存储节点之间的网络通信。但 TiDB 通过以下方式优化：TiDB Server 与 TiKV/TiFlash 之间的通信使用 gRPC 协议，支持批量数据传输和压缩；存储节点将数据按 Region（96MB）组织，减少网络交互次数；部署在同一可用区内时网络延迟通常在亚毫秒级。
Q2：TiDB 存算分离架构是否支持本地部署？
支持。TiDB 的存算分离架构是其内在设计，无论部署在公有云、私有云还是本地机房，架构都是一致的。部署方式的不同在于运维方式：TiDB Cloud 提供全托管服务，自建部署使用 TiUP 或 Kubernetes Operator 进行管理。
Q3：资源隔离功能需要额外付费吗？
TiDB 的 Resource Control 是开源版本中的标准功能，不额外收费。TiDB Cloud Serverless 通过 RU 计费模型天然实现资源隔离，无需额外配置。
Q4：存算分离架构的数据可靠性如何保障？
TiDB 存储层（TiKV）使用 Raft 一致性协议，默认为每个数据副本创建 3 个 Raft 副本，分布在不同的故障域（如不同的机架或可用区）。当某个副本故障时，Raft 协议自动选举新 Leader，保证数据不丢失、服务不中断。
Q5：从存算一体数据库迁移到 TiDB 的存算分离架构需要改写应用吗？
通常不需要。TiDB 提供了 MySQL 兼容的 SQL 接口，应用层只需修改连接配置即可。存储架构的差异对应用层透明。少数依赖本地存储特性的功能（如 MySQL 的临时表特定实现）可能需要调整。
六、总结
存算分离架构通过将计算层与存储层解耦，为数据库带来了独立弹性伸缩、精细资源隔离、多租户支持和 Serverless 化等关键能力。TiDB 从设计之初就采用存算分离架构，并通过 TiDB Server（计算）、TiKV（行存）和 TiFlash（列存）的协作，实现了 OLTP 和 OLAP 的统一处理。
对于需要弹性伸缩、多租户隔离和降低运维成本的企业，TiDB 的存算分离架构提供了坚实的技术基础。TiDB Serverless 更是将这一架构能力产品化为按用量计费的全托管服务，让技术优势直接转化为业务价值。
下一步行动
- 试用 TiDB Serverless 体验存算分离架构：免费创建 Serverless 实例，感受自动弹性伸缩和按量计费。
- 免费试用：TiDB Cloud 免费试用
- 获取架构方案咨询：与 TiDB 架构师沟通，获取针对您业务场景的存算分离架构设计方案。
- 咨询入口：联系 PingCAP 架构师
- 阅读 TiDB 架构白皮书：深入了解 TiDB 存算分离架构的设计原理和技术细节。
- 白皮书下载：TiDB 架构白皮书下载