HoraedB 项目中的清单文件格式优化实践

背景介绍

在时序数据库HoraedB中，清单(manifest)文件用于存储SST文件的元数据信息。当前版本使用Protocol Buffers(protobuf)作为清单文件的序列化格式，但在实际使用中发现了一些性能问题。

现有问题分析

protobuf格式虽然具有良好的模式演化能力，但在HoraedB的特定场景下存在以下不足：

1. 空间效率低：对于包含大量SST文件元数据的列表，protobuf会为每个结构体重复序列化元信息，造成存储空间浪费。

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

优化方案设计

经过社区讨论，决定采用自定义二进制格式来优化清单文件的存储效率。新设计的格式具有以下特点：

文件整体结构

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

• 魔数：用于验证数据源的合法性
• 版本号：支持未来的模式演化
• 标志位：保留用于扩展功能，如压缩支持
• 记录总长度：用于完整性校验

记录结构

每条记录采用固定长度的自描述格式：

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

这种设计使得每条记录的元数据仅占用28字节，相比protobuf格式显著减少了存储空间。

实现细节

合并流程优化

新的清单文件合并流程简化为：

1. 从对象存储下载现有清单文件
2. 将增量SST文件元数据转换为二进制记录
3. 直接追加到现有清单文件末尾
4. 更新文件头部的记录总长度字段
5. 上传回对象存储覆盖原文件

性能考虑

每条记录28字节的设计使得单个清单文件可以高效存储大量SST文件元数据。理论上，1GB的清单文件可以存储约3800万条SST文件记录。

版本兼容性处理

通过版本号字段支持未来的模式演化。当检测到版本升级时，系统可以自动将旧格式清单转换为新格式，确保向后兼容。

实际效果

基准测试表明，新格式在序列化100条增量SST记录到包含1000条记录的现有清单时，性能表现稳定，处理时间在微秒级别。

总结

HoraedB通过优化清单文件格式，显著提升了存储效率和更新性能。这种自定义二进制格式的设计不仅解决了protobuf在特定场景下的不足，还为未来的功能扩展预留了空间。这种优化对于需要处理海量时序数据的数据库系统尤为重要，能够有效降低存储开销和提高元数据管理效率。