InfluxDB 是一种时序数据库,时序数据库通常被用在监控场景,比如运维和 IOT(物
联网)领域。这类数据库旨在存储时序数据并实时处理它们。
比如。我们可以写一个程序将服务器上 CPU 的使用情况每隔 10 秒钟向 InfluxDB 中写
入一条数据。接着,我们写一个查询语句,查询过去 30 秒 CPU 的平均使用情况,然后让
这个查询语句也每隔 10 秒钟执行一次。最终,我们配置一条报警规则,如果查询语句的执
行结果>xxx,就立刻触发报警。
上述就是一个指标监控的场景,在 IOT 领域中,也有大量的指标需要我们监控。比如,
机械设备的轴承震动频率,农田的湿度温度等等。
时间序列数据主要由电力行业、化工行业、气象行业、地理信息等各类型实时监测、检查与分析设备所采集、产生的数据,这些工业数据的典型特点是:产生频率快(每一个监测点一秒钟内可产生多条数据)、严重依赖于采集时间(每一条数据均要求对应唯一的时间)、测点多信息量大(常规的实时监测系统均有成千上万的监测点,监测点每秒钟都产生数据,每天产生几十GB的数据量)。基于时间序列数据的特点,关系型数据库无法满足对时间序列数据的有效存储与处理,因此迫切需要一种专门针对时间序列数据来做优化的数据库系统,即时间序列数据库。
关系型数据库也是支持时间戳的,也能够基于时间戳进行查询。但是,从我们的使用
场景出发,需要注意数据库的写入性能。通常,关系型数据库会采用 B+树数据结构,在数
据写入时,有可能会触发叶裂变,从而产生了对磁盘的随机读写,降低写入速度。
当前市面上的时序数据库通常都是采用 LSM Tree 的变种,顺序写磁盘来增强数据的写
入能力。
我们之前说,时序数据库一般用于指标监控场景。这个场景的数据有一个非常明显的特点就是冷热差别明显。通常,指标监控只会使用近期一段时间的数据,比如我只查询某个设备最近 10 分钟的记录,10 分钟前的数据我就不再用了。那么这 10 分钟前的数据,对我们来说就是冷数据,应该被压缩放到磁盘里去来节省空间。而热数据因为经常要用,数据库就应该让它留在内存里,等待查询。而市面上的时序数据库大都有类似的设计。
时序数据是描述一个实体在不同时间所处的不同状态。
就像是我们打开任务管理器,查看 CPU 的使用情况。我发现 CPU 占用率太高了,于
是杀死了一个进程,但 10秒前的数据不会因为我关闭进程再发生改变了。
这是时序数据的一大特点。与之相应,时序数据库基本上是插入操作较多,而且还没
有什么更新需求。
docker pull tutum/influxdb
docker run -d -p 8083:8083 -p 8086:8086 --name my_influxdb influxd
图形化界面
使用浏览器访问 http://x.x.x.x:8086。如果是安装后的首次使用,InfluxDB 会返回一
个初始化的引导界面。按照给定步骤完成操作。
InfluxDB是一个由InfluxData开发的开源时序型数据。它由Go写成,着力于高性能地查询与存储时序型数据。
名称 说明 | 组织 |
---|---|
organization | 组织 |
Member | 用户,可设置权限 |
API TOKEN | 调用API时使用的token |
bucket | 数据桶(数据库) |
measurement | 数据表 |
point | 数据点,表示单条数据记录,point由时间戳(time)、数据(field)、标签(tag)三类字段组成 |
retention policy | 数据保留策略,可以定义数据保留的时长,每个数据库可以有多个数据保留策略,但只能有一个默认策略 |
time | 代表每条数据的时间字段,是measurement中的数据主键,因此time字段具有索引属性。一条point只能有一个time |
field | 代表各种数据的字段,例如气温、压力、股价等。field字段没有索引属性,一条point可以包括多个field |
tag | 代表各类非数据字段,例如设备编码、地区、姓名等。tag字段有索引属性,一条point可以包括多个tag(tag只能为字符串类型) |
InfluxDB与常用的关系型数据库(MySQL)的概念对比:
MySQL | InfluxDB | |
---|---|---|
数据库 | database | bucket |
表名 | table | measurement |
记录 | rows | point |
字段 | columns | time+tag+field |
Flux 是 InfluxData 的功能性数据脚本语言,设计用于查询、分析和处理数据,它是InfluxQL 和其他类似 SQL 的查询语言的替代品。
from(bucket: “hrecord_bucket”)
// 配合InfluxDB客户端中的时间控件使用
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
//查询具体时间段
|> range(start: 2022-09-26T01:14:00.000Z, stop: 2022-09-30T01:14:00.000Z)
// 查询过去一小时
|> range(start: -1h)
// 筛选数据表
|> filter(fn: (r) => r["_measurement"] == "tbl_hrecord")
//筛选车牌号
|> filter(fn: (r) => r["plate_code"] == "京FGS002")
// 按照时间降序排列,desc:false 为升序
|> sort(columns:[“_time”], desc: true)
//查询前十条
|> limit(n: 10, offset: 0)
|> pivot(columnKey: [“_field”], rowKey: [“recordId”,“_time”], valueColumn: “_value”)
// 按车牌号码和车牌颜色分组
|> group(columns:["plate_code","plate_color"] , mode: "by")
数据保留的默认时长?
如果没有指定 retention policy,InfluxDB 会使用默认的 retention policy。在默认的 retention policy 中,InfluxDB 会保留最近的无限期数据,以及从过去 7 天内的数据。因此,InfluxDB 会自动删除过去 7 天前的数据。
有没有对应的InfluxDB框架(类似gorm)?
以下是一些常用的 Go 语言的 InfluxDB 框架:
|> sort(columns:[“_time”], desc: true) ,sort的第三个参数可以不指定吗?
可以,如果不指定 desc
参数,则默认为 false
,表示按照指定列的升序排列。如果指定 desc: true
,则按照指定列的降序排列。
什么情况下会用到列转行?
在 InfluxDB 中,列转行通常用于以下情况:
需要注意的是,虽然列转行可以方便地处理表格数据,但是在实际应用中,它可能会增加数据处理的复杂性和计算量。因此,在使用列转行时,需要根据具体情况进行权衡和优化,以确保数据处理的效率和准确性。
能否使用可视化定义配置文件?
可以使用对应的influxdb可视化界面生成基本的配置文件,然后根据需求将部分配置做对应的更改