InfluxDB 系统架构

参考:时序数据库技术体系 – 初识InfluxDB

简单的理解:

Database

InfluxDB 中有着和传统数据库一样的 Database 的概念

Retention Policy(RP)

数据保留策略。核心作用有 3 个:

指定数据的过期时间,指定数据副本数量以及指定 ShardGroup Duration. RP 创建语句如下:

1
CREATE RETENTION POLICY ON <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> [SHARD DURATION <duration> ] [DEFAULT]

其中retention_policy_name表示RP的名称,database_name表示数据库名称,duration表示TTL,n表示数据副本数。

1
CREATE RETENTION POLICY "one_day_only" ON "water_database" DURATION 1d REPLICATION 1 SHARD DURATION 1h DEFAULT 

InfluxDB中Retention Policy有这么几个性质和用法:

  1. RP是数据库级别而不是表级别的属性。这和很多数据库都不同。

  2. 每个数据库可以有多个数据保留策略,但只能有一个默认策略。

  3. 不同表可以根据保留策略规划在写入数据的时候指定RP进行写入,下面语句就指定six_mouth_rollup的rp进行写入:

1
curl -X POST 'http://localhost:8086/write?db=mydb&rp=six_month_rollup' --data-binary 'disk_free,hostname=server01 value=442221834240i 1435362189575692182'

如果没有指定任何RP,则使用默认的RP。

Shard Group

Shard Group是InfluxDB中一个重要的逻辑概念,从字面意思来看Shard Group会包含多个Shard,每个Shard Group只存储指定时间段的数据,不同Shard Group对应的时间段不会重合。比如2017年9月份的数据落在Shard Group0上,2017年10月份的数据落在Shard Group1上。

每个Shard Group对应多长时间是通过Retention Policy中字段”SHARD DURATION”指定的,如果没有指定,也可以通过Retention Duration(数据过期时间)计算出来,两者的对应关系为:

Retention Policy’s Duration Shard Group Duration
< 2 days 1 h
>= 2 days and <= 6 mouths 1 day
> 6 mouths 7 days

问题来了,为什么需要将数据按照时间分成一个一个Shard Group?有两个原因:

  1. 将数据按照时间分割成小的粒度会使得数据过期实现非常简单,InfluxDB中数据过期删除的执行粒度就是Shard Group,系统会对每一个Shard Group判断是否过期,而不是一条一条记录判断。

  2. 实现了将数据按照时间分区的特性。将时序数据按照时间分区是时序数据库一个非常重要的特性,基本上所有时序数据查询操作都会带有时间的过滤条件,比如查询最近一小时或最近一天,数据分区可以有效根据时间维度选择部分目标分区,淘汰部分分区。

Shard

Shard 在 InfluxDB 中是一个比较重要的概念,它和 Retention Policy(数据保留策略) 相关联。

每一个存储策略下会存在许多shard,每一个shard存储一个指定时间段内的数据,并且不重复

每一个 shard 都对应一个底层的 tsm 存储引擎,有独立的 cache、wal、tsm file

Shard Group实现了数据分区,但是Shard Group只是一个逻辑概念,在它里面包含了大量Shard,Shard才是InfluxDB中真正存储数据以及提供读写服务的概念,类似于HBase中Region,Kudu中Tablet的概念。关于Shard,需要弄清楚两个方面:

  1. Shard是InfluxDB的存储引擎实现,具体称之为TSM(Time Sort Merge Tree) Engine,负责数据的编码存储、读写服务等。TSM类似于LSM,因此Shard和HBase Region一样包含Cache、WAL以及Data File等各个组件,也会有flush、compaction等这类数据操作。

  1. Shard Group对数据按时间进行了分区,那落在一个Shard Group中的数据又是如何映射到哪个Shard上呢?

