InfluxDB如何平衡打点速度和压缩比

Posted on | Edited on | Comments:

在实际使用InfluxDB的过程中，发现一个有意思的现象，打点速度越快，同样多的数据点，落到磁盘上的文件就会越大，原因是什么呢？这篇文章就来探究一下打点速度和压缩比的规律。

Shard Group & Shard & tsm file的关系

我们知道InfluxDB底层的存储文件是tsm文件，关于tsm的详细格式可以参考这里，下面是shard gorup和shard的关系：



InfluxDB的数据是存放在Shard Group中的，每个shard group负责一个特定时间段的数据的存取；
而在开源的InfluxDB中，一个shard gorup只包含一个shard；

一个shard可以包含多个tsm文件


InfluxDB的打点数据流

首先要了解一下，InfluxDB的打点数据流是怎样的。



首先是检查数据点的格式是否合法，其次是检查原信息是否存在，在进行了必要的检查和原信息创建之后，数据点被解析，然后写入wal和cache，两者全部写入正确之后才会返回写入成功。

在写入cache之后，InfluxDB会定时检查是否需要将cache中的数据通过snapshot的方式写数据文件到磁盘，在判断是否需要写数据文件到磁盘上的时候，主要有两条规则

1
2
1. cache空间是否已经满了
2. 设定的写入时间是否超时

两个条件只要有一个满足，InfluxDB就开始将cache的数据写到磁盘，这两个参数可以在配置文件中进行配置

1
2
3
cache-max-memory-size = 1073741824
cache-snapshot-memory-size = 26214400
cache-snapshot-write-cold-duration = "1h"

cache-max-memory-size 必须大于 cache-snapshot-memory-size，后者越大，那么内存中的数据就越多， cache-snapshot-write-cold-duration越大，在开始写盘之前就需要等的越久。

当数据文件写到tsm文件之后，InfluxDB会对tsm进行compact，目的是将多个tsm文件合成一个，注意此过程并不涉及数据的重新压缩，对应的配置文件中的参数为：

1
compact-full-write-cold-duration = "4h"

写入速度和压缩率的关系

根据上述流程，数据在写入磁盘之前，需要在内存缓存，缓存有大小和刷新时间的限制；根据上一篇文章的讨论，数据的压缩率和时间戳是否有序有很大关系；缓存越大，那么数据就会在一个更大的范围内进行排序，从而达到比较好的压缩效果。
除了上述原因，通常越高的写入速度伴随着高并发，数据的时间戳的顺序具有更随机的特性，也会造成压缩率降低的效果。

欢迎讨论~