Apache Horaedb 项目中 TimeMergeStorage 的合并操作设计思考

在 Apache Horaedb 这个分布式时序数据库项目中，TimeMergeStorage 作为其核心存储组件之一，面临着如何处理相同主键数据行合并的重要技术挑战。本文将深入探讨这一设计问题的背景、解决方案以及相关技术考量。

问题背景

TimeMergeStorage 组件当前采用 RecordBatch 作为数据处理单元，当遇到具有相同主键的多行数据时，系统需要决定如何合并这些数据行的值。初始设计仅支持"覆盖"模式，即选择序列号最大的行作为最终值。这种模式对于索引和序列数据可能适用，但对于实际时序数据则存在明显不足。

在实际应用场景中，我们经常需要将30分钟内的数据点聚合成单行数据，这就要求系统能够支持增量更新操作，而不仅仅是简单的值覆盖。

技术方案设计

针对这一问题，我们提出了一个基于更新模式的解决方案：

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

该方案的关键在于让 TimeMergeStorage 支持模式参数配置，使得在查询和压缩操作时能够采用不同的值选择策略。这种设计简单直接，能够满足大多数使用场景的需求。

设计考量与权衡

这一方案存在一个明显的局限性：同一个存储实例中的所有行必须采用相同的合并模式。根据项目设计文档，这种限制对于指标引擎中的表结构是可以接受的。

如果需要支持更细粒度的控制，我们可以借鉴 RocksDB 的实现方式，它通过以下机制实现了灵活的合并操作：

1. 在写入内存表时，每个条目都带有类型标记
2. 内部键格式包含用户键、序列号和操作类型
3. 查询时根据操作类型决定合并策略
4. 压缩过程中对相同键的多个版本进行智能合并

这种设计虽然更加灵活，但也带来了显著的实现复杂性。对于 Horaedb 的当前需求，简单的模式参数方案已经能够满足要求，同时保持了实现的简洁性。

总结

在时序数据库设计中，数据合并策略的选择直接影响着系统的功能和性能。Horaedb 项目通过引入可配置的合并模式，在功能需求和实现复杂度之间取得了良好的平衡。这种设计既满足了基本的数据处理需求，又为未来的扩展保留了可能性，体现了数据库系统设计中"简单有效"的工程哲学。