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树方案* * 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的以下需求无法得到完美支持： 　　

　　

　　时间序列下采样后会删除大量数据=*级别DB的LSMTree删除代价太大*在单机环境下存储大量数据时， 不能占用太多文件句柄=*LevelDB随着时间的增加会产生大量的小文件*数据存储需要热备份=*LevelDB只能冷备份*大数据场景下的写吞吐量要跟上=* B树BoltDB的写吞吐量成为瓶颈*存储要有良好的压缩性能=*BoltDB不支持压缩*另外， 考虑到技术栈的一致性和部署的便捷性(面向容器的部署)，InfluxDB团队希望存储引擎像其TSDB引擎一样用GO编写，因此排除了潜在的RocksDB选项。 　　

　　

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

　　

　　2 InfluxDB的数据模型 　　

　　

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

　　

　　在InfluxDB中，时间序列数据支持多值模型，典型的时间点数据如下： 　　

　　

　　图1 　　

　　

　　 　　

　　

　　Measurement:指标对象，即数据源对象。每个测量可以有一个或多个指标值，即**字段* *如下所述。实际中，一个真实的被检测对象(如“cpu”)可以定义为measurementtags:概念，相当于大多数时间序列数据库中的标签。通常，数据源可以由标签唯一地标记。每个标记的键和值必须是字符串。Field:数据源记录的特定指标值。每个指示符称为一个“字段”，指示符值是“字段”对应的“值”timestamp:数据的时间戳。在InfluxDB中，理论上时间戳可以精确到* *纳秒**(ns)级别。另外，在InfluxDB中，在度量的概念之上，还有一个数据库标杆传统DBMS的概念。从逻辑上讲，每个数据库下可以有多个测量值。在单机版的InfluxDB实现中，每个数据库实际上对应一个文件系统目录。 　　

　　

　　2.1系列键的概念 　　

　　

　　InfluxDB中的SeriesKey概念在时序数据库领域通常被称为时间轴概念。SeriesKey在内存中的表示是以下字符串(逗号和空格被转义)的字节数组(github.com/influxdata/influxdb/model # make key()) 　　

　　

　　{测量名称} {标记1}={标记1 }，{标记2}={标记2 }， 　　

　　

　　SeriesKey的长度不能超过65535个字节。 　　

　　

　　2.2支持的字段类型 　　

　　

　　InfluxDB的字段值支持以下数据类型3360 　　

　　

　　 　　

　　

　　在InfluxDB中，字段的数据类型必须在以下范围内保持不变，否则写入数据时会报告错误类型冲突。 　　

　　

　　相同的序列号，相同的字段，相同的碎片 　　

　　

　　2.3分片的概念 　　

　　

　　在InfluxDB中，一个数据库只能指定一个保留策略(简称：RP)。RP允许您设置存储在指定数据库中的时间序列数据的持续时间。而Shard这个概念就是从duration衍生出来的。一旦数据库的持续时间被确定，数据库中的时间序列数据将在持续时间内。 　　

范围内进一步按时间进行分片从而时数据分成以一个一个的shard为单位进行保存。

　　

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

　　

　　

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

　　

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

　　

3. InfluxDB的存储引擎分析

　　

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

　　

大批量的时序数据写入的高性能直接根据时间线(即Influxdb中的 Serieskey )在指定时间戳范围内扫描数据的高性能间接通过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 encodingField Value：由于单个数据块的Field Value必然数据类型相同，因此可以集中按数据类型采用不同的压缩算法Float类: Gorrila's Float CommpressionInteger类型: Delta Encoding Zigzag Conversion RLE / Simple8b / NoneString类型: Snappy CompressionBoolean类型: 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在存储方面有哪些不同。但是，即便是这单机版的存储机制，也对我们设计时序数据库有着重要的参考意义。

以上就是帮企客小编为大家带来的全部内容，希望可以帮助到大家。