Apache Lucene 中的索引性能

Question

我正在尝试使用 lucene 索引 50 亿甚至更多行的记录。 索引时间是否会随着记录集的增加而呈指数增长？

我最初对 1000 万条记录进行索引的速度非常快，但是当我尝试为超过 1 亿条记录建立索引时，相对于 1000 万条记录的索引时间而言，所花费的时间比我预期的要长。

是不是因为它针对更多文档编制索引，因此时间呈指数级增长？或者这种行为背后的原因是什么，有什么方法可以优化它（请注意，目前所有文档中的所有字段都是StringField类型，将其更改为IntField可以帮助我朝这个方向发展吗？） .

我的第二个问题是在索引 50 亿条记录的情况下搜索性能如何。有什么想法吗？

如果您需要我提供的更多信息，请告诉我。

Answer 1

我们当前的用例似乎与您的有些相似：16 亿行，大多数字段都是完全匹配的，定期添加文件/行，定期搜索。目前，我们的初始索引没有以任何方式分布或并行化，大约需要 9 个小时。我提供这个数字只是为了让您对自己的索引体验有一个非常模糊的认识。

尝试回答您的问题：

1. 我们的索引时间不会随着已索引的行数呈指数增长，尽管它确实会逐渐减慢。对我们来说，到最后可能会慢 20%，尽管它也可能是特定于我们的数据的。

   如果您的速度明显变慢，我支持 femtoRgon 的建议，即您可以剖析一下时间消耗了什么。 Lucene 从来都不是我们系统中最慢/最弱的组件。

2. 是的，您可以并行写入索引，您可能会看到吞吐量有所提高。当然，它是否有帮助取决于你的瓶颈在哪里。考虑使用 Solr - 它可能会减轻您的工作量。

3. 我们混合使用StringField、LongField 和TextField。字段类型本身似乎不太可能导致您的速度变慢。

这些答案都是轶事，但也许它们会对你有所帮助。

此页面现已过时，但如果您用尽 所有 其他选项，可能会提示您可以拉动哪些杠杆来调整性能：How to make indexing faster

Answer 2

您是否进行了分析以了解实际导致您的性能问题的原因？你会发现一些意想不到的东西一直在吃东西。当我分析了一个我认为是由 lucene 引起的类似性能问题时，结果发现问题主要是字符串连接。

至于您是否应该使用StringField 或IntField（或TextField，或其他），您应该根据字段中的内容来确定您将如何搜索它。如果您可能希望将该字段作为数值范围进行搜索，则它应该是IntField，而不是StringField。顺便说一句，StringField 将整个值索引为单个术语，并跳过分析，因此这也是全文的错误字段，您应该使用TextField。基本上，对我来说，使用StringField 对所有内容都非常糟糕，并且可能会导致索引时出现性能问题，但我肯定会在您开始尝试搜索时出现更大的问题。

至于“50 亿个值的搜索性能如何”，这是一个过于模糊的问题，甚至无法尝试回答。不知道。试试看。