SlateDB项目中的LSM-Tree持久化清单设计解析

在分布式存储系统中，如何高效地维护和恢复数据库状态是一个关键问题。SlateDB作为一个基于LSM-Tree结构的存储引擎，其设计团队近期针对DbState的持久化问题进行了深入探讨，最终形成了一套创新的清单(Manifest)设计方案。

背景与挑战

SlateDB当前面临的核心问题是：当进程停止后，DbState会丢失。重启时需要能够继续使用已持久化到对象存储的SST文件。DbState包含几个关键组件：

• 活跃的内存表(mem_table)
• 不可变内存表(imm_memtables)
• L0层的SST文件信息列表
• 下一个SST文件ID

初始解决方案是通过扫描对象存储中的所有SST文件来重建DbState，但这存在明显缺陷：随着数据量增长，扫描成本会变得不可接受；且在并发写入和压缩场景下难以保证一致性。

设计演进

设计团队经历了两个阶段的思考：

1. 初级阶段：简单扫描方案

   • 启动时扫描所有SST文件头信息
   • 通过最大SST ID推断next_sst_id
   • 优点：实现简单快速
   • 缺点：无法应对压缩场景，性能随数据量线性下降

2. 成熟方案：清单日志系统

   • 受Delta Lake设计启发
   • 采用日志序列+检查点机制
   • 定义改变DbState的操作类型(AddSST/RemoveSST)
   • 顺序日志文件(00000.log, 00001.log等)
   • 定期合并日志到检查点文件
   • 写入协调机制防止僵尸进程

关键技术考量

1. 性能优化：

   • 避免每次flush都更新清单
   • 清单更新频率独立于flush频率
   • 压缩操作产生新的清单版本

2. 一致性保证：

   • 清单作为唯一真实来源
   • 先写新SST，再更新清单，最后删除旧SST
   • 后台清理机制

3. 扩展性设计：

   • 支持快照和克隆功能
   • 引用计数管理SST文件生命周期
   • 灵活的存储后端支持

实现细节

清单系统的核心操作流程：

写入路径：

1. 执行压缩操作，写入新SST文件
2. 发布包含新SST信息的清单
3. 后台异步删除旧SST文件

读取路径：

1. 加载最新检查点文件
2. 应用检查点后的增量日志
3. 重建完整DbState

未来方向

当前设计为MVP版本，后续可能演进：

• 清单嵌入SST文件的混合方案
• 多级清单结构优化大规模场景
• 分布式锁服务集成
• 快照管理增强

SlateDB的清单设计展示了如何平衡简单性与功能性，为LSM-Tree在对象存储上的高效实现提供了有价值的参考。这种设计不仅解决了状态恢复问题，还为后续功能扩展奠定了坚实基础。