经验总结 - materialized views

本指南是社区交流会经验总结系列的一部分。想了解更多真实场景中的解决方案和洞见，可按具体问题浏览。 数据库是否被过多的 parts 拖慢了？请参阅 parts 过多 社区经验指南。 进一步了解 Materialized Views。

真实的生产环境问题： “我们有一个 materialized view。原始日志表大约有 20 GB，但基于这张日志表的视图却膨胀到了 190 GB，几乎是原始表的 10 倍。出现这种情况，是因为我们为每个属性都创建了一行，而每条日志可能有 10 个属性。”

规则： 如果你的 GROUP BY 生成的行数比它消除的还多，那你构建的就是一个代价高昂的索引，而不是 materialized view。

此查询可帮助你在创建 materialized view 之前，预测它究竟会压缩数据，还是会导致数据膨胀。请针对实际的表和列运行此查询，以避免出现“190GB 膨胀”这种情况。

它会显示：

• 低聚合率 (<10%) = 好的 MV，可显著压缩数据
• 高聚合率 (>70%) = 差的 MV，存在存储膨胀风险
• 存储倍数 = 你的 MV 最终会变大或变小多少

-- 替换为您的实际表和列
SELECT 
    count() as total_rows,
    uniq(your_group_by_columns) as unique_combinations,
    round(uniq(your_group_by_columns) / count() * 100, 2) as aggregation_ratio
FROM your_table
WHERE your_filter_conditions;

-- 如果 aggregation_ratio > 70%，请重新考虑物化视图的设计
-- 如果 aggregation_ratio < 10%，可获得良好的压缩效果

需要监控的预警信号：

• 插入延迟升高 (原本耗时 10ms 的查询现在需要 100ms 以上)
• “parts 过多”错误出现得越来越频繁
• 插入操作期间 CPU 使用率飙升
• 此前未出现过的插入超时

你可以使用 system.query_log 跟踪查询耗时趋势，对比添加 MV 前后的插入性能。

• ClickHouse at CommonRoom - Kirill Sapchuk - “过度热衷于 materialized views”和“20GB→190GB 爆炸式增长”案例的来源