Continuous aggregates 只能在超表之上定义。您不能从另一个聚合定义或更改它。
我看到了两种使用当前版本的 TimescaleDB 2.2 实现所需功能的方法:
-
continuous aggregate policies 都在 7 天后实现数据。一个retention policy 在 1 周后删除原始数据,另一个保留策略在 30 天后删除第一个具有 1 小时存储桶的连续聚合中的数据。
- 第一个连续聚合策略在 7 天后实现,第二个在 30 天后实现。这意味着需要保留原始数据,直到第二个连续聚合具体化数据。因此,这两个保留政策都将在 30 天之后。虽然原始数据保留时间更长,但超表可以是compressed,以减少磁盘使用量。
这是可能的实现。
两种方法中的连续聚合将是相同的:
CREATE MATERIALIZED VIEW cagg_1h WITH (timescaledb.continuous) AS
SELECT time_bucket('1h', my_time_column), ...
FROM my_hypertable
WHERE ...
GROUP BY 1, ...;
CREATE MATERIALIZED VIEW cagg_1d WITH (timescaledb.continuous) AS
SELECT time_bucket('1d', my_time_column), ...
FROM my_hypertable
WHERE ...
GROUP BY 1, ...;
第一种方法的政策:
SELECT add_continuous_aggregate_policy('cagg_1h', INTERVAL '7d', INTERVAL '6d', INTERVAL '4h');
SELECT add_continuous_aggregate_policy('cagg_1d', INTERVAL '8d', INTERVAL '5d', INTERVAL '1h');
SELECT add_retention_policy('my_hypertable', INTERVAL '8d');
SELECT add_retention_policy('cagg_1h', INTERVAL '30d');
我尝试定义连续聚合的刷新窗口,即开始和结束偏移间隔,以及保留原始数据的间隔,以便在删除之前数据将在两个连续聚合中具体化。
对于第二种方法:
SELECT add_continuous_aggregate_policy('cagg_1h', INTERVAL '7d', INTERVAL '6d', INTERVAL '4h');
SELECT add_continuous_aggregate_policy('cagg_1d', INTERVAL '30d', INTERVAL '27d', INTERVAL '1d');
SELECT add_compression_policy('my_hypetable', INTERVAL '7d');
SELECT add_retention_policy('my_hypertable', INTERVAL '30d');
SELECT add_retention_policy('cagg_1h', INTERVAL '30d');
同样,连续聚合包含刷新窗口,因此数据将具体化到所需的时间间隔,并且不会被保留策略丢弃。
第二种方法包括一个压缩策略,假设 7 天后不会有更新到达原始数据,从问题描述来看似乎是正确的。
在添加压缩策略之前,必须通过altering the original hypertable 启用它。