influxdb 时间序列数据库

1、InfluxDB 是用Go语言编写的一个开源分布式时序、事件和指标数据库，无需外部依赖。 基于时间序列，支持与时间有关的相关函数（如最大，最小，求和等） 可度量性：你可以实时对大量数据进行计算 基于事件：它支持任意的事件数据 1）无结构（无模式）：可以是任意数量的列 2）可拓展的 3）支持min, max, sum, count, mean, median 等一系列函数，方便统计 4）原生的HTTP支持，内置HTTP API 5）强大的类SQL语法 6）自带管理界面，方便使用 2、安装： rpm -ivh https://dl.influxdata.com/influxdb/releases/influxdb-0.13.0.x86_64.rpm 3、启动： sudo service influxdb start 4、客户端： 在usr/bin里使用influx即可登入Influx服务器。也可以将路径加入环境变量中，这样既可在任意地方使用influx。 InfluxDB自带web管理界面，在浏览器中输入 http://服务器IP:8083 即可进入web管理页面。 5、基本概念： database 数据库 measurement 表 point 表中的一行数据 point由time(自动生成的时间戳),field数据，tags由索引的数据 series所有在数据库中的数据，都需要通过图表来展示，而这个series表示这个表里面的数据，可以在图表上画成几条线：通过tags排列组合算出来。 6、基本操作: 客户端命令行、HTTP API、各语言API库 show databases; create database test drop database test use test

show measurements //其中 disk_free 就是表名，hostname是索引，value=xx是记录值，记录值可以有多个，最后是指定的时间。没有建表语句，直接插入 insert testtable,hostname=server01 value=442221834240i 1435362189575692182 select * from testtable drop measurement testtable 增加数据采用insert的方式，要注意的是 InfluxDB的insert中，表名与数据之间用逗号（,）分隔，tag和field之间用 空格分隔，多个tag或者多个field之间用逗号（,）分隔。 //没有修改 insert testtable,hostname=server01,regin=test value=0

7 http://ip:8083

image.png

8、HTTP API操作 创建数据库：curl -POST http://localhost:8086/query --data-urlencode "q=CREATE DATABASE mydb" 删除：curl -POST http://localhost:8086/query --data-urlencode "q=DROP DATABASE mydb" 插入数据：curl -i -XPOST 'http://localhost:8086/write?db=mydb' --data-binary 'cpu_load_short,host=server01,region=us-west value=0.64 1434055562000000000'

curl -i -XPOST 'http://localhost:8086/write?db=mydb' --data-binary 'cpu_load_short,host=server02 value=0.67 cpu_load_short,host=server02,region=us-west value=0.55 1422568543702900257 cpu_load_short,direction=in,host=server01,region=us-west value=2.0 1422568543702900257' 响应： 1）2xx：204代表no content，200代表InfluxDB可以接收请求但是没有完成请求。一般会在body体中带有出错信息。 2）4xx：InfluxDB不能解析请求。 3）5xx：系统出现错误。

9、查看数据库策略： SHOW RETENTION POLICIES ON test 数据保留时间：duration--持续时间，0代表无限制 创建数据只保留2小时的策略，并设为默认策略： CREATE RETENTION POLICY "2_hours" ON "telegraf" DURATION 2h REPLICATION 1 DEFAULT 因为名为default的策略不再是默认策略，因此，在查询使用default策略的表时要显式的加上策略名 “default”。 select * from "default".cpu limit 2 修改策略使用如下语句修改： ALTER RETENTION POLICY "2_hours" ON "telegraf" DURATION 4h DEFAULT 删除策略： drop retention POLICY "2_hours" ON "telegraf"

