Lucene (.NET) 文档结构和性能建议答案

【问题标题】：Lucene (.NET) Document stucture and performance suggestionsLucene (.NET) 文档结构和性能建议
【发布时间】：2011-02-19 21:13:14
【问题描述】：

我正在索引大约 1 亿个文档，这些文档由几个字符串标识符和一百个左右的数字术语组成。我不会进行范围查询，所以我没有深入研究数字字段，但我没有认为这是正确的选择。

我的问题是，当我开始向查询添加 OR 条件时，查询性能会迅速下降。我所有的查询都是基于特定的数字术语。所以文档看起来像 StringField:[someString] 和 N DataField:[someNumber] .. 然后我用 DataField 之类的东西查询它：((+1 +(2 3)) (+75 +(3 5 52)) (+99 +88 +(102 155 199)))。

目前，这些查询在我的笔记本电脑上运行大约需要 7 到 16 秒。我想确保这是他们能做的最好的事情。我愿意接受有关字段结构和查询结构的建议 :-)。

谢谢

乔什

PS：我已经阅读了这里、Lucene wiki 和 lucid imiagination 上的所有其他 lucene 性能讨论……我比那个兔子洞还远一点……

【问题讨论】：

我认为需要更多信息才能得到答案。也许一些关于你已经尝试过的信息。你有任何可用的分析工具吗？如果不是，您认为您的问题是 I/O 还是 CPU 受限？问题似乎是查询绑定或结果检索绑定？很多问题，但还没有答案......
我不确定它是否与 IO/CPU 相关，我将相同的索引移动到另一个盒子（Core 2 Quad QX6600），结果是一样的。即使在 10,000 RPM Raptor 上，结果也是同样...当然，当它存在于服务器硬件上时，它可能会加快速度。而且问题不在于结果，我已经制作了一个“GetCount”收集器，它只会在每次点击时增加一个 int ..这就是我正在做我的时间测试..也只有 1200 个术语（感谢 LUKE）我的FieldCache 在 2 或 3 个查询中加载，所以我也没有获得任何东西：-P

标签： performance search lucene lucene.net

【解决方案1】：

由于您提到您正在执行特定数字查询而不是范围查询，因此我不建议您查看 Lucene 3.0 中真正快速的数字范围查询。

按照您的描述，我想是评分导致了问题。当您有这么多嵌套的布尔查询时，评分会变得越来越复杂。分数是浮点数，算术比较慢。如果你不关心分数，写自定义Collector 是个好主意。您可以在我链接的 javadoc 中查看示例来编写您自己的示例。

【讨论】：

我正在使用 Lucene.net 2.9.2 并且 numaricQuery 还没有。（如果是我打赌这会快得多:-)）这里也没有涉及计分。我已经在使用我自己的收集器。上面的数字基于我的“GetCount”收集器，它所做的只是调用 Collect(int doc) 时增加一个 int。在收集器方面不能再快了：-P。
所以更正（在重新阅读您的评论之后）.. 数字范围查询在 2.9.2 中（我知道）.. 但是在查看 3.0 的数字查询之后（我正在考虑移植它我自己），我意识到你对数字范围查询的看法..所以你..希望数字查询存在..但实际上它们只是术语查询，这就是我当前的查询正在变成的..