---

摘要

PolarDB 是阿里云自研的 云原生关系型数据库，100% 兼容 MySQL、PostgreSQL 及 Oracle 语法，采用 存储计算分离 + 分布式共享存储 架构，将传统数据库的性能瓶颈逐一打破——单库最大 100 TB、最高 100 万 QPS、读写节点秒级弹性扩展。本文从 PolarFS 分布式文件系统、物理复制机制、全局一致性读、HTAP 混合负载、Serverless 架构五个层面剖析 PolarDB 的核心技术。

---

一、架构核心：存储计算分离

1.1 传统 MySQL vs PolarDB

` 传统 MySQL (主从复制): ┌──────────────────┐ Binlog 复制 ┌──────────────────┐ │ 主库 (RW) │ ─────────────────→ │ 从库 (RO) │ │ • 计算 + 存储 │ 异步/半同步 │ • 计算 + 存储 │ │ • 本地磁盘 │ │ • 本地磁盘 │ └──────────────────┘ └──────────────────┘ 痛点: ✗ 数据多副本 = 存储成本 ×3+ ✗ 从库有 分钟级 延迟 ✗ 扩容需拷贝数据 ✗ 只读节点需独立存储

PolarDB (存算分离): ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ RW Node │ │ RO Node 1│ │ RO Node 2│ │ RO Node N│ │ (读写) │ │ (只读) │ │ (只读) │ │ (最多15) │ │ MySQL │ │ MySQL │ │ MySQL │ │ MySQL │ │ 8.0 内核 │ │ 8.0 内核 │ │ 8.0 内核 │ │ 8.0 内核 │ │ • 计算 │ │ • 计算 │ │ • 计算 │ │ • 计算 │ │ • 日志生成│ │ • 日志应用│ │ • 日志应用│ │ • 日志应用│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ REDO Log │ │ │ └──────┬──────┴──────────────┴──────────────┘ │ ┌───────────▼────────────────────────────────────┐ │ PolarFS 分布式共享文件系统 │ │ │ │ ┌────────────────────────────────────────────┐ │ │ │ PolarStore (存储集群) │ │ │ │ • 数据 3 副本 (AZ内) │ │ │ │ • Chunk 粒度: 10 GB │ │ │ │ • RDMA 网络访问 (微秒级延迟) │ │ │ │ • 自动修复 / 再平衡 / 扩缩容 │ │ │ └────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────┘ `

1.2 核心收益

| 特性 | 传统 MySQL | PolarDB | |------|:---:|:---:| | 存储成本 | 3倍 (主+从+备) | 1倍 (共享) | | 只读延迟 | 秒-分钟级 | < 5ms | | 扩容时间 | 小时级 (拷贝数据) | < 5 分钟 (只加计算节点) | | 最大容量 | ~2 TB (受本地磁盘限制) | 100 TB | | 只读节点数 | 5-10 | 15 (可扩) | | Crash Recovery | 分钟级 (应用 Binlog) | < 60 秒 (共享 REDO) |

---

二、PolarFS：分布式文件系统

2.1 架构设计

PolarFS 是专为 PolarDB 设计的高性能用户态文件系统，运行在计算节点上：

` 传统文件系统 I/O 路径: App → VFS → ext4/xfs → Block Layer → NVMe

PolarFS I/O 路径: App → 用户态 PolarFS → RDMA → PolarStore (跳过内核, 零拷贝, 微秒级延迟)

技术特征: • 用户态实现，避免内核态上下文切换 • RDMA 网络协议（高性能计算网络） • 并行日志写入 (Parallel WAL) • 原子写 512 字节扇区粒度 • 与 MySQL 内核深度耦合的 Direct I/O `

2.2 存储组织结构

` PolarFS 存储层级:

PolarDB Cluster └── PolarDB Instance (单实例) └── Volume (一个数据库实例的存储空间) ├── Chunk 0 (10 GB) → PolarStore ChunkServer #1 ├── Chunk 1 (10 GB) → PolarStore ChunkServer #2 ├── Chunk 2 (10 GB) → PolarStore ChunkServer #3 └── ... │ ├── Segment (2 MB) — 基本分配单位 └── Block (16 KB) — 最小 I/O 单位

特点: • 每个 Chunk 包含 3 个副本分布在 3 台 ChunkServer • 三副本使用 Parallel Raft 协议保证一致性 • Chunk 自动分裂/合并以适应读写热点 `

---

三、物理复制机制

3.1 为什么不用 Binlog？

` MySQL 主从复制 (Binlog): Master: Execute SQL → Write Binlog (Logical) ↓ (异步/半同步) Slave: Read Binlog → Replay SQL (Logical) ✗ Logical replay 需要重新解析 SQL → 慢 ✗ binlog 格式复杂 (ROW/STATEMENT/MIXED) ✗ 大事务在主从间有明显延迟

PolarDB 物理复制 (REDO-based): RW Node: Execute → Write REDO Log → Flush to PolarFS RO Node: Read REDO Log from PolarFS → Apply to memory ✓ 不需要解析 SQL，直接应用数据页修改 ✓ REDO 格式简单固定，效率极高 ✓ 只读节点延迟 < 5ms（同一 PolarFS 上读 REDO） `

