Documentation

下采样并保留数据

此页面记录了 InfluxDB OSS 的早期版本。 InfluxDB OSS v2 是最新的稳定版本。 请参阅相应的 InfluxDB v2 文档: 使用 InfluxDB 进行数据降采样

InfluxDB 每秒可以处理数十万的数据点。长时间处理大量数据可能会造成存储问题。一个自然的解决方案是对数据进行降采样;仅在有限的时间内保留高精度的原始数据,并长时间存储低精度的汇总数据。 本指南描述了如何使用 InfluxQL 自动化降采样数据和过期旧数据的过程。要使用 Flux 和 InfluxDB 2.0 对数据进行降采样和保留数据,请参阅 Process data with InfluxDB tasks

定义

  • 连续查询 (CQ) 是在数据库中自动和定期运行的 InfluxQL 查询。 CQs 需要在 SELECT 子句中包含一个函数,并且必须包括一个 GROUP BY time() 子句。

  • 保留策略 (RP) 是 InfluxDB 数据结构的一部分,用于描述 InfluxDB 保存数据的时间长度。 InfluxDB 将您的本地服务器时间戳与数据上的时间戳进行比较,并删除超过 RP 的 DURATION 的数据。 单个数据库可以有多个 RP,并且每个数据库的 RP 是唯一的。

本指南不详细介绍创建和管理CQ和RP或任务的语法。如果您对这些概念不熟悉,我们建议您查看以下内容:

示例数据

本节使用虚构的实时数据来跟踪通过电话和网站向餐厅下的食物订单数量,间隔为十秒。我们将这些数据存储在一个数据库中,称为food_data,在测量 orders中,以及在字段 phonewebsite中。

示例:

name: orders
------------
time                   phone   website
2016-05-10T23:18:00Z   10      30
2016-05-10T23:18:10Z   12      39
2016-05-10T23:18:20Z   11      56

目标

假设从长远来看,我们只对每30分钟通过电话和网站的平均订单数量感兴趣。 在接下来的步骤中,我们使用RPs和CQs来:

  • 自动将十秒分辨率数据聚合为三十分钟分辨率数据
  • 自动删除超过两小时的原始十秒分辨率数据
  • 自动删除超过52周的30分钟分辨率数据

数据库准备

我们在将数据写入数据库 food_data 之前执行以下步骤。 我们在插入任何数据 之前 执行此操作,因为 CQ 仅针对最近的数据运行;也就是说,数据的时间戳不早于 now() 减去 CQ 的 FOR 子句,或者 now() 减去 GROUP BY time() 的时间间隔,如果 CQ 没有 FOR 子句。

1. 创建数据库

> CREATE DATABASE "food_data"

2. 创建一个两小时的 DEFAULT 保留策略

如果我们在将数据点写入数据库时不提供明确的保留策略,则InfluxDB会写入DEFAULT保留策略。我们将DEFAULT保留策略的数据保存两小时,因为我们希望InfluxDB自动将每十秒接收的数据写入该保留策略。

使用CREATE RETENTION POLICY语句创建一个DEFAULT保留策略:

> CREATE RETENTION POLICY "two_hours" ON "food_data" DURATION 2h REPLICATION 1 DEFAULT

该查询创建了一个名为 two_hours 的规则模式,它存在于数据库 food_data 中。 two_hours 保留了持续时间为两个小时 (2h) 的数据,并且它是数据库 food_data 的默认规则模式。

复制因子 (REPLICATION 1) 是一个必需的参数,但对于单节点实例必须始终设置为 1。

注意: 当我们在步骤 1 中创建 food_data 数据库时,InfluxDB 自动生成了一个名为 autogen 的保留策略,并将其设置为该数据库的 DEFAULT 保留策略。 autogen 保留策略的保留期限是无限的。 通过上述查询,保留策略 two_hours 替代 autogen 成为 food_data 数据库的 DEFAULT 保留策略。

3. 创建52周的保留策略

接下来,我们想要创建另一个保留策略,该策略会保留数据52周,并且不是数据库的 DEFAULT 保留策略 (RP)。最终,这30分钟的汇总数据将存储在这个RP中。

使用CREATE RETENTION POLICY语句来创建一个非DEFAULT的保留策略:

