NanoTDB 存储引擎设计：Append-Only 时序数据库的 Golang 工程实践

在物联网与工业传感器场景中，数据库需要持续处理高吞吐的写入请求，同时支撑时间范围查询与聚合运算。这类工作负载与传统的 OLTP 数据库截然不同 —— 写入远高于读取、数据按时间单调增长、查询以时间区间为主、且历史数据通常有明确的保留周期（TTL）。NanoTDB 正是在这一背景下诞生的轻量级实现，它用 Go 语言实现了一个专为「资源受限硬件上的长期传感器数据」设计的 Append-Only 时序数据库。本文聚焦其存储引擎层面的工程取舍，探讨 WAL、MemTable、SSTable 与 Compaction 在 Golang 环境下的具体实现思路。

Append-Only 写入路径：WAL 先于一切

时序数据库的写入路径核心在于将随机 I/O 转换为顺序 I/O，同时保证崩溃恢复能力。NanoTDB 继承了成熟的日志结构化思路，采用了经典的 Write-Ahead Log（WAL）+ MemTable + SSTable 三层架构。

写入数据点时，第一步是将原始记录追加到 WAL 文件。这一步至关重要：即使后续 MemTable 刷盘失败，系统重启后只需回放 WAL 即可重建内存状态，确保不丢数据。在 Golang 中，WAL 实现通常依赖 os.OpenFile 的 O_APPEND | O_CREATE | O_WRONLY 模式保证追加写入的原子性；文件句柄在整个生命周期内保持打开，由独立的 goroutine 负责批量 flush，规避频繁的系统调用开销。

第二步，数据进入 MemTable。MemTable 是内存中的有序结构，按 (metric_id, timestamp) 复合键排序，维持 O (log n) 的写入复杂度。Go 标准库没有现成的跳表实现，但业界普遍采用 github.com/smallstep/assert/skiplist 或自行基于 container/list 实现轻量跳表，以获得比红黑树更简洁的迭代器语义和更天然的并发友好性（分段锁）。MemTable 设置容量阈值（如 64 MB）与时间阈值（如 30 秒），任一触发即触发刷盘。

关键参数（Go 场景下的经验值）：MemTable 大小上限 MaxMemTableSize 建议设为可用内存的 1/8 到 1/4；刷盘阈值 FlushInterval 若设为 30 秒，在传感器每 5 秒上报一次的情境下，单次刷盘约承载 6 条记录的数据量，平衡了延迟与 I/O 效率。

磁盘持久化：SSTable 的数据布局与索引设计

MemTable 刷盘后生成 SSTable（Sorted String Table），这是一组只读的、键值有序的文件集合。NanoTDB 的 SSTable 布局借鉴了 LevelDB 以来业界成熟的块结构设计：

┌──────────────┬──────────────┬──────────────┬──────────────┐
│   Data Block │   Data Block │      ...     │  Index Block │
│   (4-8 KB)   │   (4-8 KB)   │              │  (sparse)    │
└──────────────┴──────────────┴──────────────┴──────────────┘
                                            ↑
                                    Bloom Filter (可选)

Data Block 是最小 I/O 单位，建议 4–8 KB 以契合 Linux 页面大小和 SSD 的读写粒度。Block 内存储压缩后的 (timestamp, value) 记录序列，采用差分编码（delta-of-delta）进一步压缩时间戳，对浮点值使用 Gorilla 压缩或简单的 float64 二进制表示。

Index Block 存储稀疏索引：每个 Block 记录其首个 key 与文件偏移。查询时先通过二分定位目标 Block 的大致范围，再在 Block 内顺序扫描。稀疏索引使内存占用可控（假设每个 Block 8 KB、文件 256 MB，则索引项约 32K 条，远小于全量记录数）。

Bloom Filter 以 SSTable 为单位构建，对 (metric_id, timestamp) 空间计算若干哈希位。查询时先查 Bloom Filter，若命中则进入 Block 扫描，否则直接跳过该文件。典型的假阳性率 1% 设置 10 个哈希函数，内存占用约每条记录 10–12 bit，对于时序场景的高基数 metric 集合尤为关键。

读路径：多 SSTable 合并与时间区间查询

时序数据的典型查询是「过去 N 小时 / 天的 metric 值」或「某时间范围内的聚合」。在 LSM-Tree 结构下，同一 key 可能同时存在于 MemTable 和多个 SSTable 中，读路径必须合并所有层级的结果。