3.2 REDO Log 复制的代际演进

| 代际 | 机制 | 延迟 | 说明 | |------|------|:---:|------| | v1 | Log Shipping | 50-100ms | 早期：RW 将 REDO 推送给 RO | | v2 | Shared REDO | 5-10ms | RO 主动从 PolarFS 拉取 REDO | | v3 | RDMA Log | < 5ms | RDMA 单边读取，CPU 开销接近零 |

---

四、全局一致性读 (GCR)

传统只读节点存在 复制延迟导致的「幻读」 问题，PolarDB 的 GCR 通过 LSN 同步机制 解决：

` 场景：用户刚下单 → 立即查自己的订单

解决方案: 读写分离 + 全局 LSN 同步

1. RW 写入订单 → REDO LSN = 10001 2. RW 将 LSN 返回给 App (通过 Proxy) 3. App 携带 LSN = 10001 访问 RO 节点 4. RO 检查自己已应用的 REDO LSN: • 如果 LSN >= 10001 → 立即返回查询结果 • 如果 LSN < 10001 → 等待（或通知 Proxy 转发到 RW） 5. RO 返回一致的结果

代码示例 (MySQL 客户端): `sql -- 插入后立即获取全局 LSN SET @polar_lsn = polar_get_lsn(); -- 随后在 RO 上查询时带上 LSN SELECT /+ POLAR_LSN(@polar_lsn) / * FROM orders WHERE user_id = 12345; `

---

五、HTAP：行列混存混合负载

5.1 架构设计

PolarDB 的 HTAP 方案是在同一集群内部署 行存 + 列存 两种存储引擎：

` ┌────────────────────────────────────────────────┐ │ PolarDB 集群 │ ├────────────────────────────────────────────────┤ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ RW Node │ │ IMCI Node │ │ │ │ (InnoDB 行存) │ │ (IMCI 列存) │ │ │ │ │ │ │ │ │ │ OLTP 查询 │ │ OLAP 查询 │ │ │ │ POINT SELECT │ │ 聚合/Join │ │ │ │ CRUD │ │ 大范围扫描 │ │ │ │ 毫秒级 │ │ 列裁剪 + 向量化 │ │ │ └────────┬─────────┘ └────────┬─────────┘ │ │ │ │ │ │ └──── REDO 日志 ───────┘ │ │ │ │ │ ┌───────────▼───────────┐ │ │ │ PolarFS (共享存储) │ │ │ │ 行存数据 + 列存数据 │ │ │ └───────────────────────┘ │ └────────────────────────────────────────────────┘

行存 → 列存的同步: • 基于 REDO Log 的实时转换 • 延迟 < 1 秒 (准实时) • 自动维护列存副本 `

5.2 性能对比

` 测试: TPC-H Q1 (lineitem 表 600M 行聚合查询)

在 InnoDB 行存引擎: SELECT sum(l_quantity), sum(l_extendedprice) FROM lineitem WHERE l_shipdate <= '1998-09-02'; 执行时间: 42 秒 (全表扫描, 290 GB)

在 IMCI 列存引擎: 同一个查询自动路由到列存: 执行时间: 1.2 秒 (列裁剪仅读 2/16 列, 向量化聚合) 加速比: 35× `

---

六、Serverless：弹性自动伸缩

6.1 核心机制

PolarDB Serverless 不需要用户事先配置 CPU/内存规格，根据实际负载自动伸缩：

` Serverless 伸缩过程:

┌─────────────────────────────────────────┐ │ PolarProxy (智能代理) │ │ • 实时监控 QPS / CPU / 连接数 / 活跃事务 │ │ • 预测负载趋势 (ML-based) │ │ • 触发弹性扩缩决策 │ └───────────────┬─────────────────────────┘ │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ ┌───────┐ ┌───────┐ ┌───────┐ │ PCU 1 │ │ PCU 2 │ │ PCU N │ │ (最小) │ │ │ │ (最大) │ └───────┘ └───────┘ └───────┘ PCU (PolarDB Capacity Unit): 1 PCU ≈ 1 核 + 2 GB 内存

伸缩粒度: 0.5 PCU 伸缩速度: < 5 秒 (秒级) 最小起步: 0.5 PCU 最大上限: 32 PCU (可按需提升)

