阿里云PolarStore数据库存储系统架构与优化实践

1. PolarStore系统架构解析

PolarStore是阿里巴巴为云原生数据库设计的创新存储系统，其核心创新在于硬件/软件协同的双层压缩架构。这个设计源于我们对现代数据库工作负载的深入观察：传统压缩方案要么牺牲性能换取高压缩率，要么为保持低延迟而接受较低的压缩效率。

1.1 双层压缩架构设计

系统采用硬件和软件两个层次的压缩协同工作：

• 硬件层：基于PolarCSD计算存储设备实现，使用专用压缩引擎处理数据块
• 软件层：在数据库引擎中实现，针对特定数据类型和工作负载优化

这种分层设计带来了三个关键优势：

1. 硬件压缩提供基础的高吞吐量处理能力
2. 软件压缩可根据数据特征进行精细优化
3. 两层之间可以动态协调，实现最佳的性能/压缩率平衡

实际部署中发现，单纯依赖硬件压缩时平均压缩比为2.35x，而启用双层压缩后提升至3.55x，存储成本降低60%。

1.2 计算存储设备(CSD)的关键作用

PolarCSD设备是系统的硬件基础，经历了两个主要版本迭代：

• PolarCSD1.0：采用开放通道架构，依赖主机CPU执行FTL功能
• PolarCSD2.0：回归传统设备管理FTL，解决资源争用问题

版本升级带来了显著改进：

• 单设备故障不再影响整个主机
• 尾延迟超过4ms的I/O操作减少36-38倍
• 支持每设备9.6TB逻辑容量，存储密度提升20%

2. 数据库优化的压缩技术

2.1 动态压缩算法选择机制

系统创新性地实现了运行时压缩算法选择，核心逻辑包括：

1. 初始写入时评估页面特征
2. 当更新日志大小超过原始页面30%时触发重新评估
3. 仅在CPU利用率低时执行选择算法，避免性能影响

算法选择标准：

def select_algorithm(page): if page.update_frequency > threshold: return "lz4" # 优先考虑解压速度 elif page.entropy > threshold: return "zstd" # 高熵值数据适用高压缩率算法 else: return default_algorithm

实际生产数据显示不同工作负载的算法分布：

2.2 页读取尾延迟优化

针对页读取的尾延迟问题，系统利用CSD的空间解耦特性实现每页日志优化：

1. 问题场景分析：

   • 页面不存在但部分redo日志未缓存时
   • 需要多次随机读取分散的日志记录
   • 传统方式产生读放大效应

2. 解决方案：

   • 为每个页面预留专用4KB日志空间
   • 后台预合并相关redo日志
   • 读取时单次I/O即可获取全部所需日志

3. 效果验证：

   • 在128线程以下场景，P95延迟降低28.9-39.5%
   • 仅增加约25%的空间开销（传统SSD无法实现）

3. 大规模部署实践

3.1 主机级稳定性保障

从PolarCSD1.0到2.0的演进解决了关键稳定性问题：

1. 资源争用问题：

   • 原架构每个设备需要15.36GB内存用于FTL
   • 12个设备需184.32GB内存和24个CPU核心
   • 新架构将FTL移至设备内部，消除主机资源压力

2. 故障域隔离：

   • 设备驱动bug可能导致整个主机故障
   • 新设计将故障限制在单个设备内

3.2 集群级空间管理

3.2.1 压缩感知调度算法

创新性的二维调度策略：

1. 将存储节点按逻辑空间和物理空间使用率绘制在二维平面
2. 定义四个操作区域：
   • 区域A：高物理空间使用，低逻辑空间使用
   • 区域D：低物理空间使用，高逻辑空间使用
3. 迁移策略：
   • 从A区迁出低压缩比块到D区
   • 从D区迁出高压缩比块到A区

3.2.2 调度效果验证

生产集群调度前后对比：

PolarCSD1.0集群：

• 调度前：节点压缩比差异显著(1.2-3.8x)
• 调度后：90%节点压缩比集中在2.2-2.7x

PolarCSD2.0集群：

• 调度前：物理空间使用不均衡
• 调度后：87.7%节点压缩比在3.15-3.85x之间

4. 生产环境性能评估

4.1 整体性能表现

使用Sysbench OLTP基准测试对比：

4.2 技术分解评估

逐步启用各项技术的性能影响：

1. 仅硬件压缩：

   • 压缩比2.12-3.84x
   • 吞吐量降低7.4%

2. 增加软件压缩：

   • 压缩比提升21.7-50.3%
   • 吞吐量再降19.6%

3. 启用redo旁路：

   • 吞吐量损失减少到8.9%

4. 完整功能：

   • 最终性能差距仅2.1%
   • 压缩比保持高水平

5. 关键实现细节与优化

5.1 压缩内存管理优化

PolarCSD2.0的FTL映射表优化：

• 原设计：8字节/条目
• 新设计：7字节/条目
  • 物理偏移粒度从1字节变为16字节
  • 偏移和长度元数据从3字节压缩到2字节
• 效果：支持9.6TB逻辑容量，内存占用降低12.5%

5.2 I/O路径优化

1. 写路径：

   • 小redo日志绕过压缩
   • 大页面写入使用异步压缩
   • 批量提交减少I/O次数

2. 读路径：

   • 热页面保持解压状态缓存
   • 冷页面按需解压
   • 预取相邻压缩块

5.3 异常处理机制

1. 压缩失败降级处理：

   • 自动切换为无损模式
   • 记录异常事件供后续分析

2. 资源监控：

   • 实时跟踪CPU/内存使用
   • 动态调整压缩线程优先级
   • 过载时自动限流

6. 与传统方案的对比

与数据库内置压缩方案比较：

实际生产中的优势体现：

1. 用户计算资源零占用
2. 压缩对业务完全透明
3. 集群级资源利用率优化

7. 部署与运维实践

7.1 硬件配置建议

推荐部署配置：

• CPU：Xeon Platinum 2.9GHz+
• 内存：4GB/设备缓存
• 网络：100Gbps×2
• 设备数量：12/节点

7.2 监控指标

关键监控项：

1. 压缩效率：

   • 实时压缩比
   • 算法分布
   • 重压缩频率

2. 性能指标：

   • 压缩/解压延迟
   • I/O排队时间
   • 缓存命中率

3. 资源使用：

   • CSD内存水位
   • PCIe带宽
   • CPU利用率

7.3 常见问题处理

1. 压缩比下降：

   • 检查数据模式变化
   • 评估算法选择效果
   • 考虑手动重压缩

2. 延迟增加：

   • 检查CSD健康状态
   • 监控后台任务影响
   • 调整QoS参数

3. 空间回收延迟：

   • 验证TRIM操作状态
   • 检查垃圾回收进度
   • 评估碎片化程度

8. 技术演进方向

未来优化方向：

1. 表级字典压缩：

   • 利用表结构信息
   • 共享字典减少元数据

2. 智能数据布局：

   • 按列聚类存储
   • 优化局部性

3. 硬件加速：

   • 专用指令集利用
   • FPGA加速关键路径

4. 冷热分离：

   • 自动分层存储
   • 冷数据归档优化

在实际部署中，我们发现压缩配置需要根据工作负载特征动态调整。例如，对于频繁更新的表，适当降低压缩强度反而能获得更好的整体性能。这需要持续监控和智能调参系统的配合。