在Lucene中擁有更多更小的記錄或更少的更大記錄會更好嗎？

Question

我正在爲使用Lucene.net工作的應用程序編制一大組日誌文件。現在我正在爲每個條目解析我的日誌文件（即，條目可以跨越多行，直到下一個日誌條目），並將每個日誌條目添加爲Lucene中的文檔。

每個文檔都包含日誌條目（已分析）和其他一些字段（只是存儲），如日誌行時間，日誌行號和來自哪種日誌。我還給每個日誌條目文檔指導一個日誌條目映射到原始源文檔，我可以通過行號重新排列它們。

雖然我喜歡能夠在索引中搜索每行條目的粒度（我可以通過關閉指定每個日誌文件的guid來重建原始文檔），但我很好奇這種類型的指數創造將是可持續的。事實上，我已經擁有了2500萬個條目，代表了來自一年的日誌。我的搜索速度仍然非常快，我可以在一兩秒鐘內搜索這2500萬條記錄。

文檔較少但每個文檔較大會更好嗎？有關係嗎？當我有5000萬條目時，我會遇到Lucene的性能瓶頸嗎？ 1億？ 5億？如果我只對每個日誌文件進行索引，如果我估計每個日誌文件大約有1000-20000行，那麼我可能會減少3個數量級的文檔。

Answer 1

所有這些事情的建議是：性能幾乎肯定不會是你的主要問題。如果所需功能對每行的文檔效果最好，那就這樣做。

話雖這麼說，Lucene的術語字典看起來像：

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

因此，有更多的文件會增加索引的大小。

在您斷定這對性能不利之前，請問如果將整個文件編制爲一個文檔，您將如何設法將每一行作爲自己的搜索結果返回。您必須在搜索結果中實施一些輔助搜索，這幾乎可以保證比Lucene的搜索結果慢。所以讓Lucene處理它吧。

至於你關於Lucene如何擴展的問題：幾年前提交了一個補丁，因爲Lucene使用的32位ID太小。所以有些人的索引包含超過2^32 = 42億文件。

Answer 2

RavenDB在內部使用Lucene進行查詢和性能測試，結果表明，具有更多字段的索引數量少於擁有更少字段的更多索引的性能。

對於一些實際的數字參見this thread，例如：

• 100索引與單個屬性中的每個：00:05:08
• 1索引100點的屬性：0點02分01秒

這是用於25,600個文檔（每個文檔都有100個填充了guid的字符串屬性）。

注意這些數字是RavenDB，但它使用Lucene的廣泛應用，所以使用Lucene時直接