时序数据库 InfluxDB(六)

简介: 时序数据库 InfluxDB(六)

01


CQ 连续查询


连续查询 Continuous Queries( CQ )是 InfluxDB 很重要的一项功能,它的作用是在 InfluxDB 数据库内部自动定期的执行查询,然后将查询结果存储到指定的 measurement 里。

配置文件中的相关配置:

[continuous_queries]
  enabled = true
  log-enabled = true
  query-stats-enabled = false
  run-interval = "1s"
  • enabled = true开启CQ
  • log-enabled = true输出 CQ 日志
  • query-stats-enabled = false关闭 CQ 执行相关的监控,不会将统计数据写入默认的监控数据库 _internal
  • run-interval = "1s"InfluxDB 每隔 1s 检查是否有 CQ 需要执行



02


基本语法


一 、


基本语法:

CREATE CONTINUOUS QUERY <cq_name> ON <database_name>
BEGIN
  <cq_query>
END

在某个数据库上创建一个 CQ ,而查询的具体内容 cq_query 的语法为:

SELECT <function[s]> 
  INTO <destination_measurement> 
  FROM <measurement> 
  [WHERE <stuff>] 
  GROUP BY time(<interval>)[,<tag_key[s]>]
  • SELECT function[s] : 连续查询并不只是简单的查询原始数据,而是基于原始数据进行聚合、特选、转换、预测等处理,所以 CQ 必须要有一个或多个数据处理函数。
  • INTO : 将 CQ 的结果存储到指定的 measurement 中。
  • FROM : 原始数据的来源 measurement 。
  • [WHERE ] : 可选项,原始数据的筛选条件。
  • GROUP BY time()[,] : 连续查询不是查一次就完了,而是每次查询指定时间范围内的数据,不断周期性的执行下去。


定位一个 measurement 的完整格式是:

<database>.<RP>.<measurement>

使用当前数据库和默认 RP 的情况就只需要 measurement 。


InfluxDB 支持的时长单位:

  • ns      :   纳秒
  • u / µ  :   微秒
  • ms     :   毫秒
  • s        :   秒
  • m       :   分钟
  • h        :   小时
  • d        :   天
  • w       :   周


二、


1、CQ 在何时执行?


CQ 在何时执行取决于 CQ 创建完成的时间点、GROUP BY time() 设置的时间间隔、以及 InfluxDB 数据库预设的时间边界(这个预设的时间边界其实就是 1970.01.01 00:00:00 UTC 时间,对应 Unix timestamp 的 0 值)。



假设我在 2019.11.05(北京时间)创建好了一个 GROUP BY time(30d) 的 CQ(也就是时间间隔为 30 天),那么这个 CQ 会在什么时间点执行?


首先,2019.11.05 号转换为 timestamp 是 1572883200 秒;再算1572883200 距离 0 值隔了多少个 30 天(一天是 86400 秒),1572883200/86400/30 = 606.8那么下一个 30 天就是 606.8 向上取整 607 ,607*86400*30 = 1573344000 ,转换为对应的日期就是 2019.11.10 号,这也就是第一次执行 CQ 的时间,之后每次执行就是往后推 30 天。


如果每次都这样算就很麻烦,但其实我们更常使用的时间间隔没有那么长,通常都是秒、分钟、小时单位,这种情况下直接从 0 速算就可以了,比如:

  • 在时间点 16:09:35 创建了 CQ ,GROUP BY time(30s) ,那么 CQ 的执行时间就是 16:10:00、16:10:30、16:11:00 以此类推(从 0s 开始速算)。
  • 在时间点 16:16:08 创建了 CQ ,GROUP BY time(5m) ,那么 CQ 的执行时间就是 16:20:00、16:25:00、16:30:00 以此类推(从 0m 开始速算)。
  • 在时间点 16:38:27 创建了 CQ ,GROUP BY time(2h) ,那么 CQ 的执行时间就是 18:00:00 、20:00:00 、22:00:00 以此类推(从 0h 开始速算)。


2、CQ 执行的数据范围?


连续查询会根据 GROUP BY time() 的时间间隔确定作用的数据,每次执行所针对的数据的时间范围是 [ now() - GROUP BY time()now() ) 。


例如,GROUP BY time(1h) :

  • 在 8:00 执行时,数据是时间大于等于 7:00,小于 8:00,即 [ 7:00 , 8:00 )  范围内的数据。
  • 在 9:00 执行时,数据是时间大于等于 8:00,小于 9:00,即 [ 8:00 , 9:00 ) 范围内的数据。


你可以使用 WHERE 去过滤数据,但是 WHERE 里指定的时间范围会被忽略掉。



