Apache Lucene中的索引性能

Question

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

我最初为1000万条记录建立索引的过程非常迅速，但是当我尝试为1亿条记录建立索引时，相对于1000万条记录的索引时间，它花费的时间比我预期的要多。

是因为它正在针对更多文档建立索引，因此时间呈指数增长？ 还是此行为背后的原因是什么，有什么方法可以对其进行优化（请注意，当前所有文档中的所有字段均为StringField类型，将其更改为IntField可以在这个方向上为我IntField帮助吗？）。

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

让我知道您是否需要我提供更多有关此方面的信息。

Answer 1

我们当前的用例似乎有点像您的用例：16亿行，大多数字段完全匹配，文件/行的定期添加，常规搜索。 目前，我们的初始索引尚未以任何方式分发或并行化，大约需要9个小时。 我仅提供该数字是为了让您对您的索引体验可能非常模糊。

尝试回答您的问题：

1. 我们的索引时间不会随着已经建立索引的行数呈指数增长，尽管会逐渐减慢。 对于我们来说，到最后可能会慢20％，尽管这也可能是我们的数据所特有的。

   如果您遇到显着的速度下降，我支持femtoRgon的建议，即建议您配置一下以查看正在消耗的时间。 Lucene从来不是我们系统中最慢/最弱的组件。

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

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

这些答案都是轶事，但也许对您有用。

现在此页面已经过时，但是如果您用尽所有其他选项，可能会提示您可以拉动哪些杠杆来调整性能： 如何使索引编制速度更快

Answer 2

您是否进行了分析以查看实际上是什么导致了性能问题？ 您会发现所有时间都在吃东西。 当我分析了一个类似的性能问题时，我认为这是由lucene引起的，事实证明该问题主要是字符串连接。

至于是否应该使用StringField或IntField （或TextField或其他），则应根据字段中的内容来确定搜索方式。 如果您想以数值范围搜索字段，则该字段应该是IntField而不是StringField 。 顺便说一句， StringField将整个值作为单个项索引，并且跳过了分析，因此对于全文本而言，这也是错误的字段，您应该使用TextField 。 基本上，对我所有东西都使用StringField似乎对我来说是一种不好的代码味道，并且可能在索引时导致性能问题，但是我绝对希望当您开始尝试搜索时会出现更大的问题。

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