时序数据库InfluxDB—介绍与性能测试

一、简述

二、主要特点

三、基本概念

1、主要概念

2、保留策略

3、连续查询

4、存储引擎—TSM Tree

5、存储目录

四、基本操作

1、Java-API操作

五、项目中的应用

六、单节点的硬件配置

七、性能测试

1、测试环境

2、测试程序

3、写入测试

4、查询测试

一、简述

时间序列数据：从定义上来说，就是一串按时间维度索引的数据。

时序数据库（TSDB）特点：

持续高并发写入、无更新、无删除；
数据压缩存储；
低查询延时。

常见的TSDB有：influxdb、IoTDB、opentsdb、timescaleDB，根据DB-engine排名，目前在time series数据库领域排名第一位。

二、主要特点

主要特点：

对时序数据(sereis data)使用TSM存储引擎，提供高性能的数据写入和压缩功能；
go语言编写，程序只有一个二进制的可执行文件，没有其他依赖关系；
插件支持telegraf采集、granfa可视化；
提供类似SQL语法格式的数据操作；
无结构（无模式）：可以是任意数量的列
支持与时间有关的相关函数（如最大，最小，求和等）；
保留策略(retention policies)功能可以定期清除老旧数据；
连续查询(continuous queries) 功能统计聚合数据来使数据查询更有效率。

缺点：

社区版只支持单机部署，集群功能需要使用收费的企业版。

三、基本概念

1、主要概念

database：数据库名，可以创建多个数据库，不同数据库中的数据文件是隔离存放的，存放在磁盘上的不同目录。
measurement：测量指标名，相当于数据库中的表。
point：相当于传统数据库里的一行数据，由时间戳（time）、数据（field）、标签（tags）组成。
tag：标签，相当于传统数据库的索引，表名+tag一起作为数据库的索引。
field：各种记录值（没有索引的属性）。
time：每条数据记录时间，是数据库中的主索引(会自动生成)。
series：相当于是 InfluxDB 中一些数据的集合，在同一个 database 中，retention policy、measurement、tag sets 完全相同的数据同属于一个 series，同一个 series 的数据在物理上会按照时间顺序排列存储在一起。

2、保留策略

retention policy：保留策略，用于设置数据保留的时间，每个数据库刚开始会自动创建一个默认的存储策略 autogen，数据保留时间为永久，之后用户可以自己设置，例如保留最近2小时的数据。InfluxDB 会定期清除过期的数据。
shard：分区，是InfluxDB存储引擎的实现，负责数据的编码存储、读写服务等。将InfluxDB中时间序列化的数据按照时间的先后顺序存入到shard中，每个shard中都负责InfluxDB中一部分的数据存储工作，并以tsm文件的表现形式存储在物理磁盘上，每个存放了数据的shard都属于一个shard group。
shard group ：可以理解为存放shard的容器，所有的shard在逻辑上都属于这个shard group，每个shard group中的shard都有一个对应的时间跨度和过期时间，每一个shard group都有一个默认的时间跨度，叫做shard group duration，默认为7天。

保留策略、shard、shardGroup三者关系

在一个RP中，如果指定的保留时间为24小时，那么每个shard的duration为1小时，即每个shard的时间跨度为1小时，那么总共会有24个跨度为1小时的shard，在触发数据的RP后，删除最早时间跨度的shard。

例如，我们在mydb数据库中指定保留策略为24小时。

那么此时shard group中对应就会存在24个shard，每次到达过期时间时，删除最早的shard，并生成一个新的shard。

3、连续查询

InfluxDB的连续查询是在数据库中自动定时启动的一组语句，语句中必须包含 SELECT 关键词和 GROUP BY time() 关键词。

InfluxDB会将查询结果放在指定的数据表中。

目的：使用连续查询是最优的降低采样率的方式，连续查询和存储策略搭配使用将会大大降低InfluxDB的系统占用量。而且使用连续查询后，数据会存放到指定的数据表中，这样就为以后统计不同精度的数据提供了方便。

4、存储引擎—TSM Tree

TSM Tree 是 InfluxDB 根据实际需求在 LSM Tree 的基础上稍作修改优化而来。
LSM-tree（日志结构的合并树）是一种基于硬盘的数据结构，核心思想就是放弃部分读能力，换取写入的最大化能力。
TSM 存储引擎主要由几个部分组成： cache、wal、tsm file、compactor。

