這幾天實現了個Lucene分布式檢索的模塊，采用的分布式方案是將數據分塊，分別生成N個索引文件，放到N個節點上運行。檢索時，對每一個節點發出查詢請求，將N個節點返回的結果歸並，然后生成一個新的結果。如果沒看明白，可以看看我的帖子 http://www.iteye.com/topic/212046 ，這個方案同帖子中的思想是一致的。
用這樣的方案，遇到的問題是歸並過后的結果，同沒有歸並結果是有一定區別的。在實現這個方案前我也分析過，Lucene使用TF/IDF算法來計算相關度，所以會產生這樣的問題：
100萬條數據，分別索引成2個50萬數據的索引文件A，B和100萬條數據的索引文件C。這樣，A、B、C3個文件的IDF都不相同，所以搜索出來的結果將會不同。但是如果是海量數據，IDF值從統計學角度上來說應該是非常相似的，所以搜索出的結果大體上來說是一樣的。
今天專門做了一個實驗，取100萬條數據做測試，每個節點50萬數據，進行幾個關鍵詞的檢索，同包含100萬條同樣數據的索引文件比較，取前100項統計有多少項不同。數據是類似www.net114.com這樣的類型的數據，下面是結果（同位置是指在100條數據中，位置相同的數據。非交集指那些分布式檢索返回的結果，不在集中式檢索的結果之中的數據）：
關鍵字：公司
同位置:0條
非交集:12條
“公司”這個關鍵字返回的結果非常多，基本返回整個數據集中的數據。這個測試針對的是目的非常模糊的查詢。
關鍵字：永恆 公司
同位置:4條
非交集:0條
返回的結果中等，針對有一定目的的查詢。
關鍵字：中國石油
同位置:1條
非交集:0條
針對比較精確的查詢，返回的結果最前面基本都是中國石油開頭的數據。
可以看到，同之前的分析結果類似，進行這樣的分布式檢索，基本上同集中式檢索獲取到的數據是相同的，但是排序不同。我已經截圖下來了，但是這里貌似沒法發……總體上來說，我這些精度損失在我的項目中還是可以接受的，對“公司”這種返回結果很多，搜索目的非常模糊的檢索，頭10項相差得比較大。但是這種搜索本身要求的精度就不是很高。而對於比較精確的搜索，頭10項相差得很小，要是有興趣的話我找個地方上傳圖片給大家看看。
至於性能，經過100萬數據的測試，大體上能提升至少30%的檢索時間，偶爾有超過單個節點查詢的情況，一般是由於在網絡傳輸層中有一些延時造成的，有的也是我系統的BUG……。進行分布式的好處在於能夠處理一些無法分割的數據，保證在海量數據下也能保持足夠的響應速度。
最近准備學習Java（我是用.Net的），不知道大家對這個分布式檢索的方案有沒有興趣，如果有興趣的話我就用Java實現它，希望到時候大家多多指點~~~
可以用remotesearcher, 如果節點不再用一個JVM, 如果是同一個里面, 用multisercher就行了， 里面回計算全局TF/IDF。
remotesearcher基本不能用於企業級應用。
精度問題，其實有辦法解決，從我的應用來看，TF/IDF應該自己作為一個文件保存。查詢時去讀取保存有所有數據的TF/IDF的表，就能保證每個節點的評分都是一致的。而且，還可以做出一些擴展的東西，比如我要搜索某個行業中的數據，可以專門做一個TF/IDF表，對該行業中的某些關鍵字加權，這樣搜出來的結果會更加符合。但是這樣就要修改Lucene的源碼了，這個目前我還沒做，因為感覺現在這樣搜出來的結果也不錯。
不過為什么說remotesearcher基本不能用於企業級應用呢？我也沒有在大規模的集群上測試過，目前幾台計算機來看效果還可以。方便的話不妨說下，謝謝。
精度問題，其實有辦法解決，從我的應用來看，TF/IDF應該自己作為一個文件保存。查詢時去讀取保存有所有數據的TF/IDF的表，就能保證每個節點的評分都是一致的。而且，還可以做出一些擴展的東西，比如我要搜索某個行業中的數據，可以專門做一個TF/IDF表，對該行業中的某些關鍵字加權，這樣搜出來的結果會更加符合。但是這樣就要修改Lucene的源碼了，這個目前我還沒做，因為感覺現在這樣搜出來的結果也不錯。
不過為什么說remotesearcher基本不能用於企業級應用呢？我也沒有在大規模的集群上測試過，目前幾台計算機來看效果還可以。方便的話不妨說下，謝謝。