作者:大爱仅有的财产丶_468 | 来源:互联网 | 2023-09-08 11:16
在索引阶段,我们可以在每一篇文档中添加一条或多条DocValues信息(正排),使得在查询阶段,当收集器Collector收集到满足查询条件的文档号后,可以根据文档号找到对应的正排信息,并依据正排信息对查询结果进行排序。
图1:
图1中添加了3篇文档,红框标注即正排信息,我们在查询条件中设置一个排序规则:
图2:
在图2的排序规则下,返回的结果为:
图3:
查询TopN的性能(优化前)
基于目前Lucene的查询模块设计,整个查询过程可以按照获取迭代器
和收集器处理文档
的这两个大的功能块进行划分。
获取迭代器
获取迭代器描述的是从倒排信息中或者存储数值类型的BKD树中找到满足查询条件的文档号集合,该集合用于生一个迭代器。随后迭代器会按照文档号从小到大的顺序(在设置了段的排序IndexSort后,顺序可能会发生变化,见文章Collector(三)中的预备知识的介绍)依次取出每一个文档号,并将文档号送到收集器Collector中。
收集器处理文档
收集器Collector会从迭代器中依次的获得有序的文档号,执行排序、过滤等操作。
问题
上文介绍的查询模块设计会存在这个问题(为了便于介绍,我们暂时不考虑设置了段排序的情况):假设我们有10000篇文档号,排序方式为按照正排值升序,并且文档0中的正排值为0,文档1中的正排值为1,剩余的9998篇文档的正排值都大于1。如果我们只要Top2的结果,那么很明显,最好的期望的处理方式应该是收集器Collector在处理完文档0跟文档1后就不再处理剩余的其他文档了。然而在优化之前,由于依次传入到收集器Collector的文档号是从小到大是有序的,但是文档号对应的正排值是无法保证有序的,意味着收集器Collector只有处理完所有的文档号才能实现正确的Top2。在文章Collector(三)中详细介绍了优化前利用NumericDocValues获取TopN的过程,可以先行阅读下。
查询TopN的性能(优化后)
在Lucene8.6.0后,当使用NumericDocValues实现TopN的查询时,可以跳过那些没有竞争力(uncompetitive)的文档集合,快速实现TopN的查询。我们先给出一个例子,比较下优化前后的性能差别,demo的地址:https://github.com/LuXugang/Lucene-7.5.0/blob/master/LuceneDemo8.9.0/src/main/java/index/NumericDocValuesTopNOptimization.java。
剩余内容看这里:https://www.amazingkoala.com.cn/Lucene/Search/2021/0621/193.html