NO IMAGE

研討如何進行Lucene的分散式應用

  
 共1頁 

 

  提問:

  現在有個專案,有10臺伺服器,每臺伺服器負責某一部分的index。另外有一臺web伺服器,它可以根據使用者提交的查詢請求到特定的伺服器上進行查詢。比如使用者提交查詢A,根據index的分配情況,可以將查詢請求分發給伺服器a來負責,而使用者提交查詢請求B,則將它提交給伺服器b來負責。不知lucene目前的index機制和search機制是否能夠支援這種需求?

 


 

  回答:

  1. 目前lucene的機制不支援這種需求

  2. 你可以很容易的擴充套件lucene,從而滿足你的需求.

  實際上,你這是涉及到 indexing的分散式儲存的問題, 涉及到結構, 傳輸,等等.

  所以,你必須要設計一個robust的分散式index結構,然後再考慮如何實現.不要一開始就拿一個開源的lucene就上.

  google當然是分散式的索引. 只不過這個分散式可能不是你想象中的那麼神祕.

 


提問:

 

  剛才看了一下lucene的index結構,感覺不需要對index進行修改,比如10臺檢索伺服器,每個伺服器負責一個網站的crawl以及index。然後我的web伺服器將使用者的query廣播到10臺檢索伺服器去,10臺伺服器同時進行搜尋(用lucene的api),然後每臺伺服器將最符合的topN條記錄傳送回web伺服器,web伺服器再對這topN×10條記錄進行重新排序,取最前面的topN條記錄就行了。

 

  你覺得我這種方法可行嗎?

  我覺得這種方法的缺點在於web伺服器和檢索伺服器之間的通訊量問題:

  1、首先要對10個伺服器進行廣播查詢,有沒有方法可以根據query的情況,能夠確定對某臺伺服器查詢?感覺這確實要對index進行分散式的儲存,但是如何進行分散式儲存呢?按照term進行分散式儲存肯定不行,因為對單一的term進行查詢,返回的文件肯定很多(按照lucene裡面的演算法),難道按照term vector來分散式儲存?好像lucene不太支援這個吧。

  2、其次,每臺檢索伺服器都返回了topN條結果,這好像比較浪費,有沒有什麼辦法讓它返回少點,同時又不影響結果?


 

  回答:

 

  你的這個結構理論上是可以的,不過有一點:

  按照你目前的應用規模,你的索引完全可以放在一臺機器上。

  為什麼要分開10臺機器儲存?

  集中在一臺機器上,就沒有檢索的時候,通訊量的這個問題了。

  如果你真的是想要分開,就要涉及到分散式索引,和索引之間的通訊壓縮的問題,這個也是你提到的困惑,我覺得如果你不是專業SE,你最好繞過這個技術難點。

  現在的版本已經有進度顯示,以及支援索引更新。至於與Jxta有一個based On grid的distributed fulltext search專案的區別,我們目前還沒有做過比較,呵呵。distributed search專案意在於提供多個節點之間架構一個平臺提供有效的資源查詢與資源共享方式。該專案採用lucene(http://lucene.apache.org)開放源專案作為底層的搜尋引擎,採用網格技術實現分散式機制。

  為什麼非要扯上“分佈”去?

  我看了半天,還不是太理解你的問題,就我目前的瞭解,似乎是兩種情況。

  1、檢索的負載大,想用多臺伺服器分散檢索的壓力。(相對的,全文內容的更新相對壓力較小,可以集中用一臺高效能伺服器來處理全文內容的更新)

  由於lucene是基於檔案的,實現起來比較方便一些。你可以使用NAS做為你的儲存,或者是直接採用廉價的同步複製方案(比如rsyncd)。

  比如10臺伺服器,用一臺處理全文內容更新,另外9臺對外提供檢索。當全文內容更新後,通過rsyncd這樣的同步複製,把更新後的內容同步到9臺檢索伺服器去,供使用者檢索。

  至於負載,10臺伺服器都有了,再花幾萬塊錢買臺均衡交換機(比如aleton)也沒有太大難處吧?

  2、檢索壓力小,全文內容的更新量大。

  在單臺伺服器下面,可能就是表現在你的全文庫分散在不同的目錄下面(比如/full/app1、/full/app2.。),想檢索的時候能檢索所有的全文記錄,而不是某一目錄(比如/full/app1),是否?

  也就是說,你希望用9臺伺服器來處理全文的增加,比如一臺伺服器對應一個應用。如果採用NAS(或是其它高速的儲存解決方案),或是rsyncd這類同步複製,在任何一個全文伺服器有更新後,及時的把這臺的更新內容同步到用於檢索的10伺服器上。

  在檢索的這臺伺服器上,如同單一伺服器一樣,同步後的資料按伺服器儲存在不同目錄下,而lucene檢索時,好象它的api是支援多目錄檢索的。

  另:

  我覺得你的需求,實際上沒有必要扯到“分佈”上面去,如果能在儲存上花點功夫,比如選擇一個比較好的統一儲存方案,或是實現儲存的“主–映象”同步複製,也許就不是問題了。

  對於儲存引出來的傳輸效能問題,你可以在構建網路的時候考慮一下,比如在每個伺服器上多加網絡卡,用光口或是GE口構建一個專門的“傳輸網路”,避免與“業務網路”、“管理網路”這類塞車,在傳輸上的問題應該影響不大。

  我做的分散式lucene搜尋,可以把資料來源分時間建到不同機器上,每臺機器做個seachserver,web伺服器同時向各個seachserver傳送請求,10臺seachserver同時查詢,返回查詢條數再從最近的索引庫返回結果,翻頁的話判斷每個每臺seacherserver的條數,以時間最近的機器返回結果!