10、InfluxDB连续查询： InfluxDB的连续查询是在数据库中自动定时启动的一组语句，语句中必须包含 SELECT 关键词和 GROUP BY time() 关键词。 InfluxDB会将查询结果放在指定的数据表中。 11、创建连续查询：在telegraf库中新建了一个名为 cq_30m 的连续查询，每三十分钟取一个used字段的平均值，加入 mem_used_30m 表中。使用的数据保留策略都是 default。 CREATE CONTINUOUS QUERY cq_30m ON telegraf BEGIN SELECT mean(used) INTO mem_used_30m FROM mem GROUP BY time(30m) END SHOW CONTINUOUS QUERIES 12、DROP CONTINUOUS QUERY <cq_name> ON <database_name> 删除连续查询 13、HTTP API查询： curl -G 'http://localhost:8086/query?pretty=true' --data-urlencode "db=mydb" --data-urlencode "q=SELECT value FROM cpu_load_short WHERE region='us-west'; SELECT count(value) FROM cpu_load_short WHERE region='us-west'" 多条语句 curl -GET 'http://localhost:8086/query?pretty=true' --data-urlencode "db=mydb" --data-urlencode "q=SELECT value FROM cpu_load_short WHERE region='us-west'" 单条语句 规定时间格式：epoch=h,m,s,ms,u,ns curl -G 'http://localhost:8086/query' --data-urlencode "db=mydb" --data-urlencode "epoch=s" --data-urlencode "q=SELECT value FROM cpu_load_short WHERE region='us-west'" 指定每次查询的数据量：chunk_size 200 curl -G 'http://localhost:8086/query' --data-urlencode "db=mydb" --data-urlencode "chunk_size=200" --data-urlencode "q=SELECT value FROM cpu_load_short WHERE region='us-west'" 14、概念： database,measurement, tag--标签，在InfluxDB中，tag是一个非常重要的部分，表名+tag一起作为数据库的索引，是“key-value”的形式 field--数据，field主要是用来存放数据的部分，也是“key-value”的形式 timestamp--时间戳，作为时序型数据库，时间戳是InfluxDB中最重要的部分，在插入数据时可以自己指定也可留空让系统指定。 说明：在插入新数据时，tag、field和timestamp之间用空格分隔。 series--序列，所有在数据库中的数据，都需要通过图表来展示，而这个series表示这个表里面的数据，可以在图表上画成几条线。 Retention policy--数据保留策略，可以定义数据保留的时长，每个数据库可以有多个数据保留策略，但只能有一个默认策略。。 Point--点，表示每个表里某个时刻的某个条件下的一个field的数据，因为体现在图表上就是一个点，于是将其称为point。 15、聚合函数： SELECT COUNT(<field_key>) FROM <measurement_name> [WHERE <stuff>] [GROUP BY <stuff>] SELECT COUNT(water_level) FROM h2o_feet WHERE time >= '2015-08-18T00:00:00Z' AND time < '2015-09-18T17:00:00Z' GROUP BY time(4d) SELECT DISTINCT("level description") FROM h2o_feet SELECT MEAN(<field_key>) FROM <measurement_name> [WHERE <stuff>] [GROUP BY <stuff>] SELECT MEDIAN(water_level) from h2o_feet SELECT SPREAD(water_level) FROM h2o_feet 返回字段最小值和最大值的差值 SELECT SUM(water_level) FROM h2o_feet COUNT,DISTINCT,MEAN,MEDIAN,SPREAD,SUM 16、选择函数： SELECT TOP("water_level",3) FROM "h2o_feet" SELECT BOTTOM(water_level,3) FROM h2o_feet 返回最小的三个值 SELECT FIRST(water_level) FROM h2o_feet WHERE location = 'santa_monica' 最旧的值 SELECT LAST(water_level),location FROM h2o_feet WHERE time >= '2015-08-18T00:42:00Z' and time <= '2015-08-18T00:54:00Z' 最新的值 SELECT MAX(water_level),location FROM h2o_feet SELECT MIN(water_level),location FROM h2o_feet SELECT PERCENTILE(water_level,5),location FROM h2o_feet PERCENTILE：排序中0-100的某个值 17、变换类函数： DERIVATIVE：返回一个字段的变化率 SELECT PERCENTILE(water_level,5),location FROM h2o_feet SELECT DERIVATIVE(water_level) FROM h2o_feet WHERE location = 'santa_monica' LIMIT 5 SELECT DERIVATIVE(water_level,6m) FROM h2o_feet WHERE location = 'santa_monica' LIMIT 5 计算每六分钟的变化率 DIFFERENCE：连续的时间值之间的差异 SELECT water_level FROM h2o_feet WHERE location='santa_monica' AND time >= '2015-08-18T00:00:00Z' and time <= '2015-08-18T00:36:00Z' SELECT DIFFERENCE(water_level) FROM h2o_feet WHERE location='santa_monica' AND time >= '2015-08-18T00:00:00Z' and time <= '2015-08-18T00:36:00Z' ELAPSED：连续时间间隔的差异 SELECT ELAPSED(water_level) FROM h2o_feet WHERE location = 'santa_monica' AND time >= '2015-08-18T00:00:00Z' and time <= '2015-08-18T00:24:00Z' MOVING_AVERAGE：返回一个连续字段值的移动平均值，字段类型必须是长整形或者float64类型 SELECT water_level FROM h2o_feet WHERE location = 'santa_monica' AND time >= '2015-08-18T00:00:00Z' and time <= '2015-08-18T00:36:00Z' NON_NEGATIVE_DERIVATIVE：返回在一个series中的一个字段中值的变化的非负速率 SELECT NON_NEGATIVE_DERIVATIVE(AGGREGATION_FUNCTION(<field_key>),[<unit>]) FROM <measurement_name> WHERE <stuff> GROUP BY time(<aggregation_interval>) STDDEV： SELECT STDDEV(water_level) FROM h2o_feet 18、指定连续查询的时间范围： 可以使用RESAMPLE FOR 关键词来指定连续查询的时间范围 CREATE CONTINUOUS QUERY vampires_1 ON transylvania RESAMPLE FOR 60m BEGIN SELECT count(dracula) INTO vampire_populations_1 FROM raw_vampires GROUP BY time(30m) END 这个语句每次会将1小时的数据执行连续查询，也就是说，每次执行时，会将now()到now()-30m和now()-30m到now()-60m分别做连续查询，这样我们就可以手动指定连续查询的时间范围了 -- RESAMPLE EVERY：指定连续查询的频率 CREATE CONTINUOUS QUERY vampires ON transylvania RESAMPLE EVERY 15m BEGIN SELECT count(dracula) INTO vampire_populations FROM raw_vampires GROUP BY time(30m) END 19、InfluxDB的特点：

