时序数据库连载系列: 时序数据库一哥InfluxDB之存储机制解析

InfluxDB 的存储机制解析

本文介绍了InfluxDB对于时序数据的存储/索引的设计。由于InfluxDB的集群版已在0.12版就不再开源，因此如无特殊说明，本文的介绍对象都是指 InfluxDB 单机版

1. InfluxDB 的存储引擎演进

尽管InfluxDB自发布以来历时三年多，其存储引擎的技术架构已经做过几次重大的改动, 以下将简要介绍一下InfluxDB的存储引擎演进的过程。

1.1 演进简史

• 版本0.9.0之前

  **基于 LevelDB的LSMTree方案**
  

• 版本0.9.0～0.9.4

  **基于BoltDB的mmap COW B+tree方案**
  

• 版本0.9.5～1.2

  **基于自研的 WAL + TSMFile 方案**（TSMFile方案是0.9.6版本正式启用，0.9.5只是提供了原型）
  

• 版本1.3～至今

  **基于自研的 WAL + TSMFile + TSIFile 方案**
  

1.2 演进的考量

InfluxDB的存储引擎先后尝试过包括LevelDB, BoltDB在内的多种方案。但是对于InfluxDB的下述诉求终不能完美地支持：

• 时序数据在降采样后会存在大批量的数据删除

  => *LevelDB的LSMTree删除代价过高*

• 单机环境存放大量数据时不能占用过多文件句柄

  => *LevelDB会随着时间增长产生大量小文件*

• 数据存储需要热备份

  => *LevelDB只能冷备*

• 大数据场景下写吞吐量要跟得上

  => *BoltDB的B+tree写操作吞吐量成瓶颈*

• 存储需具备良好的压缩性能

  => *BoltDB不支持压缩*
  

此外，出于技术栈的一致性以及部署的简易性考虑（面向容器部署），InfluxDB团队希望存储引擎 与 其上层的TSDB引擎一样都是用GO编写，因此潜在的RocksDB选项被排除

基于上述痛点，InfluxDB团队决定自己做一个存储引擎的实现。

2 InfluxDB的数据模型

在解析InfluxDB的存储引擎之前，先回顾一下InfluxDB中的数据模型。

在InfluxDB中，时序数据支持多值模型，它的一条典型的时间点数据如下所示：

图 1

• measurement:

  指标对象&#