通常任何搜索引擎软件都会创建倒排索引以加快搜索速度。基本格式是："Harry Potter Movies"
每当在引号内存在搜索查询（如"Harry Potter Movies"）时，这意味着应当存在词的位置的精确匹配，并且在搜索（如在k个词内的查询（如hello /4 world））中，这通常意味着在从词hello的左边或右边的4个词距离的范围内找到词world。我的问题是，我们可以采用像线性检查帖子和计算单词距离这样的解决方案，但是如果集合非常大，我们就不能搜索所有的帖子。那么，Lucene或Solr是否使用了其他的数据结构或优化类型呢？
第一种解决方案可以只搜索每个单词的k个帖子。另一种解决方案可以只搜索排名靠前的文档（通常称为champion list，按tf-idf或类似的方法排序），但更多更好的文档可以被忽略。这两种解决方案都有一些缺点，它们都不能保证质量。但在Solr服务器中，即使在大的集合中，我们也能保证结果的质量。如何做到这一点？
1条答案
按热度按时间fsi0uk1n1#
你在这里问的短语查询实际上是非常有效的计算位置，因为你问的是“哈利”和“波特”和“电影”出现的文档。
Lucene非常聪明，但它的算法核心是，它只需要访问所有这三个术语都出现的文档的位置列表。
Lucene的帖子也被分割成多个文件：在计数文件中有：（文档、TF、位置地址）+位置文件内有：（位置数组）
因此，它可以扫描（doc，tf，pos_addr）以查找这三个词中的每一个，并且只在这三个词都出现在特定文档中时才查询PositionsArray。短语查询有机会非常快，因为您只访问最少出现的词的所有文档。
如果您希望看到短语查询运行缓慢（并执行大量磁盘寻道！），请尝试：“to be or not to be”...这里的AND部分没有多大帮助，因为所有的术语都很常见。