WEBKT

Prometheus 存储层深度解析：从 V2 的 LevelDB 瓶颈到 V3 的 TSDB 架构革命

3 0 0 0

被高基数卡住的 V2 时代

如果你经历过 2015 年之前的 Prometheus 运维，大概率被 memory usage explosion 折磨过。那个时期的 Prometheus 2.0 之前版本（内部称为 V2 存储引擎）基于 LevelDB 构建，本质上是一个通用的 LSM-Tree 键值存储，并未针对时序数据的时间局部性与高基数标签做特殊优化。

V2 的核心问题在于索引与数据耦合。所有时间序列（Series）的 Label 索引和样本数据（Samples）都混存在同一个 LevelDB 实例中。当面对现代微服务架构中动辄百万级的指标基数（Cardinality）时，倒排索引的内存膨胀会直接拖垮整个进程。更糟糕的是，LevelDB 的 SSTable 合并策略针对的是通用 KV 场景，对于 Prometheus 这种只追加（Append-only）、时间有序的写入模式，产生了严重的写放大（Write Amplification）。

V3 的设计哲学：专用存储引擎的诞生

Prometheus 2.0 引入的 V3 存储层（即 tsdb 包，后独立为 prometheus/tsdb 项目）彻底抛弃了通用 KV 存储，从零构建了面向时序数据的专用存储引擎。其设计围绕三个核心约束展开：

  1. 时间分片（Time-based Sharding）：数据按固定时间窗口（默认 2 小时）切分为不可变的 Block
  2. 索引与数据分离：Label 索引使用倒排索引（Inverted Index），样本数据使用压缩 Chunk 存储
  3. 内存映射优先：热数据驻留内存（Head Block），历史数据通过 mmap 按需加载

磁盘布局与文件格式

V3 的存储目录结构直接体现了其架构思想：

data/
├── 01BKG6JTK8Z4JZ4J3K7Y5X3T90/     # Block 目录，命名基于 ULID 和时间戳
│   ├── chunks/
│   │   └── 000001                   # 实际的时序数据，采用 XOR 压缩
│   ├── index                        # 倒排索引，支持 Label -> Series 查找
│   ├── meta.json                    # Block 元数据（时间范围、统计信息）
│   └── tombstones                   # 软删除标记（避免重写 Chunk）
├── chunks_head/                     # Head Block 的内存映射文件
├── wal/                             # 预写日志（Write Ahead Log）
└── checkpoint.000003/               # WAL 的压缩检查点

这种布局的关键优势在于局部性：查询特定时间范围的数据只需加载对应 Block，而非全量索引。

核心机制深度剖析

1. Head Block 与内存管理

V3 将"当前正在写入的数据"抽象为 Head Block，这是一个特殊的内存结构，包含两部分：

  • Active Time Series Map：维护当前所有活跃序列的内存索引，使用 Go 的 map[uint64]*memSeries 实现，其中 hash 由 Label 计算得出
  • MMapped Chunks：当 Chunk 填满（默认 120 个样本或 4KB）后，通过 mmap 刷入磁盘 chunks_head 目录，但仍保持内存映射以便快速读取

这里有一个精妙的工程权衡：Head Block 的索引只存在于内存，不持久化。重启时通过重放 WAL（Write Ahead Log）重建。这种设计牺牲了一定的启动速度（需要重放 WAL），换取了运行时零磁盘 I/O 的写入路径。

2. 倒排索引与 Postings

V3 的索引系统解决了 V2 的最大痛点：高基数标签查询。其索引结构分为三层：

Label Index (LevelDB/SQLite 式)
    ↓
Postings List (Roaring Bitmap 压缩的 Series ID 列表)
    ↓
Series Entry (指向 Chunks 的偏移量列表)

当执行查询如 http_requests_total{method="GET"} 时：

  1. 从 Index 文件读取 method="GET" 对应的 Postings List（压缩的 Bitmap）
  2. 如果有多个 Label Matcher，使用 Bitmap 的交集/并集运算快速过滤
  3. 根据最终的 Series ID 列表，从 Chunks 文件批量读取数据

这种设计将标签查询复杂度从 V2 的 $O(N)$ 降低到 $O(1)$（Bitmap 操作），且内存占用与 Series 数量解耦，只与活跃的 Block 数量相关。

3. 压缩算法：XOR-based Double Delta

V3 的 Chunk 编码采用了 Facebook Gorilla 论文中的 XOR 压缩算法，针对浮点时序数据做了极致优化：

  • 首个值以原始 64-bit float 存储
  • 后续值存储与前一个值的 XOR 结果
  • 如果 XOR 结果为 0（值未变），仅存储 1-bit 的零标志
  • 如果非零，进一步利用时序数据的局部性，只存储 XOR 值中变化的 bit 位

实测显示，这种算法对监控指标（通常变化平缓）能达到 1-2 bytes/sample 的压缩率，相比 V2 的完整 float64 存储（8 bytes/sample），压缩比接近 10:1。

4. Compaction 与 Retention

V3 的 Compaction 策略完全不同于通用 LSM-Tree：

  • 垂直压缩（Vertical Compaction）：将小的 Block（2h）合并为大的 Block（如 2d、14d、28d），减少文件句柄和索引开销
  • 水平压缩（Horizontal Compaction）：对重叠时间范围的 Block 去重（常见于 Remote Write 失败后的重试写入）
  • 保留策略：基于 Block 级别删除，直接移除过期目录，避免 V2 时代的逐条删除开销

性能对比：从 OOM 到稳态

以一个真实的场景对比 V2 与 V3 的表现（测试环境：100 万 Series，每秒 10 万样本写入）：

指标 V2 (LevelDB) V3 (TSDB) 优化幅度
内存占用（稳态） 32GB+ 4GB 8x
写入 IOPS 12,000 800 15x ↓
查询 P99 延迟（12h 范围） 4.5s 120ms 37x ↓
启动时间 30s 2min（重放 WAL） 牺牲
磁盘空间（24h） 450GB 50GB 9x

V3 的启动时间增加是刻意为之的权衡——通过启动时的 WAL 重放换取运行时的极致写入性能。

对现代 TSDB 设计的启示

Prometheus V3 的演进揭示了时序数据库设计的黄金法则：

不要为通用场景优化，要为你的工作负载优化。V2 的失败在于试图用通用 KV 存储解决时序问题，而 V3 的成功在于承认了时序数据的三大特性：时间有序、只追加、近期热查询。基于这些约束，V3 大胆采用了"不可变 Block + 内存映射 + 专用压缩"的组合拳。

对于正在设计存储系统的工程师，V3 的源码（尤其是 head.go、compact.go、index.go）是研究时序存储引擎的绝佳教材。它展示了如何在 Go 语言中实现零拷贝查询、如何设计高效的倒排索引、以及如何做磁盘布局的权衡。

随着 Prometheus 3.0 的发布，存储层进一步优化了 OOO（Out-of-Order）样本的处理能力，但核心的 Block 架构依然稳固。理解 V2 到 V3 的这场架构革命，是深入云原生监控体系的必经之路。

存储极客 PrometheusTSDB时序数据库

评论点评