如何解决TimescaleDB - 即使是少量数据,连续聚合刷新也需要很长时间
即使是少量数据,连续聚合刷新也需要很长时间
这是关于连续聚合和刷新。
我们运行了以下查询并记录了观察结果。
- 创建表并将其转换为具有适当主键和索引的超表。
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 秒
select count(*) from devices_data_summary_hourly -> 35065
- 接下来,我们将为一个设备 ID 添加数据,但每天只添加一个点,持续 4 年。
INSERT INTO devices_data
SELECT time,2,INTERVAL '1 day') AS time;
查询 o/p : INSERT 0 1462 查询在 555 毫秒内成功返回。
- 接下来,我们将观察刷新作业将这些点添加到每小时聚合视图所需的时间
刷新作业时间 -> 19.059796 秒
select count(*) from devices_data_summary_hourly -> 36527
简要观察:
第 3 步和第 4 步的输出:
添加到主超表的点数 -> 25246081
刷新作业时间以将这些点添加到 CAGG -> 19.078569 秒
积分添加到 CAGG -> 35065
第 5 步和第 6 步的输出:
添加到主超表的点数 -> 1462
刷新作业时间以将这些点添加到 CAGG -> 19.059796 秒
点数已添加到 CAGG -> 1462
结论:
通过观察第 3 步和第 4 步的输出,我们看到 CAGG 花费几乎相同的时间来计算聚合,即使数据量存在巨大差异。 这可能意味着,无论数据量如何,timescaledb 都会刷新跨越 4 年的整个数据集。
问题:
- 这是应该的吗?
- timescaledb 是否只考虑时间范围,不够智能,无法仅针对已更改的点重新计算聚合?
- 我们的数据库架构设计或任何其他导致这种行为的配置是否遗漏了什么?
解决方法
预期是您增量加载当前数据,而不是回溯数据。
它在您展示的测试中表现不佳并不奇怪。您使用的工具与其设计背道而驰。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。