zigzag指标应st天龙用,zigzag使用技巧

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/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在存储方面有哪些不同。可是，即便是这单机版的存储机制，也对咱们规划时序数据库有着重要的参阅含义。