Apache Horaedb 项目中的清单文件格式优化探讨

在 Apache Horaedb 这个高性能时序数据库项目中，清单(manifest)文件的设计对系统性能有着重要影响。本文将深入分析当前清单文件实现的问题，并探讨一种更高效的替代方案。

当前实现的问题

Horaedb 目前使用 Protocol Buffers(protobuf)格式来序列化清单文件。虽然 protobuf 提供了良好的模式演进能力，但在 Horaedb 的具体使用场景中存在两个主要问题：

1. 空间效率低下：对于包含大量小结构体的数组字段，protobuf 会为每个结构体重复序列化元数据，造成存储空间的浪费。

2. 增量更新困难：将整个清单体作为一个 protobuf 消息序列化，使得增量更新变得复杂，每次更新都需要重写整个文件。

优化方案设计

针对上述问题，项目团队提出了一种自定义的二进制格式方案：

基础结构设计

清单文件由版本号和一系列自描述记录组成：

| 版本号(u8) | 记录(N)... |

每条记录包含：

| ID(u64) | 时间范围(i64×2) | 大小(u32) |

这种设计具有以下优势：

• 每条记录都是自描述的，无需额外元数据
• 增量更新只需追加新记录到文件末尾
• 固定长度的字段布局提高了序列化/反序列化效率

扩展设计考虑

在实际讨论中，设计进一步优化为：

| 魔数(u32) | 版本号(u8) | 标志位(u8) | 长度(u64) | 记录(N)... |

每条记录扩展为：

| ID(u64) | 时间范围(i64×2) | 大小(u32) | 行数(u32) |

这些改进增加了：

• 魔数用于数据校验
• 标志位保留未来扩展能力
• 长度字段便于完整性检查
• 行数字段补充完整元数据信息

实现策略

清单合并流程从原来的：

1. 下载原始protobuf数据
2. 反序列化为结构体
3. 合并新数据
4. 重新序列化为protobuf
5. 上传新文件

优化为：

1. 下载原始二进制数据
2. 直接追加新记录二进制数据
3. 上传新文件

这种优化减少了序列化/反序列化开销，特别是在处理大量小文件时效率提升明显。

性能考量

基准测试显示，新格式在处理100个新增SST文件追加到包含1000条记录的清单时，性能表现稳定。理论上，新格式可以支持约3800万条SST元数据记录存储在1GB大小的清单文件中。

未来扩展性

通过版本号字段，新格式保留了良好的扩展能力：

• 可以添加新版本支持额外字段
• 启动时进行版本检查和处理数据迁移
• 标志位预留了压缩等特性支持

总结

Apache Horaedb 通过优化清单文件格式，解决了protobuf在特定场景下的效率问题。新的二进制格式不仅提高了存储效率，还简化了增量更新流程，为系统处理海量小文件提供了更好的支持。这种优化展示了在特定领域根据实际需求定制解决方案的重要性，而不是盲目依赖通用序列化方案。