我正在为使用Lucene.net的应用程序索引大量日志文件。现在我正在为每个条目解析我的日志文件（即一个条目可以跨越多行直到下一个日志条目）并将每个日志条目添加为Lucene中的文档。
每个文档都包含日志条目（已分析）并具有一些其他字段（仅存储），例如日志行时间，日志行号以及它来自哪种日志。我还给每个日志条目文档一个guid，将一系列日志条目映射回原始源文档，我可以按行号重新排序。
虽然我喜欢能够在索引中搜索每行条目的粒度（我可以通过关闭我已分配每个日志文件的guid重建原始文档），但我很好奇这种索引创造将是可持续的。事实上，我已经拥有了2500万个条目，代表了一年的日志。我的搜索速度仍然很快，我可以在大约一两秒内搜索这2500万条记录。
文档较少但每个文档较大是否更好？有关系吗？当我有5000万条目时，我会遇到Lucene的性能瓶颈吗？ 1亿？ 500万？如果我只对每个日志文件编制索引，如果我估计每个日志文件大约有1000-20000行，那么我可能会减少3个数量级的文档。
答案 0 :(得分：3)
所有这些事情的建议是：表现几乎肯定不是你的主要问题。如果所需的功能最适合每行一个文档，那么就这样做。
话虽如此，Lucene的术语词典看起来像：
term1 -> doc1 doc4 doc32 ...
term2 -> doc1 doc3 doc8
因此，拥有更多文档会增加索引的大小。
在您断定这对性能有害之前，如果您将整个文件编入索引作为一个文档，请询问如何将每行返回为自己的搜索结果。您必须在搜索结果上实施一些辅助搜索，这几乎可以保证比Lucene的速度慢。所以让Lucene来处理它。
至于你关于Lucene可以扩展的程度的问题：几年前提交了一个补丁，因为Lucene使用的32位ID太小了。因此，有些索引包含超过2 ^ 32 = 42亿个文档。
答案 1 :(得分：1)
RavenDB在内部使用Lucene进行所有查询，并且性能测试表明，具有更多字段的索引比具有更少字段的索引更好。
请参阅this thread了解一些实际数字，例如：
这是25,600个文档（每个文档都有100个字符串属性填充guids）。
注意这些数字适用于RavenDB，但它广泛使用Lucene，所以如果直接使用Lucene有很大的不同，我会感到惊讶