0
点赞
收藏
分享

微信扫一扫

大数据之时序数据库InfluxDB基本概念篇

黄昏孤酒 2022-11-02 阅读 88


大数据之时序数据库InfluxDB基本概念篇_数据

InfluxDB基本概念小结

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

I. 基本概念

大数据之时序数据库InfluxDB基本概念篇_数据_02

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

一条实际的插入数据如

大数据之时序数据库InfluxDB基本概念篇_mysql_03

a. 小结说明

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

b. 是否可以没有field

实测不行,输出如下

大数据之时序数据库InfluxDB基本概念篇_string类_04

c. 是否可以没有tag

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

大数据之时序数据库InfluxDB基本概念篇_数据_05

2. 数据分析

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

大数据之时序数据库InfluxDB基本概念篇_string类_06

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. 查询策略

大数据之时序数据库InfluxDB基本概念篇_mysql_07

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

b. 新建策略

大数据之时序数据库InfluxDB基本概念篇_string类_08

c. 修改策略

大数据之时序数据库InfluxDB基本概念篇_string类_09

d. 删除策略

大数据之时序数据库InfluxDB基本概念篇_mysql_10

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

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

大数据之时序数据库InfluxDB基本概念篇_数据_11

举报

相关推荐

0 条评论