查询流程：接收 (metric_id, start, end) 参数后，首先在 MemTable 中二分查找时间范围内最早的记录（倒序遍历利用时序数据的单调性），随后通过全局时间索引定位到覆盖该时间窗口的所有 SSTable，逐一检查 Bloom Filter 以跳过不包含该 metric 的文件，对命中的 SSTable 读取其 Index Block 确定目标 Block 范围，最后在 Block 内完成区间扫描。

合并阶段需要处理同一 timestamp 的多条记录（若存在去重逻辑，则取最新值）。Go 的 channel 与 goroutine 天然适合并行读取多个 SSTable：将 SSTable 列表切分后启动 worker pool，每个 worker 负责读取若干文件的局部结果，最后在调用方归并排序输出。

性能调优经验：对于时间范围查询，若跨度超过 7 天，建议启用预聚合（downsampling）层 —— 例如将原始数据按 5 分钟窗口聚合为统计摘要（min/max/avg），查询时优先读取预聚合结果而非扫描全量原始记录。这一策略在 Prometheus 和 InfluxDB 中均有应用，可将大范围查询的延迟降低 10 倍以上。

Compaction：写放大与读放大的权衡

LSM-Tree 的固有代价是 Compaction—— 后台定期合并小 SSTable 为大 SSTable、去重 tombstone、回收空间。Compaction 直接影响写入吞吐（写放大）与读取性能（读放大），是存储引擎设计的核心调优点。

NanoTDB 面向「 modest hardware 」的定位，决定了它倾向于采用简单的 Compaction 策略而非复杂的 Leveled Compaction。最常见的轻量级实现是 Size-Tiered Compaction：每当存在 N 个小 SSTable（典型 N=4）时，触发合并生成一个包含全部数据的大 SSTable。这种策略写放大约 10x，读放大随 SSTable 层数增长，但对资源受限场景足够。

后台 Compaction 应运行在独立的 goroutine 中，通过 context.Context 与 select 实现优雅关闭。合并过程中需要临时文件写入，可借助 ioutil.TempFile 创建临时文件，写入完成后再原子重命名为目标文件名，避免崩溃导致文件损坏。合并完成后需更新全局 SSTable 索引（记录新增 SSTable 的时间范围与文件路径），并删除被合并的旧文件。

关键参数：Compaction 并发度建议设为 runtime.NumCPU() - 1，避免与读写路径争抢 CPU；合并批次大小 CompactionBatchSize 建议 10000 条记录，防止单次合并耗时过长导致写入阻塞。

与 Golang 并发模型的契合点

时序数据库的高吞吐量写入与后台 Compaction 天然适合 Go 的并发模型。关键设计点包括：

MemTable 刷盘采用双缓冲模式：写入始终进入活跃 MemTable，触发刷盘时将活跃指针原子切换到新 MemTable，由后台 goroutine 完成旧 MemTable 的序列化，避免写入路径加锁。

WAL 写入使用带缓冲的 channel（如 buffer size 10000），由专用的 WAL writer goroutine 从 channel 消费并批量刷盘，减少系统调用次数的同时避免阻塞写入方。

Compaction 任务通过 semaphore（信号量模式）控制并发数，避免多任务同时读取大量文件导致 I/O 饱和。

崩溃恢复时，回放 WAL 使用 bufio.Scanner 按行读取，通过 channel 将回放任务分发给多个 worker goroutine 并行解析，显著加速大文件的恢复过程。

工程实践建议：面向传感器数据的参数配置

若基于 NanoTDB 的设计构建生产级时序存储，以下参数配置经验可供参考：

写入路径：WAL buffer 建议 1 MB，刷盘间隔 100 ms，在单条记录 100–500 字节的场景下，100 ms 可聚集约 2000–10000 条记录，I/O 效率与恢复粒度兼顾。

存储结构：SSTable Block 大小 4 KB（适合小记录）、8 KB（适合大记录）按传感器数据量级选择；Bloom Filter 采用 10 个哈希函数、1% 假阳性率。

Compaction：启用后台 Compaction，间隔 5–10 分钟；保留至少 2 个完整 Compaction 代的 SSTable，防止查询在 Compaction 期间退化。

TTL 与数据淘汰：按时间分区目录结构（如 data/2026/05/15/），TTL 到达后直接删除目录而非逐文件清理，大幅降低元数据维护成本。

资料来源：NanoTDB 官方仓库（aymanhs/NanoTDB）及行业时序数据库存储引擎通用设计实践。

systems