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

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

Shard Group & Shard & tsm file的关系

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

Image

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

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

InfluxDB的打点数据流

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

Image

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

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

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

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

  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文件合成一个,注意此过程并不涉及数据的重新压缩,对应的配置文件中的参数为:

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

写入速度和压缩率的关系

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

欢迎讨论~