数据降采样和保留

InfluxDB 每秒可以处理数十万个数据点。长期处理如此大量的数据可能会引起存储问题。一个自然的解决方案是对数据进行降采样；仅在有限的时间内保留高精度原始数据，并更长时间地存储较低精度、汇总的数据。本指南介绍了如何使用 InfluxQL 自动化降采样数据和过期旧数据的过程。要使用 Flux 和 InfluxDB 2.0 降采样和保留数据，请参阅使用 InfluxDB 任务处理数据。

定义

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

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

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

• CQ 文档和
• RP 文档.

示例数据

本节使用虚构的实时数据来跟踪通过电话和网站向餐厅订购食物的订单数量，时间间隔为十秒。我们将此数据存储在名为 food_data 的数据库或 bucket 中，在 measurement orders 中，以及在 字段 phone 和 website 中。

示例

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 分钟间隔的平均订单数量感兴趣。在接下来的步骤中，我们使用 RP 和 CQ 来

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

数据库准备

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

1. 创建数据库

> CREATE DATABASE "food_data"

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

如果我们在将点写入数据库时未提供显式 RP，则 InfluxDB 将写入 DEFAULT 保留策略。我们使 DEFAULT RP 将数据保留两个小时，因为我们希望 InfluxDB 自动将传入的十秒分辨率数据写入该 RP。

使用 CREATE RETENTION POLICY 语句创建 DEFAULT RP

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

该查询创建一个名为 two_hours 的 RP，它存在于数据库 food_data 中。two_hours 将数据保留 DURATION 两个小时 (2h)，并且它是数据库 food_data 的 DEFAULT RP。

注意： 当我们在步骤 1 中创建 food_data 数据库时，InfluxDB 自动生成了一个名为 autogen 的 RP，并将其设置为数据库的 DEFAULT RP。autogen RP 具有无限的保留期。使用上面的查询，RP two_hours 替换 autogen 作为 food_data 数据库的 DEFAULT RP。

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_data 的 DEFAULT RP。也就是说，针对 food_data 的写入和读取操作（未指定 RP）仍将转到 two_hours RP (DEFAULT RP)。

4. 创建连续查询

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

使用 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 计算 measurement orders 和 DEFAULT RP two_hours 中两个字段 website 和 phone 的 30 分钟平均值。它还告诉 InfluxDB 将这些结果写入保留策略 a_year 中的 measurement downsampled_orders，字段键为 mean_website 和 mean_phone。InfluxDB 将每 30 分钟为前 30 分钟运行此查询。

注意： 请注意，我们在 INTO 子句中完全限定了 measurement（即，我们使用语法 "<retention_policy>"."<measurement>"）。InfluxDB 需要该语法才能将数据写入 DEFAULT RP 以外的 RP。

结果

有了新的 CQ 和两个新的 RP，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: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 中的数据是聚合的 30 分钟分辨率数据，它们受 52 周 RP 的约束。

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

注释

• 请注意，我们在第二个 SELECT 语句中完全限定了 downsampled_orders（即，我们使用语法 "<retention_policy>"."<measurement>"）。我们必须在该查询中指定 RP 才能 SELECT 驻留在 DEFAULT RP 以外的 RP 中的数据。

• 默认情况下，InfluxDB 每 30 分钟检查一次以强制执行 RP。在检查之间，orders 可能具有早于两小时的数据。InfluxDB 检查以强制执行 RP 的速率是一个可配置的设置，请参阅数据库配置。

通过结合使用 RP 和 CQ，我们已成功设置我们的数据库，以自动将高精度原始数据保留有限的时间，创建较低精度的数据，并将较低精度的数据存储更长的时间。现在您已经大致了解了这些功能如何协同工作，请查看有关 CQ 和 RP 的详细文档，以了解它们可以为您做的所有事情。