IoT时序场景ClickHouse首次查询响应慢问题咨询

现存问题及优化方案 #

• 聚合计算冗余：你已经物化了date字段，查询时不需要对time字段调用toStartOfInterval计算日区间，直接GROUP BY date即可，减少运行时计算开销。优化后查询语句如下：

SELECT date AS agreg, avg(value) AS value
FROM feeds
WHERE uuid='391becbb-39fd-4205-aba1-5088c9529d42'
  AND ts > 1629378660000
  AND ts < 1632057060000
GROUP BY date
ORDER BY date ASC

• 缺少预聚合逻辑：目前使用的是普通ReplacingMergeTree，每次查询都要扫描原始数据做聚合，冷查时需要从磁盘读取大量原始数据，耗时自然偏高。针对这种按uuid+日维度聚合的高频查询，建议新增聚合物化视图提前预计算结果，查询时直接读取预计算好的小体积数据，冷查速度可以提升10倍以上。示例物化视图结构如下：

CREATE MATERIALIZED VIEW feeds_daily_agg
ENGINE = SummingMergeTree()
PARTITION BY toYYYYMM(date)
PRIMARY KEY (uuid, date)
ORDER BY (uuid, date)
AS SELECT
  uuid,
  date,
  count() AS cnt,
  sum(value) AS sum_value
FROM feeds
GROUP BY uuid, date;

查询时直接访问该视图，平均值通过sum_value/cnt计算即可。

• 字段类型冗余：value使用Decimal(30,5)精度过高，大部分IoT场景下Float64完全满足精度要求，替换后可以减少近一半的字段存储体积，降低IO耗时。如果对精度要求确实高，可以保留Decimal类型，但建议缩小精度范围，比如调整为Decimal(18,5)。
• 索引粒度适配问题：index_granularity=4096对于IoT单uuid时间序列的场景偏大，如果单设备每天数据点只有几千甚至更少，可以把index_granularity调整到1024或者512，提升索引定位的精准度，减少不必要的数据块扫描。
• 表引擎选型冗余：如果你的IoT场景没有数据去重需求，不需要用ReplacingMergeTree，换成普通MergeTree即可，减少后台合并的开销，同时查询性能也会有小幅提升。
• 冷缓存优化：如果业务对首次查询延迟要求高，可以配置ClickHouse的use_uncompressed_cache=1开启未压缩数据缓存，同时针对高频查询做定时预热，比如每小时跑一次全量高频uuid的日聚合查询，把对应数据加载到内存中，避免用户触发冷查。

内容的提问来源于stack exchange，提问作者Guillaume Caruso