Apache Solr 8.8开启bf参数查询性能骤降问题咨询

首先可以明确：该性能问题和AWS基础设施无关，你在原有非AWS环境部署Solr 8.8可复现问题已经验证了这一点，核心诱因是Solr 6.x到8.x的组件逻辑变更，叠加你使用的函数查询本身的性能缺陷：

• Group组件函数计算逻辑变更：Solr 7.0版本重构了Group模块的评分与函数值计算流程，6.6版本中bf参数携带的函数只会对每个分组内最终返回的Top N文档计算，而8.x版本默认会对查询命中的所有文档全量计算bf函数值后，再执行分组聚合。你的bf表达式中使用了scale()函数，该函数本身就需要遍历所有命中文档、读取对应字段值统计最小/最大值才能完成归一化计算，两个逻辑叠加直接让计算量提升了两个数量级。
• bf表达式存在冗余计算：你当前使用的表达式中多处乘1、乘0的逻辑完全无效：product(x,1)等价于x本身，product(sale_products_i,0)永远返回0，冗余的函数嵌套会额外增加函数解析、执行的栈调用开销，进一步放大耗时。
• 字段配置缺失放大开销：如果bf中引用的几个数值字段没有开启docValues，函数查询时会走倒排索引的字段缓存读取字段值，相比docValues的列式存储读取效率低一个数量级，在全量文档遍历计算的场景下，这个开销会被急剧放大。

按改造成本从低到高排序，可逐步落地验证：

• 第一时间清理bf表达式的冗余逻辑，简化后表达式为：

  product(bi_color_family_size_weighted_sku_availability_ratio, sum(product(scale(analytics_revenue,0.1,2),1.3), product(outlet_products_i,-0.15)))
  

  这一步无业务侵入，可降低10%左右的函数执行开销。
• 替换性能极差的scale()函数，这是核心优化点：scale()需要动态遍历全量命中文档统计最值，大结果集下必然出现性能瓶颈，不要在查询时动态做归一化计算：
  • 最优方案：通过离线/近线任务提前计算好analytics_revenue映射到0.1-2区间的归一化值，写入独立的数值字段（如analytics_revenue_scaled）并开启docValues，查询时直接引用预计算字段，bf可进一步简化为product(bi_color_family_size_weighted_sku_availability_ratio, sum(product(analytics_revenue_scaled,1.3), product(outlet_products_i,-0.15)))，优化后QTime可回落至和关闭bf参数同一量级。
  • 轻量方案：如果不想改动索引结构，可基于历史统计的analytics_revenue全局最小、最大值，手动写线性归一化逻辑替换scale()，比如已知字段最小值为minRev、最大值为maxRev，归一化逻辑写为sum(0.1, product(1.9, div(sub(analytics_revenue, minRev), sub(maxRev, minRev))))，避免Solr动态遍历文档统计最值。
• 检查字段配置：确认bf中引用的bi_color_family_size_weighted_sku_availability_ratio、analytics_revenue、outlet_products_i三个字段在schema中配置了docValues="true"，如果未开启，重建索引后字段读取效率会有明显提升。
• 临时兼容方案：如果短期无法完成上述改造，可在请求参数中追加group.func.score.mode=top，将Group组件的函数计算逻辑回退到6.6版本的模式，仅对每个分组内返回的Top文档计算bf函数值，注意该模式下bf的排序结果和默认全量计算模式存在差异，需要提前评估业务是否可接受。
• 缓存配置优化：如果查询重复度较高，可在solrconfig.xml中开启functionQueryCache，对相同表达式的函数计算结果做缓存，进一步降低重复查询的耗时。

内容的提问来源于stack exchange，提问作者Juan Fernando Molina