Lucene 搜索耗时过长答案

【问题标题】：Lucene search taking TOOO longLucene 搜索耗时过长
【发布时间】：2011-02-27 12:15:50
【问题描述】：

我在（当前）70Gig 索引上使用 Lucene.net (2.9.2.2)。我可以进行相当复杂的搜索并在 1 ~ 2 秒内获取所有文档 ID。但要实际加载所有命中（在我的测试查询中大约有 70 万次）需要 5 分钟以上。

我们没有将 lucene 用于 UI，这是一个进程之间的数据存储，我们有数亿个预缓存的数据元素，我正在处理的部分从每个找到的文档中导出一些特定字段。（因此，没有分页，因为这是进程之间的导出）。

我的问题是在搜索结果中获取所有文档的最佳方式是什么？目前我正在使用一个自定义收集器，它对文档进行获取（使用 MapFieldSelector）作为其收集。我还尝试在收集器完成后遍历列表。但那更糟。

我对想法持开放态度:-)。

提前致谢。

【问题讨论】：

您能否详细说明为什么您需要为每个查询加载数十万次点击？我还没见过这样的应用程序。
对于您的 700,000 个文档，总数据量是多少（大小）？如果数据很多，加载数据的速度不会超过磁盘读取数据的速度。另外，您在阅读数据时对数据做了什么？将其写入磁盘？记住它？
这是一个导出过程..查找符合条件的配置文件..匹配的配置文件全部移交给另一个进程。该过程可能只是将 ID 导出给用户（异步），或者它可能对所有这些 ID 进行进一步处理。为了提取 700,000 个文档的当前目标字段，我们正在查看大约 100 megs ..（可能更多更糟糕的情况 senario).. 要提取整个文档，可能是 750 ~ 800 megs)。是的，因为这是一个处理过程，所以需要所有的命中。
所以在您的示例中，加载 700K 文档的目标字段是 5 分钟以上，还是加载所有 700k 文档的整个文档？

【解决方案1】：

您需要搜索哪些字段？您需要存储哪些字段？ Lucene.net 可能不是存储和检索实际文档文本的最有效方式。您的方案建议不存储任何内容，索引所需字段并返回文档 ID 列表。文档本身可以存储在辅助数据库中。

【讨论】：

存储的数据非常小（最多几百字节）。所以从 Lucene 到另一个存储引擎可能不会更快（甚至可能更慢）。因为每个 documentID会导致对另一个引擎的单独调用..除非我可以进行该调用并以每毫秒 3 次或更多的速度获得结果，否则它可能比 Lucene 慢（不幸的是）。

【解决方案2】：

嗯，鉴于您在将“获取”代码移出收集器时发现了问题，听起来您的问题与 I/O 相关。

考虑到您的索引大小，我几乎不敢问这个问题，但是您尝试过吗：

如果是这样，对检索文件的速率是否有明显影响？顺便说一句，如果我摇摇晃晃的数学是正确的，我每秒检索到 2333 个项目...

另外，对于您要检索的字段子集，它们中的任何一个都可以压缩吗？或者您是否已经尝试过压缩？

作为一个相关的问题，70 万个项目在您的索引中所占的比例是多少？感受一下 I/O 吞吐量会很有趣。您可能可以计算出您的机器/硬盘驱动器组合的最大理论数据速率，看看您是否已经接近极限。

【讨论】：

昨晚进行了优化.. 今天早上 5:00 开始进行碎片整理（它仍在运行）.. 我会告诉你这是否加快了速度.. :-)
不幸的是，没有明显的差异.. 计算每个文档大约需要 0.51 毫秒（平均读取超过 780,000 个文档）.. 这不是“坏”我正在尝试的领域现在缓存，但它（到目前为止）需要 50 分钟来加载（尚未完成）和 5 1/2 gigs 的 ram..
我认为字段缓存不会有帮助，除非您再次检索相同的文档。