• 可以设置metric的保存时间。
• 支持通过条件过滤以及正则表达式删除数据。
• 支持类似 sql 的语法。
• 可以设置数据在集群中的副本数。
• 支持定期采样数据，写入另外的measurement，方便分粒度存储数据 20、cpu_usage,host=server01,region=us-west value=0.64 1434055562000000000 series 相当于是 InfluxDB 中一些数据的集合，在同一个 database 中，retention policy、measurement、tag sets 完全相同的数据同属于一个 series，同一个 series 的数据在物理上会按照时间顺序排列存储在一起。 21、shard:在 InfluxDB 中是一个重要的概念，它和 retention policy 相关联。每一个存储策略下会存在许多 shard，每一个 shard 存储一个指定时间段内的数据，并且不重复，例如 7点-8点 的数据落入 shard0 中，8点-9点的数据则落入 shard1 中。每一个 shard 都对应一个底层的 tsm 存储引擎，有独立的 cache、wal、tsm file。 22\ TSM Tree 的算法 TSM存储引擎：cache,wal,tsm file,compactor 23 shard: shard 并不能算是其中的一个组件，因为这是在 tsm 存储引擎之上的一个概念。在 InfluxDB 中按照数据的时间戳所在的范围，会去创建不同的 shard，每一个 shard 都有自己的 cache、wal、tsm file 以及 compactor，这样做的目的就是为了可以通过时间来快速定位到要查询数据的相关资源，加速查询的过程，并且也让之后的批量删除数据的操作变得非常简单且高效。

在 LSM Tree 中删除数据是通过给指定 key 插入一个删除标记的方式，数据并不立即删除，需要等之后对文件进行压缩合并时才会真正地将数据删除，所以删除大量数据在 LSM Tree 中是一个非常低效的操作。

而在 InfluxDB 中，通过 retention policy 设置数据的保留时间，当检测到一个 shard 中的数据过期后，只需要将这个 shard 的资源释放，相关文件删除即可，这样的做法使得删除过期数据变得非常高效。 24 cache: 插入数据时，实际上是同时往 cache 与 wal 中写入数据，可以认为 cache 是 wal 文件中的数据在内存中的缓存。当 InfluxDB 启动时，会遍历所有的 wal 文件，重新构造 cache，这样即使系统出现故障，也不会导致数据的丢失。

