ted*_*ddy 19 lucene algorithm indexing information-retrieval inverted-index
我读过Doug Cutting的论文; " 总排名的空间优化 ".
由于它是很久以前写的,我想知道lucene使用什么算法(关于帖子列表遍历和分数计算,排名).
特别是,那里描述的总排名算法涉及遍历每个查询词的整个帖子列表,因此在非常常见的查询词如"黄狗"的情况下,2个词中的任何一个可能具有非常长的帖子列表,如果是网络搜索.它们是否真的遍及当前的Lucene/Solr？或者是否有任何启发式方法来截断所使用的列表？
在只返回前k个结果的情况下,我可以理解,在多个机器上分发发布列表,然后组合每个机器的top-k可以工作,但是如果我们需要返回"第100个结果页面",即结果排名从990-1000,然后每个分区仍然必须找出前1000,所以分区将没有多大帮助.
总的来说,有没有关于Lucene使用的内部算法的最新详细文档？
jpo*_*ntz 30
我不知道这样的文档,但由于Lucene是开源的,我鼓励你去阅读源代码.特别是,当前的主干版本包括灵活的索引,这意味着存储和发布列表遍历已经与其余代码分离,从而可以编写自定义编解码器.
关于发布列表遍历,您的假设是正确的(默认情况下(取决于您的Scorer实现)Lucene遍历查询中存在的每个术语的整个发布列表,并将匹配文档放入大小为k的堆中以计算top-k文档(见TopDocsCollector).因此,将结果从990返回到1000会使Lucene实例化一个大小为1000的堆.如果按文档对索引进行分区(另一种方法可能是按术语分割),则每个分片都需要将前1000个结果发送到服务器,即负责合并结果(例如,参见Solr QueryComponent,它将查询从N转换为P> N到几个从0到P的碎片请求sreq.params.set(CommonParams.START, "0");).这就是为什么在极端分页的情况下,Solr在分布式模式下可能比在独立模式下慢.
我不知道Google如何有效地为结果评分,但是Twitter发布了一篇关于他们的检索引擎Earlybird的论文,他们解释了他们如何修补Lucene以便对帖子列表进行有效的反向时间顺序遍历,从而允许他们返回最近的推文匹配查询而不遍历每个术语的整个发布列表.
更新: 我在Googler Jeff Dean的演讲中找到了这个演示文稿,其中解释了Google如何构建其大规模信息检索系统.特别是,它讨论了分片策略和发布列表编码.