即使数据量很小,连续聚合刷新也需要很长时间
这是关于连续聚合和刷新它。
我们运行了以下查询并记录了观察结果。
- 创建一个表并将其转换为具有适当主键和索引的超表
CREATE TABLE "devices_data"(
time TIMESTAMP WITHOUT TIME ZONE NOT NULL,
device_id INTEGER,
temperature DOUBLE PRECISION,
PRIMARY KEY(time, device_id)
);
SELECT create_hypertable('devices_data', 'time');
CREATE INDEX ON "devices_data"(device_id, time DESC);
- 创建连续聚合视图以聚合每小时数据并定义刷新策略
CREATE MATERIALIZED VIEW devices_data_summary_hourly
WITH (timescaledb.continuous) AS
SELECT device_id,
time_bucket(INTERVAL '1 hour', time) AS bucket,
AVG(temperature),
MAX(temperature),
MIN(temperature),
SUM(temperature),
COUNT(*)
FROM devices_data
GROUP BY device_id, bucket
WITH NO DATA;
SELECT add_continuous_aggregate_policy('devices_data_summary_hourly',
start_offset => NULL,
end_offset => INTERVAL '1 h',
schedule_interval => INTERVAL '1 minute');
- 接下来,我们将为特定设备id添加一些跨越4年的数据
INSERT INTO devices_data
SELECT time, 1, random()*50 + 10
FROM generate_series(TIMESTAMP '2017-03-01 00:00:00',
TIMESTAMP '2021-03-01 00:00:00',
INTERVAL '5 seconds') AS time;
查询o/p:INSERT 0 25246081查询在3分58秒内成功返回
- 接下来我们将观察刷新作业需要多少时间才能将这些点添加到每小时聚合视图中
刷新作业时间->19.078569秒
从devices_data_summary_hourly->中选择count(*(;35065
- 接下来,我们将为一个设备id添加数据,但在4年内每天只添加一个点
INSERT INTO devices_data
SELECT time, 2, random()*50 + 10
FROM generate_series(TIMESTAMP '2017-03-01 00:00:00',
TIMESTAMP '2021-03-01 00:00:00',
INTERVAL '1 day') AS time;
查询o/p:INSERT 0 1462查询在555毫秒内成功返回
- 接下来我们将观察刷新作业需要多少时间才能将这些点添加到每小时聚合视图中
刷新作业时间->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计算聚合所需的时间几乎相同,尽管数据量存在巨大差异。这可能意味着,无论数据量如何,时间刻度数据库都会刷新4年的整个数据集。
问题:
- 应该是这样吗
- 时间刻度数据库是否只考虑了时间范围,并且不够智能,无法仅为已更改的点重新计算聚合
- 我们的数据库模式设计或任何其他导致这种行为的配置中是否遗漏了什么
预期是增量加载当前数据,而不是过期数据。
它在你展示的测试中表现不佳并不奇怪。您使用的工具与设计相反。