查询Lucene中的运行时间和索引大小

Question

我听说过，在Lucene，处理每个查询的时间＆amp;使用的内存几乎不取决于索引的大小。相反，我被告知，查询的大小本身确实决定了运行查询所需的时间和计算资源。我得到的论点归结为，这仅仅是因为反向索引的工作方式。

我对Lucene并不熟悉，但这个断言究竟是什么基础，以及它有多少真理？

Answer 1

索引和查询都在资源使用中起作用。 Lucene根据文档列表构建反向索引 - 这些文档在哪些文档中。反向索引将随索引一起增长（诚然，您可能会发现未经验证的边缘情况，但在任何现实，实际情况下都是如此）。

对于查询，它列出了必须为要返回的文档进行验证的条件 - 再次（一般来说）条件越多，资源使用越多。

所以答案肯定是两者 - 索引的大小和查询的大小都会影响资源的使用。

Answer 2

Lucene索引全文并将terms的链接存储到他们的文档中。在搜索terms时，lucene搜索索引而不是实际文档。这就是为什么它被称为inverted index并提供快速响应。

Lucene使用不可变列表（数组类型）数据结构来存储术语字典。所有搜索查询都根据术语词典中的信息获取文档。 Lucene使用FST数据结构实现来缓存术语字典，这实际上是Trie数据结构的实现。在FST中，lucene基于前缀及其在术语词典中的偏移量来存储术语信息。从那里，它执行顺序比较以匹配搜索查询。一旦在术语词典中找到匹配，它就会包含其他信息，如文档发布列表的频率和偏移量。发布列表基本上包含实际文档的内存偏移量。

例如，您正在搜索术语：lucene然后FST的外观和术语词典中的顺序搜索。术语词典中的术语已排序。

Conclusion: Lucene需要两次磁盘搜索，以便从搜索查询中搜索每个字段的字词。第一次搜索，从内存中的FST到术语词典和第二次搜索的偏移量，偏移到发布列表以查找所有匹配的文档偏移量。然后它只需要1个磁盘搜索来为每个匹配的文档提供服务。

当索引大小增加然后可用的内存（缓存）大小时，处理时间和内存使用成为瓶颈。这就是分片概念出现的原因。您可以在多个分片中分发文档，以便索引的大小很小，并且可以在内存中缓存。