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

实测不行，输出以下

> 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&公众号

知识星球