选择连续聚合比在 timescaledb 中选择原始数据慢

Question

在我的数据库（Postgresql 12；timescaleDB 1.7.0）中有多个指标表，每分钟包含一行和设备。它包含一个 deviceId、时间、四个双精度数和一个枚举值。

有不同的基于时间的查询来分析数据，例如在数据的 12h 切片上绘制图表或选择最后 5m 的聚合状态。

为了提高查询性能，我为 12 小时的情况设置了 timescale 的连续聚合视图，这大大缩短了查询时间，因为一切都是预先计算的。我对 5m 的小得多的切片尝试了相同的操作，期望得到改进，因为每个查询的数据会小得多，尽管不像 12h 示例中那样剧烈。 令人惊讶的是，情况恰恰相反。选择原始数据现在比选择我不太了解的聚合视图快得多。

这是我的观点的定义：

CREATE VIEW metric_5m
            WITH ( timescaledb.continuous,
            timescaledb.refresh_interval = '5 minutes' )
AS
SELECT device,
       time_bucket('5 minutes', time)   as "time_bucket",
       max(metric.maximum) as "maximum",
       min(metric.minimum) as "minimum",
       avg(metric.average) as "average",
       avg(metric.sd)      as "sd"
FROM metric
GROUP BY time_bucket, device;

选择原始数据（在我的测试设置中约为 360 万行）大约需要 300 毫秒，而选择视图大约需要 3500 毫秒。我怀疑我以某种方式使用错误或间隔太小，因为它在 12 小时示例中表现得非常好，但我找不到原因。

因此，感谢您对此提供的所有帮助！

Answer 1

您的猜测是正确的，在连续聚合上观察到的缓慢查询执行是由于间隔太小造成的。连续聚合的具体化存储部分，然后用于计算最终聚合。这需要空间和时间。因此，连续聚合在更大的间隔下具有显着优势，并且在小间隔内直接对超表执行聚合查询效率更高。

我不知道有人研究过如何在连续聚合得到回报时估计分组间隔。我希望它取决于聚合的数量、聚合中的数据类型和聚合类型，因为不同的聚合会有不同的部分。例如，avg 需要比sum 或count 更多的部分信息。 This blogpost 提供了一些关于连续聚合的详细信息以及它们如何通过部分实现。

您可以尝试查看compression 是否有助于提高性能，因为它会减少从磁盘读取的数据量，并且可以按分组列组织压缩数据。