我们当前的用例似乎与您的用例有些相似：16亿行，大多数字段都是精确匹配的，定期添加文件/行，定期搜索。我们的初始索引目前没有以任何方式分布式或并行化，大约需要9个小时。我提供这个数字只是为了给予您一个非常模糊的概念，让您对索引体验有一个大致的了解。
尝试回答你的问题：
1.我们的索引时间不会随着已经索引的行数呈指数级增长，尽管它确实会逐渐变慢。对我们来说，到最后可能会慢20%，尽管它也可能是特定于我们的数据。
如果你遇到了明显的慢下来，我支持femtoRgon的建议，你应该分析一下是什么在消耗时间。Lucene从来不是我们系统中最慢/最弱的组件。
1.是的，你可以并行地写入索引，你可能会看到吞吐量的提高。当然，它是否有帮助取决于你的瓶颈在哪里。考虑使用Solr -它可以减轻你的努力。
1.我们使用StringField，LongField和TextField的混合。看起来不太可能是字段类型本身导致您的减速。
这些答案都是奇闻轶事，但也许对你有用。
这个页面现在已经很过时了，但是如果你用尽了所有你的其他选项，可能会提供提示，告诉你可以拉哪些杠杆来调整性能：How to make indexing faster

你有没有分析过到底是什么导致了你的性能问题？你可能会发现一些意想不到的事情一直在吞噬着你。当我分析了一个类似的性能问题时，我认为是由lucene引起的，结果发现问题主要是字符串连接。
至于应该使用StringField还是IntField，（或TextField，或其他），你应该根据字段中的内容来确定如何搜索它。如果你可能想搜索字段作为一个数值范围，它应该是IntField，而不是StringField。顺便说一下，StringField将整个值作为一个术语索引，并跳过分析，因此这也是全文的错误字段，您应该使用TextField。基本上，对我来说，对所有内容使用StringField似乎都是一种糟糕的代码气味，并且可能在索引时导致性能问题，但我肯定会期望更大的问题会出现时，你开始尝试搜索。
至于“50亿个值的搜索性能如何”，这是一个太模糊的问题，甚至无法回答。不知道。试试看。

Lucene有一个每个分片21.4亿文档的硬限制。所以你必须把你的索引分成分片或者有多个索引，这样每个索引/分片包含的文档不超过21.4亿。我有一些索引已经达到了这个硬限制。（我直接使用lucene..而不是ElasticSearch/Solr），并且没有看到索引速度有任何明显的下降。（Int，Float和Long）以及StringField和TextField类型。也检查您的RAM缓冲区大小设置为Index Writer。增加它可能会稍微帮助速度。