PolarDB 存算分离

tanzhuo -

背景

随着互联网业务规模不断扩大，传统关系型数据库架构逐渐暴露出一些瓶颈，例如扩展能力不足、存储成本高、读写压力集中等问题。为了应对这些挑战，云厂商开始设计一种新的数据库架构模式：存算分离（Storage-Compute Decoupling）。

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

本文将从架构角度分析 PolarDB 的存算分离设计，并与 AWS Aurora 以及传统 MySQL 架构进行对比。

传统 MySQL 架构的问题

在传统 MySQL 架构中，数据库通常运行在单个服务器上：

MySQL Server
 ├── CPU
 ├── Memory
 └── Local Disk

计算和存储都在同一台机器上。

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

1 存储扩展困难

数据库数据通常存储在本地磁盘中，当数据量增长时，只能通过：

  • 升级磁盘
  • 更换更大的机器

这种方式扩展能力有限。

2 读扩展成本高

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

Master
 ├── Slave1
 ├── Slave2
 └── Slave3

每个只读节点都需要一份完整的数据副本。

随着读节点增加：

  • 存储成本会快速增长
  • 数据同步压力增加

3 高可用复杂

如果主节点故障：

  • 需要手动或自动进行主从切换
  • 可能存在复制延迟
  • 数据一致性需要额外处理

PolarDB 的存算分离架构

PolarDB 的核心设计是：

计算节点与存储节点完全解耦。

架构大致如下：

          +--------------------+
          |    Compute Node    |
          | (MySQL / PG / ORA) |
          +---------+----------+
                    |
          +---------+----------+
          | Distributed Storage|
          |     (PolarStore)   |
          +--------------------+

计算节点负责：

  • SQL解析
  • 查询执行
  • 事务处理

存储层负责：

  • 数据存储
  • 日志管理
  • 副本复制

所有计算节点共享同一份分布式存储。

这种架构被称为：

Shared Storage Architecture

存算分离解决了什么问题

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

1 弹性扩展能力

在传统数据库中：

增加计算能力必须升级服务器。

而在 PolarDB 中：

可以直接增加计算节点：

Storage Layer
   ↑
   │
Compute1
Compute2
Compute3

所有节点共享同一份数据。

因此可以实现：

  • 读扩展
  • 分布式计算
  • 秒级扩容

2 存储成本降低

传统 MySQL 读节点需要完整数据副本。

PolarDB 的存算分离架构下：

多个计算节点共享同一存储系统。

因此：

  • 不需要复制完整数据
  • 存储成本显著降低

3 高可用能力更强

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

Storage Node
 ├── Replica1
 ├── Replica2
 └── Replica3

当某个节点故障时：系统可以极快的进行恢复。

这种设计可以实现：

  • 自动故障恢复
  • 高可用架构
  • 数据持久化保障

4 极致性能

PolarDB 存储层通常采用：

  • 分布式日志结构
  • 并行 I/O
  • SSD 云存储

这种方式可以大幅提升数据库性能。主要瓶颈从存储层变化为了内部网络IO层。

polarDB 的劣势

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

1 网络延迟

计算层与存储层分离意味着：

数据访问需要通过网络。

相比本地磁盘：

会增加一定延迟。

2 架构复杂度高

存算分离架构需要设计：

  • 分布式存储系统
  • 网络协议
  • 数据一致性机制

实现难度远高于传统数据库。

3 对云基础设施依赖强

这种架构高度依赖：

  • 高性能网络
  • 分布式存储
  • 云平台调度能力

因此通常只适用于云环境。

PolarDB vs AWS Aurora

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

Aurora 也是一种 存算分离数据库。

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

架构示意：

          Writer Node
               |
       +-------+-------+
       |               |
   Reader1         Reader2
       |               |
   +-----------------------+
   |   Distributed Storage |
   +-----------------------+

Aurora 的分布式存储通常跨多个可用区部署，以提升可用性。

但在具体实现上，两者仍然存在一些重要差异。

首先是 存储架构设计差异。

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 的日志方式更大。

第二个差异是 读节点架构。

Aurora 的读节点主要是 Reader Instance，读节点通常只负责读取数据，而写操作集中在 Writer Node。

PolarDB 则支持一种叫做 Reader Node + 主节点共享存储 的模式，多个节点可以直接访问共享存储，从而实现更灵活的读扩展。

第三个差异是 生态与兼容性策略。

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

PolarDB 则更加注重 原生数据库兼容性：

  • PolarDB MySQL
  • PolarDB PostgreSQL
  • PolarDB Oracle

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