跳到主要内容

PolarDB 存算分离

· 阅读需 7 分钟
tanzhuo

随着业务规模扩大，传统关系型数据库架构逐渐暴露出扩展能力不足、存储成本高、读写压力集中等瓶颈。云厂商为此设计了一种新的架构模式：存算分离（Storage-Compute Decoupling）。本文从架构角度分析 PolarDB 的存算分离设计，并与 AWS Aurora 以及传统 MySQL 架构进行对比。

背景​

PolarDB 是阿里云推出的一款云原生数据库，其核心设计理念之一就是 计算层与存储层解耦。这种架构使数据库具备更强的弹性扩展能力和更高的资源利用率。

传统 MySQL 架构的问题​

在传统 MySQL 架构中，数据库通常运行在单个服务器上，计算和存储都在同一台机器：

MySQL Server
 ├── CPU
 ├── Memory
 └── Local Disk      # 数据与计算绑定在同一台机器

这种架构在早期互联网时代已经足够，但随着业务规模扩大，会出现几个明显问题。

1) 存储扩展困难​

数据库数据通常存储在本地磁盘中，当数据量增长时，只能升级磁盘或更换更大的机器，扩展能力有限。

2) 读扩展成本高​

MySQL 常见的扩展方式是 主从复制：

Master
 ├── Slave1      # 每个从库都持有一份完整数据副本
 ├── Slave2
 └── Slave3

每个只读节点都需要一份完整的数据副本。随着读节点增加，存储成本会快速增长，数据同步压力也随之上升。

3) 高可用复杂​

如果主节点故障，需要手动或自动进行主从切换，期间可能存在复制延迟，数据一致性也需要额外处理。

PolarDB 的存算分离架构​

PolarDB 的核心设计是：计算节点与存储节点完全解耦。架构大致如下：

          +--------------------+
          |    Compute Node    |
          | (MySQL / PG / ORA) |   # 计算层：SQL 解析、执行、事务
          +---------+----------+
                    |
          +---------+----------+
          | Distributed Storage|   # 存储层：数据、日志、副本
          |     (PolarStore)   |
          +--------------------+

计算节点负责 SQL 解析、查询执行和事务处理；存储层负责数据存储、日志管理和副本复制。所有计算节点共享同一份分布式存储，这种架构被称为 Shared Storage Architecture。

存算分离解决了什么问题​

这种设计主要解决了传统数据库的几个核心问题。

1) 弹性扩展能力​

传统数据库增加计算能力必须升级服务器，而在 PolarDB 中可以直接增加计算节点：

Storage Layer
   ↑
   │
Compute1      # 新增计算节点无需复制数据
Compute2
Compute3

所有节点共享同一份数据，因此可以实现读扩展、分布式计算和秒级扩容。

2) 存储成本降低​

传统 MySQL 的读节点需要完整数据副本，而在存算分离架构下，多个计算节点共享同一存储系统，不需要复制完整数据，存储成本显著降低。

3) 高可用能力更强​

PolarDB 的存储层通常使用分布式副本机制：

Storage Node
 ├── Replica1      # 多副本保障数据持久化
 ├── Replica2
 └── Replica3

当某个节点故障时，系统可以极快地进行恢复。这种设计可以实现自动故障恢复、高可用架构和数据持久化保障。

4) 极致性能​

PolarDB 存储层通常采用分布式日志结构、并行 I/O 和 SSD 云存储，可以大幅提升数据库性能。主要瓶颈从存储层转移到了内部网络 I/O 层。

PolarDB 的劣势​

虽然存算分离架构有很多优势，但也存在一些挑战。

1) 网络延迟​

计算层与存储层分离意味着数据访问需要通过网络，相比本地磁盘会增加一定延迟。

2) 架构复杂度高​

存算分离架构需要设计分布式存储系统、网络协议和数据一致性机制，实现难度远高于传统数据库。

3) 对云基础设施依赖强​

这种架构高度依赖高性能网络、分布式存储和云平台调度能力，因此通常只适用于云环境。

PolarDB vs AWS Aurora​

PolarDB 和 Aurora 的整体设计理念非常接近，二者都是典型的 云原生数据库架构，都采用了 存算分离（Compute + Storage Decoupling） 的设计。

Aurora 将计算节点与一个分布式存储集群分离，多个计算节点共享同一存储系统。架构示意：

          Writer Node
               |
       +-------+-------+
       |               |
   Reader1         Reader2         # 读节点共享底层存储
       |               |
   +-----------------------+
   |   Distributed Storage |
   +-----------------------+

Aurora 的分布式存储通常跨多个可用区部署，以提升可用性。但在具体实现上，两者仍然存在一些重要差异。

1) 存储架构设计差异​

Aurora 的核心设计是 日志驱动存储（Log Structured Storage）。在 Aurora 中，计算节点并不会直接写入数据库页，而是将 redo log 发送到存储节点，存储层根据这些日志来重建数据页。简化后的流程如下：

Client
↓
Aurora Compute Node
↓
Redo Log                    # 只传输日志，不传输完整数据页
↓
Distributed Storage Nodes
↓
Storage Node 重建数据页

Aurora 的存储层通常由 6 个副本组成，分布在 3 个可用区（AZ）：

AZ1 : Storage Node A / Storage Node B
AZ2 : Storage Node C / Storage Node D
AZ3 : Storage Node E / Storage Node F

写入时只需要 4/6 quorum 即可提交事务。这种设计带来了几个优势：

  • 写入只需要发送日志，网络传输量更小
  • 不需要完整复制数据库页
  • 故障恢复速度更快

而 PolarDB 的存储实现方式略有不同。PolarDB 采用的是 共享分布式存储（Shared Storage） 架构，计算节点可以直接访问底层的 PolarStore / PolarFS 分布式文件系统，数据库页仍然以页的形式存储。简化结构如下：

Client
↓
Compute Node (MySQL / PG / Oracle)
↓
PolarFS / PolarStore        # 分布式文件系统，页式存储
↓
Distributed Storage Nodes

这种设计更接近传统数据库的存储方式，因此数据页结构保持兼容，对数据库内核改动相对较小。但在写入路径上，网络传输的数据量可能比 Aurora 的日志方式更大。

2) 读节点架构​

Aurora 的读节点主要是 Reader Instance，读节点通常只负责读取数据，写操作集中在 Writer Node。PolarDB 则支持一种 Reader Node + 主节点共享存储 的模式，多个节点可以直接访问共享存储，从而实现更灵活的读扩展。

3) 生态与兼容性策略​

Aurora 是 AWS 深度改造后的数据库引擎，虽然兼容 MySQL / PostgreSQL，但底层实现已经发生了较大变化。PolarDB 则更加注重 原生数据库兼容性：

  • PolarDB MySQL
  • PolarDB PostgreSQL
  • PolarDB Oracle

因此很多应用迁移到 PolarDB 时，修改成本会更低。

小结​

存算分离的本质，是把数据库的计算能力和存储能力拆成两个可以独立扩展的层。PolarDB 通过共享分布式存储换来了秒级扩容、低成本读扩展和更强的高可用能力，代价则是网络延迟和更高的架构复杂度。与 Aurora 相比，两者理念相近，但 PolarDB 走的是共享文件系统路线，更贴近传统数据库的存储形态，兼容性更好；Aurora 则用日志驱动存储换取了更小的写入传输量。理解这两条路线的取舍，对评估云数据库选型很有帮助。

评论 / COMMENTS