influxDB时序数据库的使用

简介

时序数据库

时序数据库全称为时间序列数据库。时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。
时间序列数据主要由电力行业、化工行业等各类型实时监测、检查与分析设备所采集、产生的数据，这些工业数据的典型特点是：产生频率快（每一个监测点一秒钟内可产生多条数据）、严重依赖于采集时间（每一条数据均要求对应唯一的时间）、测点多信息量大（常规的实时监测系统均有成千上万的监测点，监测点每秒钟都产生数据，每天产生几十GB的数据量）。

什么是InfluxDB

InfluxDB是一款用Go语言编写的开源分布式时序、事件和指标数据库，无需外部依赖。该数据库现在主要用于存储涉及大量的时间戳数据，如DevOps监控数据，APP metrics, loT传感器数据和实时分析数据。

InfluxDB特征：

• 无结构(无模式)：可以是任意数量的列(tags)。

• 可以设置metric的保存时间。

• 支持与时间有关的相关函数(如min、max、sum、count、mean、median等)，方便统计。

• 支持存储策略：可以用于数据的删改(influxDB没有提供数据的删除与修改方法)。

• 支持连续查询：是数据库中自动定时启动的一组语句，和存储策略搭配可以降低InfluxDB的系统占用量。

• 原生的HTTP支持，内置HTTP API。

• 支持类似SQL语法。

• 支持设置数据在集群中的副本数。

• 支持定期采样数据，写入另外的measurement，方便分粒度存储数据。

• 自带web管理界面，方便使用(登入方式：http://< InfluxDB-IP >:8083)。

安装

官网下载页面

拉取镜像文件后运行即可，当前最新版本是1.3.5。启动容器时设置挂载的数据目录和开放端口。InfluxDB的操作语法InfluxQL与SQL基本一致，也提供了一个类似mysql-client的名为influx的CLI。InfluxDB本身是支持分布式部署多副本存储的

# docker pull influxdb
# docker run -idt --name influxdb -p 8086:8086 -v /Users/ssj/influxdb:/var/lib/influxdb influxdb
f216e9be15bff545befecb30d1d275552026216a939cc20c042b17419e3bde31
# docker exec -it influxdb /bin/bash 
root@f216e9be15bf:/# influx
Connected to http://localhost:8086 version 1.3.5
InfluxDB shell version: 1.3.5
> create database cadvisor  ## 创建数据库cadvisor
> show databases           
name: databases
name
----
_internal
cadvisor
> CREATE USER testuser WITH PASSWORD 'testpwd' ## 创建用户和设置密码
> GRANT ALL PRIVILEGES ON cadvisor TO testuser ## 授权数据库给指定用户
> CREATE RETENTION POLICY "cadvisor_retention" ON "cadvisor" DURATION 30d REPLICATION 1 DEFAULT ## 创建默认的数据保留策略，设置保存时间30天，副本为1

InfluxDB名词

database：数据库，根关系型数据库一个概念。

measurement：数据库中的表，就是关系型数据库中的表。

points：表里面的一行数据，就是关系型数据库中的记录。

InfluxDB中独有的一些概念

Point由时间戳（time）、标签（tags）和值（field）组成。

time：每条数据记录的时间，也是数据库自动生成的主索引。

tags：各种有索引的属性。

fields：各种记录的值。

tag set：tag在InfluxDB中会按照字典序排序，不管是tag-key还是tag-value，只要不一致就分别属于两个tag set，例如hostname=server01,device=/data和hostname=server02,device=/data就是两个不同的tag set。

还有三个重要的名词：Series、Retention policy和Shard

Series：相当于是InfluxDB中一些数据的集合，在同一个database中，retention policy、measurement、tag sets完全相同的数据同属于一个series，同一个series的数据在物理上会按照时间顺序排列存储在一起。

Retention policy：存储策略，用于设置数据保留的时间，每个数据库刚开始会自动创建一个默认的存储策略autogen，数据保留时间为永久，之后用户可以自己设置，例如保留最近2小时的数据。插入和查询数据时如果不指定存储策略，则使用默认存储策略，且默认存储策略可以修改。InfluxDB会定期清除过期的数据。

Shard：在InfluxDB中是一个比较重要的概念，它和Retention policy相关联。每一个存储策略下会存在许多shard，每一个shard存储一个指定时间段内的数据，并且不重复，例如7点-8点的数据落入shard0中，8点-9点的数据则落入shard1中。每一个shard都对应一个底层的tsm存储引擎，有独立的 cache、wal、tsm file。

TSM存储引擎主要由几个部分组成：cache、wal、tsm file、compactor。

Cache：相当于是LSM Tree中的memtabl。插入数据时，实际上是同时往cache与wal中写入数据，可以认为cache是wal文件中的数据在内存中的缓存。当InfluxDB启动时，会遍历所有的wal文件，重新构造cache，这样即使系统出现故障，也不会导致数据的丢失。cache中的数据并不是无限增长的，有一个maxSize参数用于控制当cache中的数据占用多少内存后就会将数据写入tsm文件。如果不配置的话，默认上限为25MB，每当cache中的数据达到阀值后，会将当前的cache进行一次快照，之后清空当前cache中的内容，再创建一个新的wal文件用于写入，剩下的wal文件最后会被删除，快照中的数据会经过排序写入一个新的tsm文件中。

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

TSM File：单个tsm file大小最大为 2GB，用于存放数据。

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

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

InfluxDB目录与文件

InfluxDB的数据存储主要有三个目录，默认情况下是meta, wal以及data三个目录。

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

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

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

操作

用户管理

# 显示用户;
show users  
  
# 创建用户;
create user "username" with password 'password'
  
# 创建管理员权限用户;
create user "username" with password 'password' with all privileges  
  
# 删除用户;
drop user "username"

数据库与表的操作

可以直接在web管理页面做操作，当然也可以命令行。

# 创建数据库;
create database "db_name"  
  
# 显示所有的数据库;
show databases  
  
# 删除数据库;
drop database "db_name"  
  
# 使用数据库;
use db_name  
  
# 显示该数据库中所有的表;
show measurements  
  
# 创建表,直接在插入数据的时候指定表名(key-value);
insert disk,hostname=server02,device=/data free=90,used=110,used_percent=98.33,count=1
  
# 删除表;
drop measurement "measurement_name"

官方文档:https://docs.influxdata.com/influxdb/v1.7/introduction/getting-started