Manticore Search 中通配符查询性能下降问题的分析与解决

问题背景

Manticore Search 是一款高性能的开源搜索引擎，在版本升级过程中，用户报告了一个关于通配符查询性能下降的问题。具体表现为：当索引使用两个或更多磁盘分片(disk chunks)时，执行包含通配符的查询速度明显下降，而相同查询在单个磁盘分片下执行速度正常。这个问题在6.2.12版本中并不存在，但在6.3.0版本中变得明显。

问题现象

通过实际测试数据可以清楚地看到性能差异：

• 在6.3.0版本中，对一个包含40万文档的索引执行match('77*')查询：

  • 当使用2个磁盘分片时，查询耗时2.06秒
  • 优化合并为1个磁盘分片后，相同查询仅需0.07秒

• 对比测试中更极端的案例：

  • 6.2.12版本：26个磁盘分片，1300万文档，查询耗时0.274秒
  • 6.3.0版本：26个磁盘分片，130万文档，查询耗时37.48秒

问题分析

经过深入调查，开发团队发现这个问题与6.3.0版本中默认启用的local_df(局部文档频率)功能有关。该功能原本是为了改进搜索结果相关性而引入的，它会：

1. 首先扩展查询中的通配符，获取所有匹配的术语
2. 然后从所有磁盘分片中收集这些术语的文档频率统计信息
3. 最后使用这些统计信息对每个磁盘分片执行查询

当查询中的通配符匹配大量术语时(如示例中的'77*'匹配了超过13万术语)，这种全局统计信息的收集过程会显著增加查询延迟，特别是在多个磁盘分片的情况下。

解决方案

开发团队提出了两种解决方案：

1. 代码修复：修改了local_df功能的实现，使其在处理通配符术语时跳过全局统计信息的收集。这意味着：

   • 通配符查询不再受local_df计算的影响
   • 其他非通配符术语仍能受益于local_df带来的相关性改进

2. 临时解决方案：在查询中添加option local_df=0参数，临时禁用该功能

技术影响与建议

这个问题的解决对Manticore Search用户有以下启示：

1. 版本升级注意事项：从6.2.x升级到6.3.x时，如果应用依赖通配符查询且索引使用多个磁盘分片，应特别关注查询性能变化

2. 索引设计考量：虽然合并磁盘分片可以解决这个问题，但不一定是长期解决方案，因为：

   • 大索引需要分片来管理内存使用
   • 频繁的OPTIMIZE操作会增加系统负载

3. 查询优化：对于性能关键的查询，可以考虑：

   • 使用更精确的查询条件减少通配符匹配范围
   • 在必要时使用option local_df=0参数

结论

Manticore Search团队快速响应并解决了这个性能退化问题，展示了开源社区的高效协作。这个案例也提醒我们，在搜索引擎这类复杂系统中，即使是旨在改进功能的变更，也可能在某些使用场景下产生意外的性能影响。通过深入的技术分析和针对性的修复，团队既保留了新功能的优势，又解决了特定场景下的性能问题。