问题标签 [continuous-aggregates]

我正在尝试使用 TimescaleDB 扩展来计算一些连续聚合。我有这个工作正常的查询：

当我尝试将其放在连续聚合物化视图中时，出现错误：

我得到的错误是：

TimescaleDB 是否允许按时间窗口在分区上进行连续聚合？

我在 PostgreSQL 12.5 上使用 TimescaleDB 2.1。

即使是少量数据，连续聚合刷新也需要很长时间

这是关于持续聚合并刷新它。

我们运行了以下查询并记录了观察结果。

1. 创建表并将其转换为具有适当主键和索引的超表。

2. 创建连续聚合视图以聚合每小时数据并定义刷新策略。

3. 接下来，我们将为特定设备 ID 添加一些跨越 4 年的数据。

查询 o/p : INSERT 0 25246081 查询在 3 分 58 秒内成功返回。

4. 接下来我们将观察刷新作业需要多长时间才能将这些点添加到每小时聚合视图中

刷新作业时间 -> 19.078569 秒

从 devices_data_summary_hourly 中选择 count(*) -> 35065

5. 接下来，我们将为一个设备 ID 添加数据，但每天只添加一个点，持续 4 年。

查询 o/p : INSERT 0 1462 查询在 555 毫秒内成功返回。

6. 接下来我们将观察刷新作业需要多长时间才能将这些点添加到每小时聚合视图中

刷新作业时间 -> 19.059796 秒

从 devices_data_summary_hourly 中选择 count(*) -> 36527

简要观察：

第 3 步和第 4 步的输出：

添加到主超表的点-> 25246081

刷新作业时间以将这些点添加到 CAGG -> 19.078569 秒

添加到 CAGG 的点数 -> 35065

第 5 步和第 6 步的输出：

添加到主超表的点-> 1462

刷新作业时间以将这些点添加到 CAGG -> 19.059796 秒

加到 CAGG 的点数 -> 1462

结论 ：

通过观察第 3 步和第 4 步的输出，我们看到 CAGG 需要几乎相同的时间来计算聚合，即使数据量存在巨大差异。这可能意味着，无论数据量如何，timescaledb 都会刷新跨越 4 年的整个数据集。

问题 ：

1. 这是应该的吗？
2. timescaledb 是否只考虑时间范围并且不够智能以仅针对那些已更改的点重新计算聚合？
3. 我们是否在我们的数据库架构设计或任何其他导致这种行为的配置中遗漏了什么？

我的 Postgres 数据库中有几个时间序列数据表，我最近将其转换为TimescaleDB hypertables。我有一个巨大的物化视图，但需要很长时间才能令人耳目一新。出于这个原因，我想使用 TimescaleDB Continuous Aggregates。不幸的是，这给出了一个错误消息：

错误：在 SELECT 查询中只允许 1 个超表用于连续聚合

因此，我计划通过简单地创建一个新表并每 10 分钟左右计算/附加新记录来构建自己的连续聚合。一位同事建议，也许时间尺度的人有充分的理由不允许来自多个超表的连续聚合，但我只是不明白它可能是什么。

我在他们的 github 页面上创建了一个关于它的问题，但目前我还没有得到任何回复。所以在我开始构建我自己的持续聚合之前，我想我会问你们来自 stackoverflow 的聪明人。

有谁知道 TimescaleDB 的人们不允许来自多个超表的连续聚合的原因是什么？在自己构建类似的东西时，你会看到什么挑战？

我是 TimeScaleDB 的新手，我创建了一个连续的聚合视图

我为此视图创建了刷新策略：

即使将结束偏移量设置为 1 小时后，我也会获得最新添加的数据。

刷新日志：

但是物化视图包含结束偏移之外的数据，虽然开始偏移设置工作正常

以下是物化视图中的数据： 物化视图

编辑：此外，我什至在政策刷新之前就获得了最新数据。

我创建了一个超表 water_meter 来存储传感器数据

它包含以下按时间戳升序排列的数据

可以看出我的数据从01 May 2020

如果我使用 time_bucket() 函数来获取每 1 天的聚合：

它工作正常，我得到以下数据：

现在，如果我使用它来获取 15 天的聚合，我会得到意想不到的结果，其中显示了 的开始时间段17 April 2020，而表中没有数据

我有以下要优化的 timescaleDB 查询

我的问题是：

• 由于我将来需要更多的职位，而且这个查询会越来越大，是否可以通过使用连续聚合和物化视图来优化它？
• 如果是：这会是什么样子？
• 如果没有：还有其他更好的选择吗？

更详细的解释说明：

