| 導購 | 订阅 | 在线投稿
分享
 
 
 

lucene並行建索引解決方案

來源:互聯網網民  2008-05-31 00:48:13  評論

背景:單線程爲30萬條數據建索引花了10分鍾,爲了提高效率采用多線程

起初我采用多個線程共享一個indexwriter實例(也意味著往同一個目錄寫索引),這是luceneinaction和lucenewiki的推薦做法,不知道到爲什麽總是報FileNotFoundException,很讓人困惑。偶爾會成功一次。這個錯誤讓我想起另外一個問題,就是在建索引的時候搜索也會報這個

錯誤,luceneinaction明明也說了建索引讀的時候沒問題。

言歸正傳,我第二次嘗試使用每個線程單獨擁有自己的indexwriter實例,但往同一個目錄寫索引,果然報了

寫鎖的錯,這和書上說的很一致。

最後沒辦法了,我使用每個線程單獨使用自己的實例,往自己的目錄寫索引,最後一個幹完的線程將所有的索引合並比如我開了4個線程,那麽就有5個目錄build_index,build_index1,build_index2,build_index3,build_index4線程1往build_index1中寫,線程往build_index2,。。。依次類推,最後一個幹完的將build_index1-4目錄的索引合並到build_index.

我開了4個線程嘗試發現也要花大概7-8分鍾,合並索引的過程非常快20秒左右。

開了10個線程,整個過程需要6分多鍾,合並索引也只花了21秒。

似乎效果並不明顯,這因該是因爲數據量還不夠大引起的,數據量越大,並行的優勢會越明顯

可見合並索引的過程非常快,這又提供了另外的好處,我們通常將build_index作爲搜索目錄,就像上面說的那樣,建索引的過程會影響搜索(雖然按照書上說是不影響的),如果我們采用這種方案,建索引的絕大部分過程其實與build_index目錄無關,只有最後合並的時候需要用到build_index,但那個過程又非常的快速,所以可以極大的緩解建索引給搜索帶來的問題。

如果條件允許,你可以擴展一下這個方案,將多線程索引升級爲多台機器同時建。

http://blog.csdn.net/pwlazy/archive/2007/02/16/1511097.aspx

 
特别声明:以上内容(如有图片或视频亦包括在内)为网络用户发布,本站仅提供信息存储服务。
 
背景:單線程爲30萬條數據建索引花了10分鍾,爲了提高效率采用多線程 起初我采用多個線程共享一個indexwriter實例(也意味著往同一個目錄寫索引),這是luceneinaction和lucenewiki的推薦做法,不知道到爲什麽總是報FileNotFoundException,很讓人困惑。偶爾會成功一次。這個錯誤讓我想起另外一個問題,就是在建索引的時候搜索也會報這個 錯誤,luceneinaction明明也說了建索引讀的時候沒問題。 言歸正傳,我第二次嘗試使用每個線程單獨擁有自己的indexwriter實例,但往同一個目錄寫索引,果然報了 寫鎖的錯,這和書上說的很一致。 最後沒辦法了,我使用每個線程單獨使用自己的實例,往自己的目錄寫索引,最後一個幹完的線程將所有的索引合並比如我開了4個線程,那麽就有5個目錄build_index,build_index1,build_index2,build_index3,build_index4線程1往build_index1中寫,線程往build_index2,。。。依次類推,最後一個幹完的將build_index1-4目錄的索引合並到build_index. 我開了4個線程嘗試發現也要花大概7-8分鍾,合並索引的過程非常快20秒左右。 開了10個線程,整個過程需要6分多鍾,合並索引也只花了21秒。 似乎效果並不明顯,這因該是因爲數據量還不夠大引起的,數據量越大,並行的優勢會越明顯 可見合並索引的過程非常快,這又提供了另外的好處,我們通常將build_index作爲搜索目錄,就像上面說的那樣,建索引的過程會影響搜索(雖然按照書上說是不影響的),如果我們采用這種方案,建索引的絕大部分過程其實與build_index目錄無關,只有最後合並的時候需要用到build_index,但那個過程又非常的快速,所以可以極大的緩解建索引給搜索帶來的問題。 如果條件允許,你可以擴展一下這個方案,將多線程索引升級爲多台機器同時建。 http://blog.csdn.net/pwlazy/archive/2007/02/16/1511097.aspx
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有