即使是少量数据,连续聚合刷新也需要很长时间
这是关于持续聚合并刷新它。
我们运行了以下查询并记录了观察结果。
- 创建表并将其转换为具有适当主键和索引的超表。
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 需要几乎相同的时间来计算聚合,即使数据量存在巨大差异。这可能意味着,无论数据量如何,timescaledb 都会刷新跨越 4 年的整个数据集。
问题 :
- 这是应该的吗?
- timescaledb 是否只考虑时间范围并且不够智能以仅针对那些已更改的点重新计算聚合?
- 我们是否在我们的数据库架构设计或任何其他导致这种行为的配置中遗漏了什么?