cache 中的数据并不是无限增长的，有一个 maxSize 参数用于控制当 cache 中的数据占用多少内存后就会将数据写入 tsm 文件。如果不配置的话，默认上限为 25MB，每当 cache 中的数据达到阀值后，会将当前的 cache 进行一次快照，之后清空当前 cache 中的内容，再创建一个新的 wal 文件用于写入，剩下的 wal 文件最后会被删除，快照中的数据会经过排序写入一个新的 tsm 文件中。

目前的 cache 的设计有一个问题，当一个快照正在被写入一个新的 tsm 文件时，当前的 cache 由于大量数据写入，又达到了阀值，此时前一次快照还没有完全写入磁盘，InfluxDB 的做法是让后续的写入操作失败，用户需要自己处理，等待恢复后继续写入数据。 25 wal： wal 文件的内容与内存中的 cache 相同，其作用就是为了持久化数据，当系统崩溃后可以通过 wal 文件恢复还没有写入到 tsm 文件中的数据。

由于数据是被顺序插入到 wal 文件中，所以写入效率非常高。但是如果写入的数据没有按照时间顺序排列，而是以杂乱无章的方式写入，数据将会根据时间路由到不同的 shard 中，每一个 shard 都有自己的 wal 文件，这样就不再是完全的顺序写入，对性能会有一定影响。看到官方社区有说后续会进行优化，只使用一个 wal 文件，而不是为每一个 shard 创建 wal 文件。

wal 单个文件达到一定大小后会进行分片，创建一个新的 wal 分片文件用于写入数据。 26 tsm file 单个 tsm file 大小最大为 2GB，用于存放数据。

TSM file 使用了自己设计的格式，对查询性能以及压缩方面进行了很多优化，在后面的章节会具体说明其文件结构。 27 compactor: compactor 组件在后台持续运行，每隔 1 秒会检查一次是否有需要压缩合并的数据。

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

另外一种就是合并当前的 tsm 文件，将多个小的 tsm 文件合并成一个，使每一个文件尽量达到单个文件的最大大小，减少文件的数量，并且一些数据的删除操作也是在这个时候完成 28 InfluxDB 的数据存储主要有三个目录。

默认情况下是 meta, wal 以及 data 三个目录。

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

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

wal 目录结构

-- wal -- mydb -- autogen -- 1 -- _00001.wal -- 2 -- _00035.wal -- 2hours -- 1 -- _00001.wal

data 目录结构

-- data -- mydb -- autogen -- 1 -- 000000001-000000003.tsm -- 2 -- 000000001-000000001.tsm -- 2hours -- 1 -- 000000002-000000002.tsm 其中 mydb 是数据库名称，autogen 和 2hours 是存储策略名称，再下一层目录中的以数字命名的目录是 shard 的 ID 值，比如 autogen 存储策略下有两个 shard，ID 分别为 1 和 2，shard 存储了某一个时间段范围内的数据。再下一级的目录则为具体的文件，分别是 .wal 和 .tsm 结尾的文件。 29 备份源数据： influxd backup /tmp/backup 备份数据库：influxd backup -database <mydatabase> <path-to-backup> influxd backup -database telegraf -retention autogen -since 2016-02-01T00:00:00Z /tmp/backup 远程备份： influxd backup -database mydatabase -host 10.0.0.1:8088 /tmp/mysnapshot 数据恢复：influxd restore [ -metadir | -datadir ] <path-to-meta-or-data-directory> <path-to-backup> influxd restore -database telegraf -datadir /var/lib/influxdb/data /tmp/backup 30 管理语句： SHOW QUERIES 展示正在执行的语句 KILL QUERY <qid> max-concurrent-queries项是配置最大的可执行的命令数，此项值为零则表示无限制。 query-timeout项用来配置命令的超时时间，如果命令的执行时长超过了此时间，则influxDB会杀掉这条语句并报出如下错误： log-queries-after用来配置执行时长为多少的语句会被记录为慢查询。配置为0则表示不会记录这些语句。 max-select-point配置一次可查询出的数据量，因为在influxDB中一条数据看做一个点，因此这个配置叫每次可查询的最大的点数。 max-select-series用来配置influxDB语句中最多可处理的series的数量，如果你的语句中要处理的series数量大于此配置，则influxDB不会执行这条语句并且会报出如下错误：

教程：https://www.linuxdaxue.com/influxdb-study-series-manual.html