InfluxDB采用了Hash分区的方法将落到同一个Shard Group中的数据再次进行了一次分区。这里特别需要注意的是,InfluxDB是根据hash(Series)将时序数据映射到不同的Shard,而不是根据Measurement进行hash映射,这样会使得相同Series的数据肯定会存在同一个Shard中,但这样的映射策略会使得一个Shard中包含多个Measurement的数据,不像 HBas e中一个Region的数据肯定都属于同一张表。

TSM存储引擎

部分组成:cache、wal、tsm file、compactor。(与HBase的LSM模型类似)

数据写入的过程

说明

  1. Cache

cache相当于是LSM Tree中的memtabl。

插入数据时,实际上是同时往cache与wal中写入数据,可以认为cache是wal文件中的数据在内存中的缓存。

当InfluxDB启动时,会遍历所有的wal文件,重新构造cache,这样即使系统出现故障,也不会导致数据的丢失。

cache中的数据并不是无限增长的,有一个maxSize参数用于控制当cache中的数据占用多少内存后就会将数据写入tsm文件。

每当cache中的数据达到阀值后,会将当前的cache进行一次快照,之后清空当前cache中的内容,再创建一个新的wal文件用于写入,

剩下的wal文件最后会被删除,快照中的数据会经过排序写入一个新的tsm文件中。

如果不配置的话,默认上限为25MB。

  1. WAL

wal文件的内容与内存中的cache相同,其作用就是为了持久化数据,当系统崩溃后可以通过wal文件恢复还没有写入到tsm文件中的数据。

  1. TSM File

单个tsm file大小最大为2GB,用于存放数据。

  1. Compactor

compactor组件在后台持续运行,每隔1秒会检查一次是否有需要压缩合并的数据。

主要进行两种操作,一种是cache中的数据大小达到阀值后,进行快照,之后转存到一个新的tsm文件中。

另外一种就是合并当前的tsm文件,将多个小的tsm文件合并成一个,使每一个文件尽量达到单个文件的最大大小,减少文件的数量,并且一些数据的删除操作也是在这个时候完成。

InfluxDB Sharding策略

上文已经对InfluxDB的Sharding策略进行了介绍,这里简单地做下总结。我们知道通常分布式数据库一般有两种Sharding策略:Range Sharding和Hash Sharding,前者对于基于主键的范围扫描比较高效,HBase以及TiDB都采用的这种Sharding策略;后者对于离散大规模写入以及随即读取相对比较友好,通常最简单的Hash策略是采用取模法,但取模法有个很大的弊病就是取模基础需要固定,一旦变化就需要数据重分布,当然可以采用更加复杂的一致性Hash策略来缓解数据重分布影响。

InfluxDB的Sharding策略是典型的两层Sharding,上层使用Range Sharding,下层使用Hash Sharding。对于时序数据库来说,基于时间的Range Sharding是最合理的考虑,但如果仅仅使用Time Range Sharding,会存在一个很严重的问题,即写入会存在热点,基于Time Range Sharding的时序数据库写入必然会落到最新的Shard上,其他老Shard不会接收写入请求。对写入性能要求很高的时序数据库来说,热点写入肯定不是最优的方案。解决这个问题最自然的思路就是再使用Hash进行一次分区,我们知道基于Key的Hash分区方案可以通过散列很好地解决热点写入的问题,但同时会引入两个新问题:

  1. 导致Key Range Scan性能比较差。InfluxDB很优雅的解决了这个问题,上文笔者提到时序数据库基本上所有查询都是基于Series(数据源)来完成的,因此只要Hash分区是按照Series进行Hash就可以将相同Series的时序数据放在一起,这样Range Scan性能就可以得到保证。事实上InfluxDB正是这样实现的。

  2. Hash分区的个数必须固定,如果要改变Hash分区数会导致大量数据重分布。除非使用一致性Hash算法。笔者看到InfluxDB源码中Hash分区的个数固定是1,对此还不是很理解,如果哪位看官对此比较熟悉可以指导一二。