我正试图使用lucene为50亿行甚至更多行的记录编制索引。索引的时间是否随着记录集的增加而呈指数级增加？
我最初对1000万条记录进行索引的速度非常快，但当我尝试对超过1亿条记录进行索引号时，相对于1000万条的索引时间，所花费的时间比我预期的要多。
是因为它正在根据更多的文档对其进行索引，因此时间呈指数级增长吗？或者，这种行为背后的原因是什么，有没有任何方法可以优化它（请注意，目前所有文档中的所有字段都是StringField类型，将其更改为IntField会在这个方向上帮助我吗？）。
我的第二个问题是，在索引50亿条记录的情况下，搜索性能如何。对此有什么想法吗？
如果你需要我这边的更多信息，请告诉我。
我们当前的用例似乎与您的用例有些相似：16亿行，大多数字段完全匹配，定期添加文件/行，定期搜索。目前，我们的初始索引没有以任何方式进行分布式或并行化，大约需要9个小时。我提供这个数字只是为了给你一个非常模糊的感觉，你的索引经验可能是什么
尝试回答您的问题：
-
我们的索引时间不会随着已经索引的行数呈指数级增长，尽管它确实会逐渐放缓。对我们来说，到最后可能会慢20%，尽管这也可能是我们的数据所特有的。
如果你正在经历严重的慢下来，我支持femtoRgon的建议，你可以通过个人资料来了解当时吃的是什么。Lucene从来都不是我们系统中速度最慢/最弱的组件。
-
是的，您可以并行写入索引，您可能会看到吞吐量的提高。当然，它是否有帮助取决于你的瓶颈在哪里。考虑使用Solr——它可能会减轻你在这里的工作量。
-
我们使用
StringField、LongField和TextField的混合物。这类领域似乎不太可能单独导致你的经济放缓。
这些答案都是轶事，但也许对你有用。
这个页面现在已经过时了，但如果您用尽了所有其他选项，可能会提示您可以使用哪些杠杆来调整性能：如何使索引更快
您是否分析过导致性能问题的原因？你可能会发现一些意想不到的事情一直在吞噬你。当我分析一个类似的性能问题时，我认为这是由lucene引起的，结果发现问题主要是字符串连接。
至于你应该使用StringField还是IntField（或TextField，或其他什么），你应该根据字段中的内容以及你将如何搜索它来确定。如果你想将字段搜索为一个数值范围，它应该是IntField，而不是StringField。顺便说一句，StringField将整个值作为一个术语进行索引，并跳过分析，因此这也是全文的错误字段，您应该使用TextField。基本上，对我来说，对所有内容使用StringField似乎都是一种糟糕的代码气味，并且可能会在索引时导致性能问题，但我肯定认为，当你开始尝试搜索时，会出现更大的问题。
至于"50亿个值的搜索性能如何"，这个问题太模糊了，甚至无法回答。不知道。试试看。