Cache：插入数据时，实际上是同时往 cache 与 wal 中写入数据，可以认为 cache 是 wal 文件中的数据在内存中的缓存。当 InfluxDB 启动时，会遍历所有的 wal 文件，重新构造 cache，这样即使系统出现故障，也不会导致数据的丢失。
WAL：wal 文件的内容与内存中的 cache 相同，其作用就是为了持久化数据，当系统崩溃后可以通过 wal 文件恢复还没有写入到 tsm 文件中的数据。
TSM File：单个 tsm file 大小最大为 2GB，用于存放数据。
Compactor：compactor 组件在后台持续运行，每隔 1 秒会检查一次是否有需要压缩合并的数据。

主要进行两种操作
一种是 cache 中的数据大小达到阀值后，进行快照，之后转存到一个新的 tsm 文件中。
另外一种就是合并当前的 tsm 文件，将多个小的 tsm 文件合并成一个，使每一个文件尽量达到单个文件的最大大小，减少文件的数量，并且一些数据的删除操作也是在这个时候完成。

5、存储目录

influxdb的数据存储有三个目录，分别是meta、wal、data。

meta 用于存储数据库的一些元数据，meta 目录下有一个 meta.db 文件。

wal 目录存放预写日志文件，以 .wal 结尾。

data 目录存放实际存储的数据文件，以 .tsm 结尾。

四、基本操作

客户端命令行
HTTP API 接口
各语言API 库（对 go 语言 API 封装）
基于 WEB 管理页面操作，从1.3版开始InfluxDB官方就把web界面给取消

1、Java-API操作

1.1、引入java插件，influxdb-java

1.2、执行写入，写入的同时会创建measurement，无结构，可写入任意数量的列

1.3、Sql方式执行查询

1.4、开启批量写入

通过设置定时定量大小实现批量写入

五、项目中的应用

1、自动生成主索引字段time，索引字段ID，非索引字段Value

2、ID为车辆主键，Value为十六进制转换的JT809协议，减少空间存储

3、数据保留时间：500天，7天一个分区文件

4、3万辆车，截止目前有450G左右的数据

5、一天的数据量有2500万左右

六、单节点的硬件配置

这里定义的InfluxDB的负载是基于每秒的写入的数据量、每秒查询的次数以及唯一series的数目。

什么时候需要更多的内存？

一般来讲，内存越多，查询的速度越快，增加更多的内存总没有坏处。
影响内存的最主要的因素是series基数，series的基数大约或是超过千万时，就算有更多的内存也可能导致OOM，所以在设计数据的格式的时候需要考虑到这一点。
内存的增长和series的基数存在一个指数级的关系。

需要哪种类型的磁盘？

InfuxDB被设计运行在SSD上，InfluxData团队不会在HDD和网络存储上测试InfuxDB,所以不太建议在生产上这么去使用。在机械磁盘上性能会下降一个数量级甚至在中等负载下系统都可能死掉。为了最好的结果，InfuxDB至少需要磁盘提供1000IOPS的性能。

七、性能测试

1、测试环境

2、测试程序

从github上找的influxdata公司提供的两款测试工具

influx-stress 用于写入测试
influxdb-comparisons 用于查询测试

3、写入测试

测试工具：influx-stress

测试原理：

该工具是通过go语言的fasthttp库编写的。

1、会在服务器上创建一个数据库stress

2、然后创建一个MEASUREMENT(类似关系数据库的表)名为ctr，该表有time,n,some三个字段。

3、不断的向stress数据库的ctr表插入数据，每次插入的数据都包含三个字段。每一条数据称为一个points。插入数据的方法是通过influxDB的HTTP API发送请求(POST /write?db=stress)。

测试结论：最大吞吐量为每秒写入60万条数据

4、查询测试

测试工具：influxdb-comparisons

测试原理：

该工具是通过go语言的fasthttp库编写的。
1、会在服务器上创建一个数据库benchmark_db
2、然后创建9个MEASUREMENT:cpu,disk,diskio,kernel,mem,net,nginx,postgresl。每个measurement有2160行数据。
3、通过http GET请求"GET/query?db=benchmark_db"查询cpu这张表。查询语句为:SELECT max(usage_user) from cpu where (hostname = 'host_0') and time >='2016-01-01T01:16:32Z' and time<'2016-01-01T02:16:32Z' group by time(1m)
可以取出61条数据。

测试结论：平均每秒执行600次查询