ClickHouse集群查询慢及表结构设计相关技术咨询

问题1：集群查询随并发升高变慢的原因 #

• 数据分布与并行调度瓶颈：如果集群采用随机分片策略，可能存在单个分片的1小时数据量远高于其他节点的情况，查询时协调节点需要等待最慢的分片返回结果，并发升高后这种等待会被放大。另外，协调节点在分发请求、聚合分片结果时，高并发下自身的CPU、内存资源可能成为瓶颈。
• 资源过载：单并发时单节点能处理8G数据的扫描、过滤，但20并发下，集群节点的磁盘IO、CPU会被占满——机械磁盘的IOPS不足以支撑多并发下的大量数据扫描，CPU在解压、过滤日志数据时负载过高，直接导致响应延迟飙升。
• 连接池配置不合理：最大打开连接数设为1000，4个节点平均每个节点要承载250个连接，若节点的max_connections配置（默认通常为100）不足，会导致连接排队等待，甚至触发连接拒绝，拉高查询耗时。
• 索引利用不充分：当前ORDER BY以time为首字段，查询条件是type+time范围，虽然能利用主键过滤，但time是高基数字段，会让同type的数据分散在不同的数据块中，查询时需要扫描更多数据块，多并发下这种开销被放大。

问题2：表设计与ORDER BY顺序的合理性 #

• 当前表设计存在明显问题：ORDER BY字段顺序不符合ClickHouse的优化原则。ClickHouse的主键索引（由ORDER BY字段构成）性能依赖字段的基数顺序，低基数字段放在前面能让相同取值的数据连续存储，减少查询时的扫描范围。
• ORDER BY顺序需调整：应按字段基数从小到大排列：level（5种取值）→type（10种取值）→service（1000种）→instance→time→traceid。调整后，相同type、level的数据会连续存储，查询type='ingress'时能快速定位到对应数据块，大幅减少扫描量。
• 表创建正确性确认：集群表需采用Distributed引擎关联底层MergeTree（或ReplacingMergeTree，若日志无重复则用MergeTree），分区键设为日期/时间字段，同时需注意：
  • 底层表的ORDER BY要使用调整后的字段顺序
  • 设置合适的index_granularity（默认8192，若单条日志行较小可适当调大，比如16384）
  • 开启自适应索引（enable_adaptive_index=1，默认开启）

问题3：分区粒度的合理性 #

• 按天分区确实过于粗糙：单天数据量约2.6T，查询1小时数据时，仍需加载整个天分区的元数据，扫描该分区内所有包含目标时间范围的数据块，额外开销较大。
• 建议调整为按小时分区：单小时数据量8G，分区大小适中，查询时可直接定位到目标小时分区，无需扫描其他分区的数据，能显著降低IO扫描范围。同时，按小时分区的数量（每年8760个）在ClickHouse的承载范围内，不会引发元数据管理问题。
• 分区键可设置为toStartOfHour(time)或toYYYYMMDDhh(time)，确保分区按小时划分。

内容的提问来源于stack exchange，提问作者Ning Li