> CREATE RETENTION POLICY "a_year" ON "food_data" DURATION 52w REPLICATION 1

该查询创建了一个名为 a_year 的保留策略 (RP),它存在于数据库 food_data 中。 a_year 设置将数据保留 DURATION 为 52 周 (52w)。 省略 DEFAULT 参数确保 a_year 不是数据库 food_dataDEFAULT RP。 也就是说,对 food_data 的写入和读取操作如果未指定 RP,将仍然会使用 two_hours RP (即 DEFAULT RP)。

4. 创建连续查询

现在我们已经设置好了我们的RP,我们想要创建一个连续查询(CQ),该查询将自动和定期地将十秒的分辨率数据降采样到三十分钟的分辨率,然后将这些结果存储在具有不同保留策略的不同测量中。

使用 CREATE CONTINUOUS QUERY 语句生成一个CQ:

> CREATE CONTINUOUS QUERY "cq_30m" ON "food_data" BEGIN
  SELECT mean("website") AS "mean_website",mean("phone") AS "mean_phone"
  INTO "a_year"."downsampled_orders"
  FROM "orders"
  GROUP BY time(30m)
END

该查询在数据库 food_data 中创建了一个名为 cq_30m 的 CQ。 cq_30m 告诉 InfluxDB 计算在测量 orders 中两个字段 websitephone 的 30 分钟平均值,并在 DEFAULT RP two_hours 中进行。它还告诉 InfluxDB 将这些结果写入在保留策略 a_year 中的测量 downsampled_orders,字段键为 mean_websitemean_phone。InfluxDB 将每 30 分钟执行一次此查询,查询过去 30 分钟的数据。

注意: 请注意我们在 INTO 子句中完全限定(即,我们使用语法 ""."")度量值。InfluxDB 要求这种语法才能将数据写入除 DEFAULT RP 以外的保留策略。

结果

随着新的CQ和两个新的RP,food_data 已经准备好开始接收数据。 在将数据写入我们的数据库并让其运行一段时间后,我们看到 两个测量值:ordersdownsampled_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:30Z    8      34
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
2016-05-13T17:00:00Z    4           23

orders中的数据是原始的、十秒分辨率的数据,存储在两个小时的RP中。
downsampled_orders中的数据是聚合的、三十分钟分辨率的数据,受52周RP的影响。

注意到 downsampled_orders 中的第一个时间戳早于 orders 中的第一个 时间戳。这是因为 InfluxDB 已经删除了 orders 中时间戳早于我们本地服务器时间戳减去两个小时的数据(假设我们在 2016-05-14T00:59:59Z 执行了 SELECT 查询)。InfluxDB 仅会在 52 周后开始删除 downsampled_orders 中的数据。

注意:

  • 注意我们在第二个 SELECT 语句中完全限定了 (也就是说,我们使用语法 ""."") downsampled_orders。我们必须在该查询中指定 RP,以从不同于 DEFAULT RP 的 RP 中 SELECT 数据。
  • 默认情况下,InfluxDB 每 30 分钟检查一次以强制执行保留策略(RP)。 在检查之间,orders 可能有超过两小时的数据。 InfluxDB 强制执行保留策略的检查频率是一个可配置的设置,详见 数据库配置

通过结合 RPs 和 CQs,我们成功地设置了数据库,以自动保留高精度原始数据一段有限的时间,创建低精度数据,并将这些低精度数据存储较长的时间。现在您对这些功能如何协同工作有了概括性的理解,请查看关于 CQsRPs 的详细文档,了解它们能为您做些什么。



Flux的未来

Flux 正在进入维护模式。您可以像现在一样继续使用它,而无需对您的代码进行任何更改。

阅读更多

InfluxDB 3 开源版本现已公开Alpha测试

InfluxDB 3 Open Source is now available for alpha testing, licensed under MIT or Apache 2 licensing.

我们将发布两个产品作为测试版的一部分。

InfluxDB 3 核心,是我们新的开源产品。 它是一个用于时间序列和事件数据的实时数据引擎。 InfluxDB 3 企业版是建立在核心基础之上的商业版本,增加了历史查询能力、读取副本、高可用性、可扩展性和细粒度安全性。

有关如何开始的更多信息,请查看: