CLOUD技术笔记PolarDB 是阿里云自主研发的云原生数据库，与其他主流云原生数据库（如 AWS Aurora、Google Cloud Spanner、Azure Cosmos DB、腾讯云TDSQL-C等）在性能方面各有特点。以下是 PolarDB 与这些数据库在关键性能维度上的对比分析：
- 读写性能
-
PolarDB：
- 采用“计算与存储分离”架构，支持最高 100TB 的共享存储。
- 写入性能：通过日志即数据（Redo Log Offload）技术，将日志写入共享存储，显著降低主节点压力，提升写入吞吐。
- 读性能：支持最多 15 个只读节点，读扩展能力强，延迟通常在毫秒级。
- 实测场景中，在 OLTP 负载下，PolarDB MySQL 版可达到百万级 QPS。
-
AWS Aurora：
- 类似 PolarDB 的存算分离架构，底层存储自动复制6份，跨3个可用区。
- 宣称写入性能可达标准 MySQL 的 3–5 倍，但实际高并发场景下可能受网络和存储层延迟影响。
- 支持最多 15 个只读副本，读扩展性良好。
-
Google Cloud Spanner：
- 强一致性全局分布式数据库，适合跨区域事务。
- 性能牺牲部分延迟换取全球一致性和高可用性，不适合低延迟 OLTP 场景。
- 写入延迟较高（通常几十到上百毫秒），适合对一致性要求极高的类应用。
-
Azure Cosmos DB：
- 多模型 NoSQL 数据库，支持强/最终一致性。
- 性能以 RU/s（Request Units）衡量，延迟可低至个位数毫秒（在强一致性模式下略高）。
- 更适合非结构化数据和高并发读写场景，但不支持传统 SQL 事务完整性。
小结：在常规 OLTP 场景下，PolarDB 和 Aurora 性能接近，均优于传统 RDS；Spanner 和 Cosmos DB 更偏向分布式一致性或 NoSQL 场景，性能目标不同。
- 弹性伸缩能力
-
PolarDB：
- 计算节点支持秒级变配（垂直扩容），存储自动弹性扩展（无需停机）。
- 只读节点可快速增减，实现读负载动态调整。
-
Aurora：
- 支持 Aurora Serverless v2，可自动扩缩容，但冷启动时间较长。
- 存储自动扩展，但计算资源调整不如 PolarDB 灵活。
-
Spanner / Cosmos DB：
- 基于资源单位（如 Spanner 的 Processing Units，Cosmos DB 的 RU/s）动态调整，按需付费。
- 弹性好，但成本模型复杂，突发流量可能导致费用飙升。
PolarDB 在传统关系型数据库的弹性体验上更贴近用户习惯，尤其适合业务波动大的场景。
- 高可用与故障恢复
-
PolarDB：
- 主备切换时间 < 30 秒，基于共享存储，无需数据复制。
- 存储多副本（通常三副本），保障数据安全。
-
Aurora：
- 故障恢复快（宣称 < 30 秒），存储层自动修复。
- 日志流式同步到存储层，主节点故障时可快速选举新主。
-
Spanner：
- 全局高可用，自动故障转移，强一致性保障。
- 但跨区域部署成本高，延迟敏感。
PolarDB 和 Aurora 在单区域高可用方面表现优异，Spanner 更适合跨地域容灾。
- 兼容性与生态
-
PolarDB：
- 高度兼容 MySQL、PostgreSQL、Oracle 语法，迁移成本低。
- 支持存储过程、触发器、视图等完整功能。
-
Aurora：
- 兼容 MySQL 和 PostgreSQL，但在某些高级特性上有差异。
-
Spanner / Cosmos DB：
- 不完全兼容传统 SQL，开发适配成本高。
PolarDB 在兼容性方面优势明显，特别适合从传统数据库迁移上云的用户。
- 成本效率
-
PolarDB：
- 存算分离，存储按量计费，相比传统 RDS 可节省 50% 以上成本。
- 只读节点共享同一存储，避免数据复制开销。
-
Aurora：
- 成本相对较高，尤其是 IO 和备份费用。
-
Spanner / Cosmos DB：
- 按资源单位计费，突发负载可能导致成本不可控。
✅ 总结对比表：
| 特性 | PolarDB | AWS Aurora | Google Spanner | Azure Cosmos DB |
|---|---|---|---|---|
| 架构 | 存算分离 | 存算分离 | 分布式强一致 | 多模型 NoSQL |
| 写入性能 | 高（日志卸载） | 高（3–5x MySQL） | 中（延迟较高） | 高（RU/s 模型） |
| 读扩展性 | 最多15只读节点 | 最多15只读节点 | 自动分片 | 全球读副本 |
| 弹性伸缩 | 秒级变配 + 自动存储 | Serverless v2 | 动态扩缩 Processing Units | RU/s 动态调整 |
| 高可用恢复时间 | < 30 秒 | < 30 秒 | 自动跨区域 | 快速故障转移 |
| SQL 兼容性 | 高（MySQL/PG/Oracle） | 高（MySQL/PG） | 有限（ANSI SQL） | 有限（SQL API） |
| 成本效率 | 高（共享存储） | 中 | 高（但贵） | 中（突发成本高） |
| 适用场景 | OLTP、混合负载 | OLTP、Web 应用 | 全球分布式事务 | NoSQL、高并发读写 |
📌 结论：
PolarDB 在传统关系型数据库的性能、兼容性、成本和弹性方面综合表现优异，特别适合需要高性能 OLTP、平滑迁移上云、读写分离和高性价比的企业应用。相比之下：
- 若需全球强一致性 → 考虑 Spanner；
- 若使用 NoSQL 或多模型 → 考虑 Cosmos DB；
- 若深度绑定 AWS 生态 → Aurora 是不错选择；
- 若追求兼容性、性能与成本平衡 → PolarDB 是极具竞争力的选择。
实际选型还需结合业务场景、地域部署、合规要求等因素综合评估。