CeresDB/Horaedb 存储引擎中的Compaction Offload技术解析

背景与挑战

在现代LSM-Tree存储引擎中，Compaction（压缩合并）是一个至关重要的后台操作。它负责将大量小尺寸的SSTable文件合并为更大、更有序的文件，从而保证查询效率并控制存储空间增长。然而在生产环境中，我们经常面临一个经典难题：Compaction操作会与前台查询/写入操作竞争系统资源（CPU、I/O带宽等）。

CeresDB/Horaedb项目在实际部署中就遇到了这样的困境：

1. Compaction速度跟不上SSTable文件生成速度，导致查询性能下降
2. 无法简单通过增加资源来解决，因为查询和写入操作的优先级更高
3. 在单一节点内难以平衡查询、写入和Compaction之间的资源分配

解决方案：Compaction Offload

针对这一挑战，项目团队提出了Compaction Offload（压缩卸载）的架构方案。其核心思想是将Compaction这一资源密集型操作从主存储节点卸载到专用的计算节点上执行，实现计算与存储的分离。

架构设计要点

1. 专用Compaction节点：

   • 实现远程Compaction服务
   • 独立部署，资源与主节点隔离
   • 可弹性扩展，应对不同负载需求

2. 主节点改造：

   • 重构Compaction流程，定义清晰的接口抽象
   • 实现远程Compactor，支持将实际压缩工作提交到专用节点
   • 保持本地Compaction能力作为fallback

3. 元数据管理：

   • Horaemeta组件负责管理Compaction节点集群
   • 提供节点发现和负载均衡能力
   • 支持动态调整Compaction资源分配

技术实现细节

接口抽象层

项目首先对Compaction流程进行了重构，定义了清晰的trait接口。这种抽象使得：

• 本地和远程Compaction可以共享相同的工作流程
• 便于未来扩展新的Compaction策略
• 测试时可以使用mock实现

远程通信机制

远程Compaction需要高效的数据传输协议，考虑因素包括：

• SSTable文件的传输效率
• 压缩任务的描述和状态跟踪
• 错误处理和重试机制

资源调度策略

Horaemeta需要实现智能的Compaction节点调度：

• 基于负载的节点选择
• 任务优先级管理
• 故障检测和自动恢复

优势与价值

1. 资源隔离：彻底解决Compaction与查询/写入的资源竞争问题
2. 弹性扩展：可根据业务需求独立扩展Compaction能力
3. 性能稳定：确保查询和写入延迟不受后台操作影响
4. 成本优化：专用节点可采用不同的硬件配置（如更高I/O性能）

未来展望

Compaction Offload架构为分布式存储系统提供了新的优化方向：

• 可考虑进一步细分Compaction类型（如小合并与大合并）
• 探索智能调度算法，动态调整Offload策略
• 结合新型硬件（如DPU）进一步提升效率

这一技术方案不仅解决了CeresDB/Horaedb的实际问题，也为其他LSM-Tree存储系统提供了有价值的参考。通过计算存储分离的思想，在保证性能的同时获得了更好的资源利用率和系统可扩展性。