触发条件: • CPU > 70% → 扩容 +2 PCU • CPU < 30% → 缩容 -1 PCU • 连接数 > 阈值 × 0.8 → 扩容 `

6.2 适用场景与成本

| 场景 | 典型请求曲线 | Serverless 节省 | |------|------|:---:| | 开发/测试环境 | 工作日 9-18 点 | 70%+ | | 低频 SaaS 应用 | 偶尔访问 | 80%+ | | IoT 数据写入 | 白天多夜间少 | 50%+ | | 定时任务 | 每天凌晨 2 点跑批 | 90%+ |

---

七、PolarDB-X：原生分布式

当单库 100 TB 不够时，PolarDB-X 提供水平分片能力：

` PolarDB-X 架构:

┌──────────────────────────────────────────┐ │ X-Proxy (SQL 路由) │ │ 自动分片路由 / 分布式查询优化 / 跨分片事务 │ └──────┬───────────────┬───────────────────┘ │ │ ┌────▼────┐ ┌─────▼────┐ ┌─────────┐ │ Shard 0 │ │ Shard 1 │ │ Shard N │ │ (PolarDB│ │ (PolarDB │ │ (PolarDB│ │ 实例) │ │ 实例) │ │ 实例) │ │ 0-4095 │ │ 4096-8191│ │ ... │ └─────────┘ └──────────┘ └─────────┘

分片策略: • Hash: 按主键哈希均匀分布 • Range: 按范围分布（如按时间） • List: 按枚举值分布（如按地区） 分布式事务: • XA 2PC (传统方案) • TSO (Timestamp Oracle) 全局时钟 • Percolator 风格的乐观事务

关键指标: • 最大节点数: 1024 • 单表 TPS: 线性扩展 • 跨分片事务 TPS: ~30000/s (乐观) / ~15000/s (悲观) `

---

八、与竞品对比

| 维度 | PolarDB | AWS Aurora | Google Cloud SQL | Azure DB | |------|:---:|:---:|:---:|:---:| | MySQL兼容 | 100% | 100% | 100% | 100% | | PG兼容 | 100% | 100% | 100% | ❌ | | Oracle兼容 | ✅ 极高 | ❌ | ❌ | ❌ | | 存算分离 | ✅ PolarFS | ✅ 自研 | ❌ (本地SSD) | ✅ (部分) | | 分布式FS | PolarFS (自研) | 自研 | ❌ (Colossus) | 自研 | | RDMA网络 | ✅ | ❌ | ❌ | ❌ | | 物理复制 | ✅ REDO | ✅ REDO | ❌ | ❌ | | 全局一致性读 | ✅ GCR | ✅ (Aurora Global) | ❌ | ❌ | | HTAP | ✅ IMCI | ❌ (需Redshift) | ❌ (需BigQuery) | ❌ | | Serverless | ✅ 秒级 | ✅ v2 (秒级) | ❌ (仅Cloud Run) | ✅ (分钟级) | | 分布式 | ✅ PolarDB-X | ✅ Aurora DSQL | ❌ (需Spanner) | ❌ | | TPC-C | 全球第一 | 未公开 | 未公开 | 未公开 |

---

九、典型架构实践

`yaml

出海电商架构

架构: Web/App: - 弹性伸缩 ECS 集群 - SLB 负载均衡 缓存层: - Redis Cluster (热数据) - 商品详情 / 购物车缓存 数据库层: 主库: - PolarDB MySQL 8.0 (新加坡 ap-southeast-1) - 规格: 16核 64GB - 存储: 2 TB (按量自动扩展) - 开启: 全局一致性读 + IMCI 列存 只读实例: - RO-1: 16核 64GB (订单查询专用) - RO-2: 16核 64GB (商品查询专用) - RO-3: 16核 64GB (报表) 跨国容灾: - PolarDB Global Database - 主: 新加坡 → 备: 法兰克福 - RPO < 1秒, RTO < 1分钟 分析层: - IMCI 列存 (AP 查询) - 替代独立的数据仓库，降低成本 50%+ `

---

总结

PolarDB 的技术路线非常清晰：在极致兼容 MySQL/PostgreSQL/Oracle 的前提下，用存算分离 + 物理复制 + RDMA 改写数据库的底层架构，再以 HTAP 和 Serverless 覆盖更多场景。它的最大差异化是 Oracle 兼容能力，使得传统企业去 Oracle 上云时无需重写应用。同时全球 TPC-C 性能第一也证明了其自研内核的实力。

---

系列文章索引

| # | 文章 | 核心主题 | |---|------|----------| | 1 | 阿里云国际版架构与核心服务深度概览 | 全球Region/AZ、神龙架构、存储/网络、安全合规 | | 2 | MaxCompute+DataWorks大数据平台深度解析 | 盘古FS、SQL优化器、端到端ETL | | 3 | PolarDB云原生数据库技术解析 | PolarFS、物理复制、HTAP、Serverless |

---

> 关于作者：本文为阿里云国际版技术系列文章，旨在帮助出海技术团队快速掌握阿里云核心技术栈。所有性能数据均来自阿里云官方文档和公开基准测试，实际数据可能因配置和负载不同而有所差异。