3、CQ 的执行结果?


CQ 会将执行结果存储到指定的 measurement ,但是存储的具体字段有哪些呢?首先 time 是必不可少的,time 写入的是 CQ 执行时数据范围的开始时间点;其次就是 function 的处理结果,如果只有单一字段,那么 field key 就是 function 的名称,如果有多个字段,那么 field key 就是 function 名称_作用字段。


例如,GROUP BY time(30m) ,UTC 7:30 执行:

  • 单一字段:
SELECT mean("field")   
  INTO "result_measurement"   
  FROM "source_measurement"   
  GROUP BY time(30m)

CQ 结果:

time                      mean
2019-11-05T07:00:00Z      7
  • 多字段:
SELECT mean("*") 
  INTO "result_measurement" 
  FROM "source_measurement" 
  GROUP BY time(30m)

CQ 结果

time                      mean_field1    mean_field2
2019-11-05T07:00:00Z      7              6.5

这里的 mean 对应的是 function 里的平均值函数。



三、


GROUP BY time() 的完整格式是:

GROUP BY time(<interval>[,<offset_interval>])

第二个参数 offset_interval 偏移量是可选的,这个偏移量会对 CQ 的执行时间和数据范围产生影响。


如果 GROUP BY time(1h) ,在 8:00 执行,数据范围是 [ 7:00 , 8:00 ) 。

那么 GROUP BY time(1h, 15m) 会使 CQ 的执行时间向后推迟 15m ,即在 8:15 执行,数据范围也就变成了 [ 7:15 , 8:15 ) 。



03


高级语法


高级语法:

CREATE CONTINUOUS QUERY <cq_name> ON <database_name>
RESAMPLE EVERY <interval> FOR <interval>
BEGIN
  <cq_query>
END

与基本语法不同的是,高级语法多了

RESAMPLE EVERY <interval> FOR <interval>

1、RESAMPLE  EVERY


EVERY 定义了 CQ 执行的间隔:

RESAMPLE EVERY 30m

意思就是每隔 30m 执行一次 CQ 。


示例:

CREATE CONTINUOUS QUERY "cq_every" ON "db"
RESAMPLE EVERY 30m
BEGIN
  SELECT mean("field") 
    INTO "result_measurement"
    FROM "source_measurement"
    GROUP BY time(1h)
END

如果没有 RESAMPLE EVERY 30m ,只有 GROUP BY time(1h) 将会:

  • 在 8:00 执行 CQ ,数据范围是 [ 7:00 , 8:00 )
  • 9:00 执行 CQ数据范围是 [ 8:00 , 9:00 ) 


增加了 RESAMPLE EVERY 30m 之后,每 30m 执行一次 CQ :

  • 在 8:00 执行 CQ ,数据范围是 [ 7:00 , 8:00 )
  • 8:30 执行 CQ ,数据范围是 [ 8:00 , 9:00 )
  • 9:00 执行 CQ ,数据范围是 [ 8:00 , 9:00 ) ,由于执行结果的 time 字段是 8:00 与上一次 CQ 一致,因此会覆盖上一次 CQ 的结果。


EVERY 的时间间隔小于 GROUP BY time() 时,会增加 CQ 的执行频率(如上述示例)


EVERYGROUP BY time() 的时间间隔一致时,无影响。


EVERY 的时间间隔大于 GROUP BY time(),CQ 执行时间和数据范围完全由 EVERY 控制,例如 EVERY 30m ,GROUP BY time(10m) :

  • 在 8:00 执行 CQ ,数据范围是 [ 7:30 , 8:00 )
  • 8:30 执行 CQ ,数据范围是 [ 8:00 , 8:30 )



2、RESAMPLE  FOR


FOR 定义了数据的时间范围:

RESAMPLE FOR 1h

意思就是每次 CQ 的数据的时间范围是 1h 。


示例:

CREATE CONTINUOUS QUERY "cq_for" ON "db"
RESAMPLE FOR 1h
BEGIN
  SELECT mean("field") 
    INTO "result_measurement"
    FROM "source_measurement"
    GROUP BY time(30m)
END

如果没有 RESAMPLE FOR 1h ,只有 GROUP BY time(30m) 将会:

  • 在 8:00 执行 CQ ,数据范围是 [ 7:30 , 8:00 )
  • 在 8:30 执行 CQ ,数据范围是 [ 8:00 , 8:30 )


