采样和数据保留
InfluxDB提供了两个特性——连续查询(Continuous Queries简称CQ)和保留策略(Retention Policies简称RP),分别用来处理数据采样和管理老数据的。这一章将会展示CQs和RPs的例子,看下在InfluxDB中怎么使用这两个特性。
Continuous Query (CQ)是在数据库内部自动周期性跑着的一个InfluxQL的查询,CQs需要在语句中使用一个函数,并且一定包括一个GROUP BY time()
语句。
Retention Policy (RP)是InfluxDB数据架构的一部分,它描述了InfluxDB保存数据的时间。InfluxDB会比较服务器本地的时间戳和请求数据里的时间戳,并删除比你在RPs里面用DURATION
设置的更老的数据。一个数据库中可以有多个RPs但是每个数据库的RPs是唯一的。
这一章不会详细地介绍创建和管理CQs和RPs的语法,如果你对这两个概念还是很陌生的话,建议查看CQ文档和。
本节使用虚构的实时数据,以10秒的间隔,来追踪餐厅通过电话和网站订购食品的订单数量。我们会把这些数据存在food_data
数据库里,其measurement为orders
,fields分别为phone
和website
。
就像这样:
假定在长时间的运行中,我们只关心每三十分钟通过手机和网站订购的平均数量,我们希望用RPs和CQs实现下面的需求:
- 自动将十秒间隔数据聚合到30分钟的间隔数据
- 自动删除超过52周的30分钟间隔数据
> CREATE DATABASE "food_data"
如果我们写数据的时候没有指定RP的话,InfluxDB会使用默认的RP,我们设置默认的RP是两个小时。使用CREATE RETENTION POLICY
语句来创建一个默认RP:
这个RP的名字叫two_hours
作用于food_data
数据库上,two_hours
保存数据的周期是两个小时,并作为food_data
的默认RP。
复制片参数(REPLICATION 1)是必须的,但是对于单个节点的InfluxDB实例,复制片只能设为1
接下来我们创建另一个RP保留数据52周,但不是数据库的默认RP。最终30分钟间隔的数据会保存在这个RP里面。
使用CREATE RETENTION POLICY
语句来创建一个非默认的RP:
> CREATE RETENTION POLICY "a_year" ON "food_data" DURATION 52w REPLICATION 1
这个语句对数据库创建了一个叫做a_year
的RP,a_year
保存数据的周期是52周。去掉DEFAULT
参数可以保证a_year
不是数据库food_data
的默认RP。这样在读写的时候如果没有指定,仍然是使用two_hours
这个默认RP。
使用CREATE CONTINUOUS QUERY
来生成一个CQ:
上面创建了一个叫做cq_30m
的CQ作用于food_data
数据库上。cq_30m
告诉InfluxDB每30分钟计算一次measurement为orders
并使用默认RPtow_hours
的字段website
和phone
的平均值,然后把结果写入到RP为a_year
,两个字段分别是mean_website
和mean_phone
的measurement名为downsampled_orders
的数据中。InfluxDB会每隔30分钟跑对之前30分钟的数据跑一次这个查询。
使用新的CQ和两个新的RPs,food_data
已经开始接收数据了。之后我们向数据库里写数据,并且持续一段时间之后,我们可以看到两个measurement分别是orders
和downsampled_orders
。
> SELECT * FROM "orders" LIMIT 5
name: orders
time phone website
2016-05-13T23:00:00Z 10 30
2016-05-13T23:00:10Z 12 39
2016-05-13T23:00:20Z 11 56
2016-05-13T23:00:40Z 17 32
> SELECT * FROM "a_year"."downsampled_orders" LIMIT 5
name: downsampled_orders
---------------------
time mean_phone mean_website
2016-05-13T15:00:00Z 12 23
2016-05-13T15:30:00Z 13 32
2016-05-13T16:00:00Z 19 21
2016-05-13T16:30:00Z 3 26
在orders
里面是10秒钟间隔的裸数据,保存时间为2小时。在downsampled_orders
里面是30分钟的聚合数据,保存时间为52周。
注意到downsampled_orders
返回的第一个时间戳比orders
返回的第一个时间戳要早,这是因为InfluxDB已经删除了orders
中时间比本地早两个小时的数据。InfluxDB会在52周之后开始删除downsampled_orders
中的数据。
使用RPs和CQs的组合,我们已经成功地创建的数据库并保存高精度的裸数据较短的时间,而保存高精度的数据更长时间。现在我们对这些特性的工作有了大概的了解,我们推荐到CQs和去看更详细的文档。