作者来自 Elastic Benjamin Trent 及 Chris Hegarty2025 年是 Apache Lucene 非常出色的一年以下是我们的亮点。想获得 Elastic 认证吗了解下一期 Elasticsearch Engineer 培训什么时候开始你现在可以开始免费的 cloud 试用或者在本地机器上试用 Elastic。很难相信 Apache Lucene 已经存在了超过四分之一个世纪是的通过 Apache Lucene 实现的搜索已经超过 25 年。社区数据一览在贡献和整个社区方面2025 年又是强劲的一年共有 1,756 次 commits 和 1,080 个 pull requests来自 134 位独立贡献者。社区在今年继续增长贡献者数量比上一年增加了 98 人。项目管理委员会 project management committee - PMC 和 committer 群体也在扩大。Apache Lucene 在 2025 年新增了 9 位 committers其中一位是 Elastic 自家的 Simon Cooper。祝贺 thecoopPMC 也迎来了 2 位新成员。我们这个小社区还在不断成长。我们的亮点接近 2,000 次 commits 和 8 个版本发布让人很难总结我们在 2025 年 Apache Lucene 中喜欢的所有内容。但不回避挑战这里是我们的一些亮点。更快查询的一年在很多方面2025 年是 Apache Lucene 拥抱更好自动向量化、手动 SIMD 优化并整体让性能更快的一年。Lucene 社区成员 Adrien Grand 在这篇博客中做了非常详细的讲解下面是一些带来最大提升的链接和总结。像往常一样特别感谢 Mike McCandless 多年来维护 Apache Lucene 基准。[IN] 重构 main top-n bulk scorers以更偏向 term-at-a-time 的方式评估 hits[IS] 无关的硬件更新所以这里只是噪声[IY] 使用无分支方式加速 filterCompetitiveHits[IZ] 改进以 bitsets 存储的文档收集[JA] 使用 Java Panama API 手动向量化 filterCompetitiveHits[JK] 将文档块大小提升到 256不考虑硬件变化 [IS]这在 2025 年几乎带来了 60% 的查询速度提升从 100 qps 提升到 170 qps。向量搜索2025 年在向量搜索方面有不少改进。其中值得重点一提的有三项通过 ACORN 改进带过滤条件的向量搜索、加入乐观的多段 multisegment 搜索以及向量的批量打分 bulk scoring 。ACORN-1 是一种用于基于图的向量索引的有趣算法。它的一个重要优势是对过滤条件和算法本身都不敏感。由于 Apache Lucene 使用分层可导航小世界 HNSW 进行索引而用户通常希望在无需额外配置的情况下对任何条件进行过滤因此它非常契合。最初是一位社区成员研究并尝试引入该算法。他后来加入了 Elastic 。嗨 Ben最终为 Lucene 找到了一个很好的平衡点在不要求用户进行大量配置、也不需要额外索引信息的前提下实现了更快的过滤向量搜索。向 Apache Lucene 中加入乐观的多段向量搜索充分体现了社区如何协作完成这些工作。三位不同的成员通力合作对该方案进行了调试、基准测试、设计和多轮迭代。这个方案最初由 Michael Sokolov Lucene 社区中的向量搜索明星提出它立刻吸引了我的注意因为它声称可以在不牺牲性能的情况下修复我们一个奇怪的并发一致性 bug 。在社区成员 Dzung Bui 的多次迭代和基准测试之后我们在速度和召回率之间找到了合适的平衡既提升了性能又让多线程搜索保持一致性并实现了一个相当巧妙的算法。批量打分 bulk scoring 源自社区成员 Trevor McCulloch 与我们自己的 Chris Hegarty 的合作并在 PR #14978 中作为一种新的打分接口引入随后在 PR #14980 中提供了最初的 float32 实现。现代向量搜索通常需要在索引中将一个查询向量与成千上万甚至数百万个向量进行比较往往是通过遍历最近邻图来完成的。传统方式是一次只比较一个向量。而批量打分则反转了这一模型在一次调用中将一批向量以索引中的序号表示传递给打分器。这样可以让打分器在多个向量之间进行预取和流水线处理摊薄缓存未命中的成本并减少单个向量的额外开销。原始设计讨论中一个令人兴奋的点是设想使用 Rust 和 C 来实现批量打分器。虽然 Lucene 本身仍然是一个 Java 库但这为高度优化、 SIMD 友好的原生实现打开了大门。我们甚至还没来得及讨论该领域中落地的其他多项改进包括 HNSW 的优化例如更紧凑的 GroupVarInt 图编码、对极小段跳过图构建以及持续降低内存占用。在运维层面 Lucene 现在暴露了堆外内存需求使得理解和调试原生内存使用变得更加容易。虽然这些改动单独来看都不算大但合在一起它们让 Lucene 的向量搜索在生产环境中变得更快、更轻量也更易于运维。额外福利最后一个亮点可能显得有些突兀。这是一个处理过程极其令人沮丧、但解决后又让人倍感成就的 Bug。我在这里就不展开技术细节了因为这涉及到 Lucene 如何进行最大评分max scoring和批量评分bulk scoring、如何应用过滤器以及它如何处理所有内部迭代器的状态 —— 这足以专门写一篇博客。简而言之我们在 2025 年 9 月底的生产环境中遇到了这个 Bug。它表现为在执行特定查询时抛出EndOfFileException。接着就像所有 “有趣” 的 Bug 一样我们花了一两周的时间才成功复现并完成调试。最后当我们终于搞清楚是什么原因导致了异常还得深入研究背后的原理才能修复它。总之整整一个月的工作量最后浓缩成了一行代码。请感受它的荣光- top.doc top.approximation.advance(filter.doc); // Must use the iterator as top might be a two-phase iterator top.doc top.iterator.advance(filter.doc);再见 2025你好 2026衷心感谢 Apache Lucene 社区中每一位不懈努力、持续改进这一经典搜索库的成员。我们 ❤️ 你们。原文https://www.elastic.co/search-labs/blog/apache-lucene-wrapped-2025