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

问题描述

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

有多种基于时间的查询来分析数据，例如在数据的12h切片上绘制图形或选择最后5m的汇总状态。

为了提高查询性能，我为12h情况设置了时标的连续聚合视图，这大大缩短了查询时间，因为所有内容都已预先计算。我尝试对较小的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毫秒。我怀疑我以某种方式使用了错误或间隔太短，因为它在12h示例中表现良好，但是我找不到原因。

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

解决方法

您的猜测是正确的，因为在连续聚合上观察到的查询执行缓慢是由于间隔太小所致。连续骨料的物化存储部分，然后将其用于计算最终骨料。这需要时间和空间。因此，连续聚合具有较大的间隔优势，并且以较小的间隔直接对超表执行聚合查询更为有效。

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

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