Recipe：Non-additivity

• 官方来源：examples/recipes/non-additivity
• 核对日期：2026-05-22

这个示例解决什么问题

为什么有些指标即使定义了 pre-aggregation，也不一定总能命中；以及如何通过重构指标让预聚合更可用。

官方示例的核心做法

示例定义了几个典型的非可加性或难匹配指标：

• countDistinct
• avg
• p90Age

并给出一个重构版 UsersRefactored：

• 将 avgAge 改写为 ageSum / count
• 把 ageSum 与 count 作为更基础、可加性的 measures

这说明了什么

1. 不是所有指标都天然适合 rollup

例如：

• avg
• percentile
• 精确 distinct

这些指标在预聚合匹配时天然更复杂。

2. 预聚合设计和指标设计是联动的

如果你希望高频查询命中率更高，就不只是“多建几个 rollup”，还可能要：

• 重新拆分 measure；
• 用更基础的 additive measures 重组复杂指标；
• 在精度和性能之间做平衡。

3. 建模重构比盲目加缓存更重要

这个示例特别适合用来教育团队：

性能问题不总是部署问题，很多时候是建模问题。

适合迁移的业务场景

• 平均客单价
• 平均响应时间
• 去重用户数
• 高分位数延迟指标

实战建议

• 高频分析先优先使用 additive measures 设计；
• 对 avg 类指标优先考虑拆成 sum / count；
• 对 distinct 与 percentile，提前评估精度、成本与延迟；
• 用真实查询模式观察是否命中预聚合。

和教程哪章搭配最好

• 核心概念
• 预聚合

一句话总结

这个 recipe 的核心价值是：预聚合命中率不仅取决于缓存配置，更取决于你是否把复杂指标拆成更适合聚合的语义结构。