实时聚合不是最新的
Real-Time aggregation not up to date
我正在经历实时聚合,无法实时更新。有什么我想念的吗?
版本 2.4.2
使用当前 docker 图像的可重现示例 timescale/timescaledb:latest-pg12
:
CREATE TABLE data
(
time TIMESTAMPTZ NOT NULL,
value DOUBLE PRECISION NOT NULL
);
SELECT create_hypertable('data', 'time', chunk_time_interval => interval '1d');
INSERT INTO data (time, value)
VALUES ('2020-01-01', 100);
CREATE MATERIALIZED VIEW data_daily WITH (timescaledb.continuous)
AS
SELECT time_bucket('1 day', time) AS time,
avg(value) AS avg,
count(*) AS count
FROM data
GROUP BY 1;
ALTER MATERIALIZED VIEW data_daily SET (timescaledb.materialized_only = false);
现在当我 运行 SELECT * FROM data_daily
我得到了预期的结果:
time, avg, count
2020-01-01 00:00:00.000000, 100, 1
但是在插入另一个值并再次 运行 查询后,它不会更新。结果同上
INSERT INTO data (time, value) VALUES ('2020-01-01', 150);
SELECT * FROM data_daily;
输出:
time, avg, count
2020-01-01 00:00:00.000000, 100, 1
手动刷新然后再次查询会显示预期的结果。
CALL refresh_continuous_aggregate('data_daily', '1900-01-01', '2100-01-01');
SELECT * FROM data_daily;
输出:
time, avg, count
2020-01-01 00:00:00.000000, 125, 2
是否需要配置其他任何内容才能使实时聚合正常工作?
从 documentation 我了解到设置 materialized_only = false
应该足够了(甚至不需要,因为它是默认设置)。
作为参考,这是第二次插入之后和手动刷新之前的查询计划:
Append (cost=0.15..59.98 rows=400 width=24) (actual time=0.138..0.200 rows=1 loops=1)
-> GroupAggregate (cost=0.15..21.76 rows=200 width=24) (actual time=0.130..0.151 rows=1 loops=1)
Group Key: _materialized_hypertable_48."time"
-> Custom Scan (ChunkAppend) on _materialized_hypertable_48 (cost=0.15..16.81 rows=260 width=72) (actual time=0.021..0.046 rows=1 loops=1)
Order: _materialized_hypertable_48."time"
Chunks excluded during startup: 0
-> Index Scan Backward using _hyper_48_315_chunk__materialized_hypertable_48_time_idx on _hyper_48_315_chunk (cost=0.15..16.81 rows=260 width=72) (actual time=0.014..0.023 rows=1 loops=1)
Index Cond: ("time" < COALESCE(_timescaledb_internal.to_timestamp(_timescaledb_internal.cagg_watermark(48)), '-infinity'::timestamp with time zone))
-> GroupAggregate (cost=0.16..32.23 rows=200 width=24) (actual time=0.010..0.021 rows=0 loops=1)
Group Key: (time_bucket('1 day'::interval, data."time"))
-> Custom Scan (ChunkAppend) on data (cost=0.16..24.60 rows=617 width=16) (actual time=0.003..0.007 rows=0 loops=1)
Order: time_bucket('1 day'::interval, data."time")
Chunks excluded during startup: 1
Planning Time: 4.978 ms
Execution Time: 0.384 ms
这是一个很好的问题,它在连续聚合的工作方式中确实有点令人困惑。
实时视图仅适用于 尚未具体化的视图区域 ,不适用于 已具体化的区域具体化但现在失效。 这是出于性能原因的可预测性以及具体化和失效的工作方式。通常刷新 window 在小于 now()
的某个时间被调用,比如 now() - '1 hour'::interval
然后插入从 1 小时前开始,然后实时视图将直接 运行 查询在基础 table 上 在区域 now()-'1 hour'
-> now()
和 return 之前该区域的物化部分的结果。可能有很多无效的小区域,因此这些区域只会在下一个 运行 的物化作业中被拾取。您可以说这是数据的最终一致视图。
现在对你来说,我想说的是 运行 刷新过程不要太遥远,而是坚持过去,然后你会看到实时视图更有效你期望的方式。
我正在经历实时聚合,无法实时更新。有什么我想念的吗?
版本 2.4.2
使用当前 docker 图像的可重现示例 timescale/timescaledb:latest-pg12
:
CREATE TABLE data
(
time TIMESTAMPTZ NOT NULL,
value DOUBLE PRECISION NOT NULL
);
SELECT create_hypertable('data', 'time', chunk_time_interval => interval '1d');
INSERT INTO data (time, value)
VALUES ('2020-01-01', 100);
CREATE MATERIALIZED VIEW data_daily WITH (timescaledb.continuous)
AS
SELECT time_bucket('1 day', time) AS time,
avg(value) AS avg,
count(*) AS count
FROM data
GROUP BY 1;
ALTER MATERIALIZED VIEW data_daily SET (timescaledb.materialized_only = false);
现在当我 运行 SELECT * FROM data_daily
我得到了预期的结果:
time, avg, count
2020-01-01 00:00:00.000000, 100, 1
但是在插入另一个值并再次 运行 查询后,它不会更新。结果同上
INSERT INTO data (time, value) VALUES ('2020-01-01', 150);
SELECT * FROM data_daily;
输出:
time, avg, count
2020-01-01 00:00:00.000000, 100, 1
手动刷新然后再次查询会显示预期的结果。
CALL refresh_continuous_aggregate('data_daily', '1900-01-01', '2100-01-01');
SELECT * FROM data_daily;
输出:
time, avg, count
2020-01-01 00:00:00.000000, 125, 2
是否需要配置其他任何内容才能使实时聚合正常工作?
从 documentation 我了解到设置 materialized_only = false
应该足够了(甚至不需要,因为它是默认设置)。
作为参考,这是第二次插入之后和手动刷新之前的查询计划:
Append (cost=0.15..59.98 rows=400 width=24) (actual time=0.138..0.200 rows=1 loops=1)
-> GroupAggregate (cost=0.15..21.76 rows=200 width=24) (actual time=0.130..0.151 rows=1 loops=1)
Group Key: _materialized_hypertable_48."time"
-> Custom Scan (ChunkAppend) on _materialized_hypertable_48 (cost=0.15..16.81 rows=260 width=72) (actual time=0.021..0.046 rows=1 loops=1)
Order: _materialized_hypertable_48."time"
Chunks excluded during startup: 0
-> Index Scan Backward using _hyper_48_315_chunk__materialized_hypertable_48_time_idx on _hyper_48_315_chunk (cost=0.15..16.81 rows=260 width=72) (actual time=0.014..0.023 rows=1 loops=1)
Index Cond: ("time" < COALESCE(_timescaledb_internal.to_timestamp(_timescaledb_internal.cagg_watermark(48)), '-infinity'::timestamp with time zone))
-> GroupAggregate (cost=0.16..32.23 rows=200 width=24) (actual time=0.010..0.021 rows=0 loops=1)
Group Key: (time_bucket('1 day'::interval, data."time"))
-> Custom Scan (ChunkAppend) on data (cost=0.16..24.60 rows=617 width=16) (actual time=0.003..0.007 rows=0 loops=1)
Order: time_bucket('1 day'::interval, data."time")
Chunks excluded during startup: 1
Planning Time: 4.978 ms
Execution Time: 0.384 ms
这是一个很好的问题,它在连续聚合的工作方式中确实有点令人困惑。
实时视图仅适用于 尚未具体化的视图区域 ,不适用于 已具体化的区域具体化但现在失效。 这是出于性能原因的可预测性以及具体化和失效的工作方式。通常刷新 window 在小于 now()
的某个时间被调用,比如 now() - '1 hour'::interval
然后插入从 1 小时前开始,然后实时视图将直接 运行 查询在基础 table 上 在区域 now()-'1 hour'
-> now()
和 return 之前该区域的物化部分的结果。可能有很多无效的小区域,因此这些区域只会在下一个 运行 的物化作业中被拾取。您可以说这是数据的最终一致视图。
现在对你来说,我想说的是 运行 刷新过程不要太遥远,而是坚持过去,然后你会看到实时视图更有效你期望的方式。