我是数据库的新手，尤其是 timescaleDB，并且有一个带有以下场景的小传感器项目：

我有一个返回消耗值的传感器。由于传感器的一些技术限制（大值导致传感器在零点重新启动时溢出），我只存储传感器当前捕获和上次捕获之间的差异（sensor_delta）。此值仅在我插入它的那天有效。但是我可以通过将最新值除以之前消耗值的天数来用有效值填充两个消耗值之间的天数。

还有其他基于时间的数据连接到传感器，但由我自己捕获和存储（pos0_value、pos1_price、pos2_price）。这些是由于不同事件而在不同时间发生变化的值，它们从我插入该值到我插入一个新值都有效。所有这些数据对于我需要的计算都很重要。

所以，这是一大堆胡言乱语。为了更好地理解，这是我拥有的简单数据：

实际数据：

我想要对这些数据执行以下操作：

• 计算从最新到上一个条目的每日 sensor_delta (sensor_delta _new )
• 获取查询日期或时间范围的有效值
• 根据每天记录的数据计算新数据

我需要的日期：

• calcval1_daily = sensor_delta_daily*pos1_daily+pos0_daily
• calcval2_daily = sensor_delta_daily+pos2_daily+calcval1_daily

插入下一个 sensor_delta 后，sensor_delta_daily 应该更新到 2021-07-01。

我知道，这很多。我也掌握了这种情况，到目前为止我想出的唯一解决方案是上面提到的查询，它返回了我想要的数据集（我省略了 pos2_value 和 calcval2_daily）。但是我拥有的数据位置越多，Query 堆积的越多，我感觉 Query 变得非常大、不可读且速度慢。

您对如何解决这种情况有任何想法吗？

想象一下，您必须显示一段时间内基于城市的降雨量信息。

您有表格，提供有关特定城市每小时降雨量的详细信息。有一个端点返回请求的时间范围/城市的平均降雨量。

（所以想象一个名为rainbow_california、rainbow_texas等的表......我意识到这个模式对于降雨来说并不理想，但以它为例。）

因此，我没有计算每个请求的平均值，而是设置了一个连续聚合来将平均值计算到一个新视图中，并制定了一个每小时刷新最后一小时数据的策略。

ca_texas_rainfall_1_day ca_texas_rainfall_7_day ca_texas_rainfall_30_day ca_california_rainfall_1_day ca_california_rainfall_7_day ca_california_rainfall_30_day

这很好用而且速度非常快，但我对设置它的最佳方式有点困惑。我应该对每个连续聚合和每个城市有不同的看法吗？这不会导致大量不同的观点吗？还是应该将每个表的平均值合并到一个视图中？

我对创建物化视图的理解WITH NO DATA是，在我或我设置的策略刷新视图之前不会加载任何记录。但是，当使用 timescaledb 并提供此选项时，我可以立即查询表，并且似乎正在加载记录。

我正在关注这些文档：https ://docs.timescale.com/timescaledb/latest/how-to-guides/continuous-aggregate/create-a-continuous-aggregate/#create-a-continuous-aggregate

By default, views are automatically refreshed. You can adjust this by setting the WITH NO DATA option.

timescaledb_view然而，无论我运行了什么查询，当访问它时，它似乎都焕然一新。我是否误解了这应该如何工作？

拥有几百万行的超表。我可以使用以下方法选择它的大小：

SELECT pg_size_pretty( pg_total_relation_size('towns') );

我也有该超表的连续聚合：

我刷新了视图，数据按预期显示。但是，我似乎无法弄清楚这个新视图占用了多少空间。

SELECT pg_size_pretty( pg_total_relation_size('towns_income') );返回 0 个字节，我知道这是不正确的。我认为total_relation_sizetowns可能会增加，但这似乎也是一样的。我错过了什么吗？我也尝试过hypertable_size但没有成功，因为 mv 在技术上不是超表。

我正在尝试使用每天刷新一次视图的策略在超表上创建一个连续的聚合视图。

当我创建视图时它第一次运行很流畅，在 Grafana 上一切看起来都很好。然而，几天后，我发现后台作业大多失败，因此只汇总了部分数据。我试图通过使用以下查询来查找发生了什么，但仍然完全不知道为什么作业失败了！

我得到的只是

所以我尝试刷新那些丢失的桶的视图。该命令在几毫秒内完成，并说视图已经是最新的，但事实并非如此！那些部分聚合的存储桶根本没有更新。

总之，我有两个问题：

1. 我在哪里可以找到有关后台作业失败原因的更多信息？

2. 为什么refresh_continuous_aggregate没有刷新数据？

创建连续聚合和策略的脚本