增加了 RESAMPLE FOR 1h 之后,每次 CQ 的时间范围是 1h ,但是因为  GROUP BY time(30m) ,每次 CQ 将会按照 30m 写入两点数据:

  • 在 8:00 执行 CQ ,数据总范围是 [ 7:00 , 8:00 ) ,实际会拆分成两点 [ 7:00 , 7:30 ) 和 [ 7:30 , 8:00 )
  • 在 8:30 执行 CQ ,数据总范围是 [ 7:30 , 8:30 ) ,实际会分成两点 [ 7:30 , 8:00 )[ 8:00 , 8:30 )


FOR 的时间间隔大于 GROUP BY time() 时,每次 CQ 的时间范围被扩大,但是每一个点仍然按照 GROUP BY time() 的时间间隔,因此每次 CQ 会写入多个点(如上述示例)。


FORGROUP BY time() 的时间间隔一致时,无影响。


FOR 的时间间隔小于GROUP BY time(),创建 CQ 时报错,不允许这种情况。



3、EVERY ... FOR


EVERYFOR 可以一起使用。


示例:

CREATE CONTINUOUS QUERY "cq_every_for" ON "db"
RESAMPLE EVERY 1h FOR 90m
BEGIN
  SELECT mean("field") 
    INTO "result_measurement"
    FROM "source_measurement"
    GROUP BY time(30m)
END

EVERY 1h 大于 GROUP BY time(30m),因此 CQ 每隔 1h 执行一次;FOR 90m ,每次 CQ 执行的时间范围是 90m,按照 30m 拆分成三个点:

  • 在 8:00 执行 CQ ,数据总范围 [ 6:30 , 8:00 ) ,实际会拆分为三个点 [ 6:30 , 7:00 )、 [ 7:00 , 7:30 )、 [ 7:30 , 8:00 )
  • 在 9:00 执行 CQ ,数据总范围 [ 7:30 , 9:00 ) ,实际会拆分为三个点  [ 7:30 , 8:00 )、 [ 8:00 , 8:30 )、 [ 8:30 , 9:00 )



最后,CQ 只能创建和删除,无法修改。


目录
相关文章
|
存储 缓存 固态存储
时序数据库 InfluxDB(四)
时序数据库 InfluxDB(四)
212 1
|
7月前
|
数据安全/隐私保护 时序数据库
InfluxData【部署 03】时序数据库 InfluxDB 离线安装配置使用(下载+安装+端口绑定+管理员用户创建+开启密码认证+开机自启配置)完整流程实例分享
InfluxData【部署 03】时序数据库 InfluxDB 离线安装配置使用(下载+安装+端口绑定+管理员用户创建+开启密码认证+开机自启配置)完整流程实例分享
466 0
|
22天前
|
缓存 物联网 数据库
InfluxDB vs TDengine :2025 年了,谁家用的数据库还不能高效读缓存?
在工业互联网和物联网的大数据应用场景中,实时数据的写入和查询性能至关重要。如何快速获取最新设备状态并实时处理数据,直接影响到业务的高效运转。本文将深入分析 TDengine 和 InfluxDB 在缓存机制上的差异,帮助读者更好地理解这两款主流时序数据库在性能优化方面的优劣。
51 1
|
7月前
|
时序数据库
InfluxData【部署 02】时序数据库 InfluxDB 客户端工具 Influx CLI 最新版本安装启动验证(在线安装+离线安装+各版本下载地址)
InfluxData【部署 02】时序数据库 InfluxDB 客户端工具 Influx CLI 最新版本安装启动验证(在线安装+离线安装+各版本下载地址)
737 0
|
7月前
|
存储 监控 Java
InfluxDB时序数据库安装和使用
InfluxDB时序数据库安装和使用
179 2
|
7月前
|
Java API 时序数据库
InfluxData【付诸实践 02】SpringBoot 集成时序数据库 InfluxDB 应用分享(InfluxDB实例+Feign接口调用InfluxDB API)源码分享
InfluxData【付诸实践 02】SpringBoot 集成时序数据库 InfluxDB 应用分享(InfluxDB实例+Feign接口调用InfluxDB API)源码分享
178 0
|
7月前
|
SQL 监控 数据可视化
InfluxData【部署 01】时序数据库 InfluxDB 最新版本安装启动验证(在线安装+离线安装+各版本下载地址)
InfluxData【部署 01】时序数据库 InfluxDB 最新版本安装启动验证(在线安装+离线安装+各版本下载地址)
252 0
|
存储 监控 Go
时序数据库 InfluxDB(五)
时序数据库 InfluxDB(五)
182 1
|
存储 消息中间件 容灾
时序数据库 InfluxDB(七)
时序数据库 InfluxDB(七)
212 0
|
存储 缓存 数据库
时序数据库 InfluxDB(三)
时序数据库 InfluxDB(三)
235 0