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

Question

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

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

为了提高查询性能，我为 12 小时的情况设置了时间刻度的连续聚合视图，这大大缩短了查询时间，因为所有内容都已预先计算。我对 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

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

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

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

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

Selecting a continuous aggregate is slower than selecting raw data in timescaledb

postgresql

timescaledb