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

Question

我听说，在 Lucene 中，每个查询的处理时间和使用的内存几乎不取决于索引的大小。相反，有人告诉我，查询的大小 本身确实决定了运行查询所需的时间和计算资源。我得到的论点归结为这只是因为反向索引是如何工作的。

我对 Lucene 不是很熟悉，但是这个断言的确切基础是什么，其中有多少真实性？

Answer 1

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

对于查询，它列出了必须验证才能返回文档的条件 - 再次（一般而言）条件越多，资源使用量就越多。

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

Answer 2

Lucene 索引全文并存储从terms 到其文档的链接。在搜索terms 时，lucene 搜索索引而不是实际文档。这就是它被称为inverted index 并提供快速响应的原因。

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

例如，您正在搜索一个术语：lucene，然后是 FST 的外观以及在术语字典中的顺序搜索。术语词典中的术语已排序。

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

当索引大小增长到可用内存（缓存）大小时，处理时间和内存使用成为瓶颈。这就是分片概念出现的原因。您将文档分布在许多分片中，这样索引的大小就会很小并且可以缓存在内存中。