180726-InfluxDB基本概念小结
by 一灰灰

2018-07-26

DB / InfluxDB

13 分钟读完 (大约 1902 个字) 0次访问

180726-InfluxDB基本概念小结

文章目录

InfluxDB基本概念小结

InfluxDB作为时序数据库，与传统的关系型数据库相比而言，还是有一些区别的，下面尽量以简单明了的方式介绍下相关的术语概念

I. 基本概念

mysql	influxdb	说明
database	database	数据库
table	measurement	类似mysql中表的概念
record	tag + field + timestamp	传统表中的一行数据，映射到influxdb中，可以划分为三个

1. database

数据库，和mysql的数据库相比，没有太大的歧义

2. measurement

对比的是mysql中的table，从实际体验来看，两个之间最明显的区别在于没有单独的创建measurement的方法，直接新增一条数据时，若measurement不存在，则直接创建并插入一条数据

3. Point

这个对比的是mysql中的record，在influxDB中，表示每个表中，某个时刻，满足某个条件的filed数据（简单来说就是 timestamp + tag + filed)的组成一个point

timestamp : 时间戳，ns单位，每个记录都必然有这个属性，没有显示添加时，默认给一个
tag: 标签，kv结构，在database中， tag + measurement 一起构建索引
- 参与索引创建，因此适合作为查询的过滤条件
- tag的数据量不要太多，最好能有典型的辨别性（和mysql的建立索引的原则差不多）
- value为String类型
- tag是可选的，在measurement不设置tag也是ok的
field：存储数据，kv结构
- 数据类型为: long, String, boolean, float

4. Series

Series: tag key 与tag value的唯一组合

II. 实例分析

上面几个为基本的概念，单独的看起来印象不够深刻，下面结合实例进行说明：

建立一个measurement,保存某个应用的性能状况，包含以下指标, 每秒写一次数据到influxDB中

服务机器: host=127.0.0.1
服务接口: service=app.service.index
qps: qps=1340
rt: 1313
cpu: 45.23
mem: 4154m
load: 1.21

1. measurement创建

上面有7个指标参数，第一步就是区分tag和field，前面说到tag会建索引，推荐用于可以区分类型，取值可以预估的字段，所以对上面进行如下区分

tag

host
servie

field

qps
rt
cpu
mem
load

一条实际的插入数据如

> insert myapp,host=127.0.0.1,service=app.service.index qps=1340,rt=1313,cpu=45.23,mem="4145m",load=1.21
> select * from myapp
name: myapp
time                cpu   host      load mem   qps  rt   service
----                ---   ----      ---- ---   ---  --   -------
1532597158613778583 45.23 127.0.0.1 1.21 4145m 1340 1313 app.service.index

a. 小结说明

在insert执行语句中，tag与tag、field与field之间用都好进行分割，tag与field之间用空格分割
tag的value都是，String类型，不需要加双引号
field的String类型数据，需要放在双引号中，否则会报错
如果需要显示添加时间戳，在filed后添加空格，再添加时间戳

b. 是否可以没有field

实测不行，输出如下

1 2	> insert myabb,host=123,service=index ERR: {"error":"unable to parse 'myabb,host=123,service=index ': invalid field format"}

是否可以没有tag

根据前面的说明已经实测，可以

> insert myabb qps=123,rt=1231
> select * from myabb
name: myabb
time                qps rt
----                --- --
1532597385053030634 123 1231

2. 数据分析

新插入几条数据，目前的数据为

> select * from myapp
name: myapp
time                cpu   host      load mem   qps  rt   service
----                ---   ----      ---- ---   ---  --   -------
1532597158613778583 45.23 127.0.0.1 1.21 4145m 1340 1313 app.service.index
1532597501578551929 45.23 127.0.0.1 1.21 4145m 1341 1312 app.service.index
1532597510225918132 45.23 127.0.0.1 1.21 4145m 1341 1312 app.service.about
1532597552421996033 45.23 127.0.0.2 1.21 4145m 1341 1312 app.service.about

a. series

上面四条数据，对应几个series呢？

根据前面的说法，tagKey + tagValue 确定给一个series （实际上是 measurement + retention policy + tags来确定)，因此上表总共有三个series

127.0.0.1 | app.service.index
127.0.0.1 | app.service.about
127.0.0.2 | app.service.about

那么这个series到底是什么东西呢？

如果将上面的数据图表化的方式显示出来，我们可以怎么办？

首先我们确定好应用及其和服务名，然后查看这个服务在这台机器上，在时间线上的服务性能
翻译过来就是，将cpu/service作为检索条件，以time为时间轴，将value(cpu,load,mem,qps,rt)映射到二维坐标上作为一个点（point），然后将所有的point连接成线，最终得到连续的图表

所以series就是上面的检索条件，同时point的概念也容易理解了

III. 保留策略

前面是表数据的相关基础概念，这里还有一个就是数据保存的策略 retention policy, 用于决定数据保存多久（意思是数据可以删除），保存几个备份，集群的处理等

1. 基本说明

influxdb面向大数据的时序数据库，所以数据量可以很大很大，如果全部存储，估计硬盘的费用都不小，而且有些数据可能并不需要永久存储，因此就有了这个rentention policy

InfluxDB本身不提供数据的删除操作，因此用来控制数据量的方式就是定义数据保留策略。

因此定义数据保留策略的目的是让InfluxDB能够知道可以丢弃哪些数据，从而更高效的处理数据。

2. 基本操作

a. 查询策略

> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        true

name: 名称
duration: 保留时间, 0表示永久保存
shardGroupDuration: shardGroup的存储时间，shardGroup是InfluxDB的一个基本储存结构，应该大于这个时间的数据在查询效率上应该有所降低。
replicaN: 全称是REPLICATION，副本个数
default: 是否是默认策略

b. 新建策略

> create retention policy "2_hour" on hh_test duration 2h replication 1 default
> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false
2_hour  2h0m0s   1h0m0s             1        true

c. 修改策略

> alter retention policy "2_hour" on hh_test duration 4h default
> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false
2_hour  4h0m0s   1h0m0s             1        true

d. 删除策略

> drop retention policy "2_hour" on hh_test
> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false

删除默认策略之后，就没有默认策略了，是否会有问题呢？

3. RP理解

设置这个策略之后，会自动删除过期的数据，那么数据时怎么保存的呢？

比如默认的永久保存策略中，有个 shardGroupDuration 参数，为7天，也就是说7天的数据放在一个Shard中，过了之后，新加一个Shard

shard包含实际的编码和压缩数据，并由磁盘上的TSM文件表示。每个shard都属于唯一的一个shard group。多个shard可能存在于单个shard group中。每个shard包含一组特定的series。给定shard group中的给定series上的所有点将存储在磁盘上的相同shard（TSM文件）中。

IV. 其他

1. 一灰灰Blog： https://liuyueyi.github.io/hexblog

一灰灰的个人博客，记录所有学习和工作中的博文，欢迎大家前去逛逛

2. 声明

尽信书则不如，已上内容，纯属一家之言，因个人能力有限，难免有疏漏和错误之处，如发现bug或者有更好的建议，欢迎批评指正，不吝感激

微博地址: 小灰灰Blog
QQ：一灰灰/3302797840

3. 扫描关注

一灰灰blog

QrCode

知识星球

goals

# InfluxDB

支付宝

微信

一灰灰Blog

Java,Python,DBA, 主旨服务器，兼职全栈

Wuhan, China

文章

523

分类

101

标签

122

关注我