-
ClickHouse 23.8 广告归因平台 11 个 MV 同步写放大导致存储 24TB 涨到 67TB + P99 480ms 飙到 38 秒的 14 天复盘:Refreshable MV + AggregatingMergeTree + Projection 6 套修法 + 12 条 OLAP 工程纪律
2026 年 4 月,我们一组 ClickHouse 23.8 + Kafka Engine + 物化视图(MV)的实时数据平台(广告投放归因分析,日入仓事件 84 亿、SQL 查询日均 280 万、20 节点 3 副本集群)在一次业务方新增 11 个 MV 后遭遇了双重雪崩:存储从 24TB 在 14 天内涨到 67TB(同样的原始数据)、报表 P99 从 480ms 飙到 38 秒、Backg…- 7
- 0
-
ClickHouse 核心表 parts 飙到 47832 看板全线超时的 6 天复盘:四因素叠加根因 + buffer/分区/merge 三层治理 + 接入决策树
2026 年 1 月,ClickHouse 集群核心表 some_events 的 parts 数飙到 47832,BI 看板全线超时,简单 count 跑 8 秒,报表 30 秒不出来。6 天深度排查定位四因素叠加:单条 INSERT 让 part 生产 QPS 2000 + merge 默认保守跟不上 + 按小时分区让 merge 无法集中 + parts_to_throw 被业务方调到 50…- 5
- 0
-
ClickHouse 生产 3 年实战:日 5 亿日志 + 200ms 聚合 + Doris 对比
ES 跑日志 5 亿/天聚合 20s,换 ClickHouse 后 200ms,资源省一半。本文实录表引擎选型 + ORDER BY/分区设计 + LowCardinality + Buffer 表 + 物化视图 + MaterializedMySQL CDC + 集群配置,对比 Doris 实战经验。- 0
- 0
OLAP
幸运之星正在降临...
点击领取今天的签到奖励!
恭喜!您今天获得了{{mission.data.mission.credit}}积分
我的优惠劵
-
¥优惠劵使用时效:无法使用使用时效:
之前
使用时效:永久有效优惠劵ID:×
没有优惠劵可用!



