在 Lucene 中有更多的小记录还是更少的大记录更好？答案

【问题标题】：Is it better to have more smaller records or fewer larger records in Lucene?在 Lucene 中有更多的小记录还是更少的大记录更好？
【发布时间】：2012-02-23 16:49:35
【问题描述】：

我正在为我使用 Lucene.net 开发的应用程序编制大量日志文件的索引。现在我正在解析每个条目的日志文件（即一个条目可以跨越多行，直到下一个日志条目）并将每个日志条目添加为 Lucene 中的文档。

每个文档都包含日志条目（被分析）和一些其他字段（只是存储），例如日志行时间、日志行号以及它来自什么类型的日志。我还为每个日志条目文档提供了一个 guid，以将一系列日志条目映射回原始源文档，并且我可以按行号重新排序它们。

虽然我喜欢能够在我的索引中搜索每行条目的粒度（并且我可以通过关闭分配给每个日志文件的 guid 来重建原始文档），但我很好奇这种索引是否创造将是可持续的。事实上，我已经有大约 2500 万个条目，它们代表仅一年的日志。我的搜索速度还是挺快的，我可以在一两秒内搜索到这 2500 万条记录。

文档越少，每个文档越大越好吗？有关系吗？当我有 5000 万个条目时，我会遇到 Lucene 的性能瓶颈吗？一亿？ 5亿？如果我只为每个日志文件编制索引，如果我估计每个日志文件大约有 1000-20000 行，我可能会少 3 个数量级的文档。

【问题讨论】：

标签： c# lucene lucene.net

【解决方案1】：

对所有这些事情的建议是：性能几乎肯定不会是您的主要问题。如果所需的功能最适合每行一个文档，那么就这样做。

话虽如此，Lucene 的术语字典看起来像：

term1 -> doc1 doc4 doc32 ...
term2 -> doc1 doc3 doc8

所以拥有更多文档会增加索引的大小。

在您断定这对性能不利之前，请询问如果您确实将整个文件作为一个文档进行索引，您将如何设法将每一行作为其自己的搜索结果返回。你必须在你的搜索结果上实现一些二次搜索，这几乎可以保证比 Lucene 的速度慢。所以就让 Lucene 来处理吧。

关于 Lucene 可以扩展多高的问题：几年前提交了一个补丁，因为 Lucene 使用的 32 位 ID 太小。所以有些人的索引包含超过 2^32 = 42 亿个文档。

【讨论】：

【解决方案2】：

RavenDB 在内部使用 Lucene 进行所有查询，性能测试表明，具有更多字段的更少索引比具有更少字段的更多索引具有更好的性能。

查看this thread 了解一些实际数字，例如：

100 个索引，每个索引都有一个属性：00:05:08
1 个索引，包含 100 个属性：00:02:01

这适用于 25,600 个文档（每个文档有 100 个用 guid 填充的字符串属性）。

注意这些数字是针对 RavenDB 的，但它广泛使用 Lucene，所以如果直接使用 Lucene 会有很大差异，我会感到惊讶

【讨论】：