持续查询幕后揭秘 - 第二部分

作者：Jimmy Guerrero / 产品
2015 年 11 月 10 日

导航至

在 InfluxDB 中，持续查询允许您预先计算和存储查询结果，以便在您需要时可以使用它们，而不会使数据库过载。在本系列的第一部分中，我们介绍了持续查询的基础知识及其用例。在这一部分中，我们将更进一步，了解持续查询如何在 InfluxDB 中执行。

那么，让我们开始吧...

持续查询执行服务

要执行查询（无论是否持续），数据库都需要有一个执行引擎。在 InfluxDB 内部，持续查询的执行由一个名为 Continuous querier 的后台服务在幕后处理。此服务模拟了您坐在键盘前并持续执行查询的体验。querier 服务由数据库引擎启动，并等待创建持续查询。

可以使用 CREATE CONTINUOUS QUERY 语句创建持续查询。在存储持续查询之前，会对其进行解析和语法验证，以确保它是有效的持续查询。如果一切顺利，与查询关联的元数据将存储在集群范围的数据库元存储中，集群中的所有服务器都可以访问该元存储。

调度持续查询执行

为了执行持续查询，querier 服务循环遍历所有数据库，从元存储中读取持续查询，并逐个检查它们是否需要执行。querier 服务每秒重复此操作一次。

一旦 querier 服务找到要执行的持续查询，它会根据查询中指定的 group by 时间间隔，计算出查询的执行频率。

首先，使用以下公式估算执行间隔 -

computeEvery = (group-by-time/ compute-runs-per-interval)

用户在查询中指定的 group by 时间间隔，除以 compute-runs-per-interval，这是计算当前和先前时间间隔的次数。默认情况下，compute-runs-per-interval 的值配置为 10。

例如，如下所示，如果我们有一个持续查询，其 group by 时间间隔为 10m，compute-runs-per-interval 设置为 10，compute-no-more-than 设置为 1m。

cq_example_1

查询将每分钟计算一次，并且在 10m 查询时间间隔内将有 10 次运行。

接下来，如果计算出的执行间隔比 配置（compute-no-more-than）中指定的最大频率更频繁，则执行间隔将被最大频率值覆盖。在持续查询的 group by 时间间隔短于 compute-no-more-than 设置的情况下，将使用 recompute-previous-n 设置。

例如，如下所示，如果我们有一个持续查询，其 group by 时间间隔为 5m，compute-runs-per-interval 设置为 10，compute-no-more-than 设置为 1m。

cq_example_2

查询将每分钟计算一次（而不是每 1?2 分钟），并且在 5m 查询时间间隔内将有 5 次运行。

验证、运行和写入结果

创建持续查询时，将从查询的 into 子句中提取 measurement 和 retention policy 并进行验证。验证后，运行查询，并将输出结果写入磁盘上指定的 measurement 中。如果未为 measurement 指定 retention policy，则将 measurement 写入数据库的默认 retention policy 中。

使用持续查询，InfluxDB 会自动重新计算先前的时间间隔，以防延迟数据到达。这在您可能具有延迟的数据流或正在写入历史数据的情况下非常有用。在第一次运行-写入通过后，执行服务会重新执行持续查询，以针对最近经过的时间段，直到配置设置 (recompute-no-older-than) 中指定的最大时间间隔设置。通常，此设置必须至少与到达的最不同步的时间戳一样旧，否则数据将不会成为下采样的组成部分。

结论

今天，我们介绍了持续查询如何在 InfluxDB 内部执行。请继续关注我们持续查询博客系列的最后一部分（第三部分），以了解如何监控和排除持续查询的故障。

grafana

在那之前，我们邀请您免费试用 14 天托管的 InfluxDB + Grafana，并希望您开始将 InfluxDB 用于您的应用程序。