CeresDB/horaedb 项目中 TimeMergeStorage 的合并操作支持分析

在分布式时序数据库 CeresDB/horaedb 的 metric_engine 模块中，TimeMergeStorage 是一个关键的数据存储组件。该组件当前仅支持简单的覆盖写入模式，这在处理时序数据时存在明显局限性。本文将深入分析现有实现的问题，并提出改进方案。

当前实现的问题

TimeMergeStorage 目前采用 RecordBatch 作为数据格式，对于具有相同主键的多行数据，仅支持"覆盖"模式，即选择序列号最大的行作为最终值。这种设计存在两个主要问题：

1. 对于索引/序列数据，覆盖模式是合理的，但对于实际指标数据则不够理想
2. 在常见使用场景中，我们需要将30分钟内的数据点聚合成一行，这就要求支持增量更新而非简单覆盖

改进方案设计

我们建议为 TimeMergeStorage 引入更新模式参数，定义如下枚举：

enum UpdateMode {
    Overwrite,  // 覆盖模式，保留最新值
    Append,     // 追加模式，支持增量更新
}

在查询和压缩过程中，根据不同的模式采用不同的值选择策略。查询时需要按照模式决定如何合并相同主键的值，压缩时也需要相应处理。

设计考量

这个方案有一个明显的限制：同一个存储实例中的所有行必须使用相同的更新模式。不过根据项目设计文档中的表结构设计，这个限制是可以接受的。

如果需要更细粒度的控制，可以参考 RocksDB 的实现方式，它为每个键值对单独标记操作类型（Put/Merge/Delete等），并在查询和压缩时根据类型执行不同的合并逻辑。这种设计虽然更灵活，但也显著增加了实现复杂度。

实现建议

对于当前需求，建议先实现简单的模式参数方案，理由如下：

1. 满足现有使用场景需求
2. 实现复杂度可控
3. 与项目当前的表结构设计相匹配

未来如果需要更灵活的控制，可以借鉴 RocksDB 的设计思路，为每个数据条目添加操作类型标记，并实现更复杂的合并逻辑。这种方案虽然强大，但需要考虑性能影响和实现成本。

总结

TimeMergeStorage 的合并操作支持是 metric_engine 的一个重要功能点。当前简单的覆盖模式不能满足所有使用场景，通过引入更新模式参数可以在保持简单性的同时解决主要问题。更复杂的方案可以作为未来的扩展方向。