时序数据库连载系列: 时序数据库一哥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:

  指标对象，也即一个数据源对象。每一个measurement能够拥有一个或多个指标值，也即下文所述的**field**。在实际运用中，能够把一个现实中被检测的对象（如：“cpu”）定义为一个measurement复制代码

• tags:

  概念等同于大多数时序数据库中的tags, 一般经过tags能够惟一标示数据源。每一个tag的key和value必须都是字符串。复制代码

• field:

  数据源记录的具体指标值。每一种指标被称做一个“field”，指标值就是 “field”对应的“value”复制代码

• timestamp:

  数据的时间戳。在InfluxDB中，理论上时间戳能够精确到 **纳秒**（ns）级别
  复制代码

此外，在InfluxDB中，measurement的概念之上还有一个对标传统DBMS的 Database 的概念，逻辑上每一个Database下面能够有多个measurement。在单机版的InfluxDB实现中，每一个Database实际对应了一个文件系统的 目录。

2.1 Serieskey的概念

InfluxDB中的SeriesKey的概念就是一般在时序数据库领域被称为 时间线 的概念, 一个SeriesKey在内存中的表示即为下述字符串(逗号和空格被转义)的 字节数组(github.com/influxdata/influxdb/model#MakeKey())

{measurement名}{tagK1}={tagV1},{tagK2}={tagV2},...

其中，SeriesKey的长度不能超过 65535 字节

2.2 支持的Field类型

InfluxDB的Field值支持如下数据类型:

Datatype	Size in Mem	Value Range
Float	8 bytes	1.797693134862315708145274237317043567981e+308 ~ 4.940656458412465441765687928682213723651e-324
Integer	8 bytes	-9223372036854775808 ～ 9223372036854775807
String	0～64KB	String with length less than 64KB
Boolean	1 byte	true 或 false

在InfluxDB中，Field的数据类型在如下范围内必须保持不变，不然写数据时会报错 类型冲突。

同一Serieskey + 同一field + 同一shard

2.3 Shard的概念

在InfluxDB中， 能且只能 对一个Database指定一个 Retention Policy (简称:RP)。经过RP能够对指定的Database中保存的时序数据的留存时间(duration)进行设置。而 Shard 的概念就是由duration衍生而来。一旦一个Database的duration肯定后, 那么在该Database的时序数据将会在这个duration范围内进一步按时间进行分片从而时数据分红以一个一个的shard为单位进行保存。

shard分片的时间 与 duration之间的关系以下

Duration of RP	Shard Duration
< 2 Hours	1 Hour
>= 2 Hours 且 <= 6 Months	1 Day
> 6 Months	7 Days

新建的Database在未显式指定RC的状况下，默认的RC为 数据的Duration为永久，Shard分片时间为7天

注: 在闭源的集群版Influxdb中，用户能够经过RC规则指定数据在基于时间分片的基础上再按SeriesKey为单位进行进一步分片

3. InfluxDB的存储引擎分析

时序数据库的存储引擎主要需知足如下三个主要场景的性能需求

1. 大批量的时序数据写入的高性能
2. 直接根据时间线(即Influxdb中的 Serieskey )在指定时间戳范围内扫描数据的高性能
3. 间接经过measurement和部分tag查询指定时间戳范围内全部知足条件的时序数据的高性能

InfluxDB在结合了1.2所述考量的基础上推出了他们的解决方案，即下面要介绍的 WAL + TSMFile + TSIFile的方案

3.1 WAL解析

InfluxDB写入时序数据时为了确保数据完整性和可用性，与大部分数据库产品同样，都是会先写WAL,再写入缓存，最后刷盘。对于InfluxDB而言，写入时序数据的主要流程如同下图所示：

图 2

InfluxDB对于时间线数据和时序数据自己分开，分别写入不一样的WAL中，其结构以下所示：

索引数据的WAL

因为InfluxDB支持对Measurement，TagKey，TagValue的删除操做，固然随着时序数据的不断写入，天然也包括 增长新的时间线，所以索引数据的WAL会区分当前所作的操做具体是什么，它的WAL的结构以下图所示

图 3

时序数据的WAL

因为InfluxDB对于时序数据的写操做永远只有单纯写入，所以它的Entry不须要区分操做种类，直接记录写入的数据便可

图 4

3.2 TSMFile解析

TSMFile是InfluxDB对于时序数据的存储方案。在文件系统层面，每个TSMFile对应了一个 Shard。

TSMFile的存储结构以下图所示:

图 5

其特色是在一个TSMFile中将 时序数据（i.e Timestamp + Field value）保存在数据区；将Serieskey 和 Field Name的信息保存在索引区，经过一个基于 Serieskey + Fieldkey构建的形似B+tree的文件内索引快速定位时序数据所在的 数据块

注： 在当前版本中，单个TSMFile的最大长度为2GB，超过期即便是同一个Shard，也会继续新开一个TSMFile保存数据。本文的介绍出于简单化考虑，如下内容不考虑同一个Shard的TSMFile分裂的场景

• 索引块的构成

  上文的索引块的构成，以下所示：
  
  *图 6*复制代码

  

其中 **索引条目** 在InfluxDB的源码中被称为`directIndex`。在TSMFile中，索引块是按照 Serieskey + Fieldkey **排序** 后组织在一块儿的。

明白了TSMFile的索引区的构成，就能够很天然地理解InfluxDB如何高性能地在TSMFile扫描时序数据了：

1. 根据用户指定的时间线（Serieskey）以及Field名 在 **索引区** 利用二分查找找到指定的Serieskey+FieldKey所处的 **索引数据块**
2. 根据用户指定的时间戳范围在 **索引数据块** 中查找数据落在哪一个（*或哪几个*）**索引条目**
3. 将找到的 **索引条目** 对应的 **时序数据块** 加载到内存中进行进一步的Scan

*注：上述的1，2，3只是简单化地介绍了查询机制，实际的实现中还有相似扫描的时间范围跨索引块等一系列复杂场景*

<br>
复制代码

• 时序数据的存储

  在图 2中介绍了时序数据块的结构：即同一个 Serieskey + Fieldkey 的 全部时间戳 - Field值对被拆分开，分红两个区：Timestamps区和Value区分别进行存储。它的目的是：实际存储时能够分别对时间戳和Field值按不一样的压缩算法进行存储以减小时序数据块的大小

  采用的压缩算法以下所示：

  • Timestamp： Delta-of-delta encoding

  • Field Value：因为单个数据块的Field Value必然数据类型相同，所以能够集中按数据类型采用不一样的压缩算法

    • Float类: Gorrila's Float Commpression
    • Integer类型: Delta Encoding + Zigzag Conversion + RLE / Simple8b / None
    • String类型: Snappy Compression
    • Boolean类型: Bit packing

  作查询时，当利用TSMFile的索引找到文件中的时序数据块时，将数据块载入内存并对Timestamp以及Field Value进行解压缩后以便继续后续的查询操做。

3.3 TSIFile解析

有了TSMFile，第3章开头所说的三个主要场景中的场景1和场景2均可以获得很好的解决。可是若是查询时用户并无按预期按照Serieskey来指定查询条件，而是指定了更加复杂的条件，该如何确保它的查询性能？一般状况下，这个问题的解决方案是依赖倒排索引(Inverted Index)。

InfluxDB的倒排索引依赖于下述两个数据结构

• map<SeriesID, SeriesKey>
• map<tagkey, map<tagvalue, List<SeriesID>>>

它们在内存中展示以下：

图 7

图 8

可是在实际生产环境中，因为用户的时间线规模会变得很大，所以会形成倒排索引使用的内存过多，因此后来InfluxDB又引入了 TSIFile

TSIFile的总体存储机制与TSMFile类似，也是以 Shard 为单位生成一个TSIFile。具体的存储格式就在此不赘述了。

4. 总结

以上就是对InfluxDB的存储机制的粗浅解析，因为目前所见的只有单机版的InfluxDB，因此尚不知道集群版的InfluxDB在存储方面有哪些不一样。可是，即使是这单机版的存储机制，也对咱们设计时序数据库有着重要的参考意义。

原文连接:yq.aliyun.com/articles/69…

#阿里云开年Hi购季#幸运抽好礼！点此抽奖：https://www.aliyun.com/acts/product-section-2019/yq-lottery?utm_content=g_1000042901