優化Lucid/Solr來索引大型文本文檔

Question

我想索引大約300萬個solr文本文檔。這些文件中大約1/3是電子郵件，其中包含大約1-5段文字。剩下的2/3文件每句只有幾句話。

它需要Lucid/Solr將近1小時才能完全索引正在處理的整個數據集。我試圖找到優化這個方法。我已經設置了Lucid/Solr來只提交每100,000個文件，並且它一次對50,000個文件的批量文件進行索引。內存不再是一個問題，因爲批處理會一直保持在1GB左右的內存。

整個數據集最初都必須編入索引。這就像一箇舊系統必須加載到一個新系統，所以數據必須被索引，並且需要儘可能快，但是我不確定要優化這個時間需要考慮哪些領域。

我在想，也許有很多像「這，一個，因爲，應該，如果......」這樣的小詞彙造成了很多開銷並且只是「噪音」字。我很好奇，如果我將它們切斷，如果它會大大加快索引時間。我一直在看Lucid文檔一段時間，但我似乎無法找到一種方法來指定什麼詞不索引。我遇到了「停止列表」一詞，但沒有多過提及它。

是否有其他方法可以使這種索引變得更快，或者我只是堅持1小時索引時間？

Answer 1

從您的查詢看來，索引時間對於您的應用程序非常重要。 Solr是一個很棒的搜索引擎，但是如果你需要超快速的索引時間，並且對你來說這是一個非常重要的標準，那麼你應該使用Sphinx搜索引擎。使用Sphinx不需要太多時間來快速設置和測試結果。

可以有多種方法（比如你提到的那個，停用詞等）來優化，但是無論你在索引時間方面做了什麼，Solr都無法擊敗Sphinx。我已經完成了自己的基準測試。

我也非常喜歡Solr，因爲它易於使用，它具有出色的功能，如N-Gram Indexing，Faceting，Multi-core，Spelling Correctors以及與其他apache產品的整合等等。但是當它來優化算法（是它的索引大小，索引時間等）獅身人面像岩石！

斯芬克斯也是開源的。試試看。

Answer 2

我們最近遇到了類似的問題。我們不能使用solrj作爲請求和響應必須通過一些應用程序，所以我們採取以下步驟： Creating Custom Solr Type to Stream Large Text Field！

1. 使用GZipOutput/InputStream和Bse64Output/InputStream壓縮大文本。這可以減少約85％的文本大小，這可以減少傳送請求/響應的時間。

2. 爲了減少內存使用在客戶端：

   2.1我們使用流API（GSON流或XML斯塔克斯）通過一個閱讀文檔之一。

   2.2定義一個自定義Solr字段類型：FileTextField，它接受FileHolder作爲值。 FileTextField最終會將閱讀器傳遞給Lucene。 Lucene將使用閱讀器讀取內容並添加到索引中。

   2.3當文本字段太大時，首先將其解壓縮到一個臨時文件，創建一個FileHolder實例，然後將FileHolder實例設置爲字段值。