2011-04-05 62 views
8

上下文Lucene/Solr如何在多領域/多面搜索中實現高性能?

這是一個主要關於Lucene(或可能是Solr)內部問題。主題是分面搜索,其中搜索可以沿着對象的多個獨立維度(方面)(例如大小,速度,汽車的價格)發生。

當與關係數據庫一起實現時,對於大量方面而言,多字段索引沒有用處,因爲可以按任意順序搜索方面,因此使用具有低可能性的特定有序多索引並創建所有可能的指數的排序是無法忍受的。

Solr被廣告應對多面搜索任務,如果我認爲正確必須與Lucene連接(假定)在多字段查詢(文檔的字段與對象的facet相關) 。

問題

倒排索引的Lucene的可以存儲在關係數據庫中,並以自然的匹配文件的交點也可以用單場指數RDBMS來實現平凡。

因此,Lucene假設除了基於倒排索引的交叉匹配文檔之外,還有一些用於多字段查詢的高級技術。

所以問題是,這個技巧/竅門是什麼?更廣泛地說:爲什麼Lucene/Solr理論上可以實現比RDBMS更好的分面搜索性能(如果是這樣)?

注意:我的第一個猜測是Lucene會使用一些空間分區方法來劃分從文檔字段構建的向量空間作爲維度,但據我瞭解,Lucene不是純粹的基於向量空間的。

回答

5

FACETING

有兩個答案的小面,因爲有兩種類型的刻面。我不確定這些中的任何一個都比RDBMS更快。

  1. Enum faceting。查詢結果是一個位向量,如果第i個文檔匹配,則第i位爲1。該方面也是一個位矢量,所以交集只是一個按位與。我不認爲這是一種新穎的方法,大多數RDBMS可能支持它。
  2. 字段緩存。這只是一個正常的(非反轉)索引。那在這裏運行SQL風格的查詢是這樣的:

    選擇方面,從field_cache COUNT(*),其中的docId在query_results 組由小

同樣,我不認爲這是任何正常的RDBMS無法做到的事情。索引是一個跳過列表,以docId爲關鍵。

多搜索項搜索

這是Lucene的眼前一亮。爲什麼Lucene的方法非常好,在這裏發佈的時間太長,但我可以推薦this post on Lucene Performance或其中鏈接的論文。

+0

謝謝。您指向的帖子寫道:「對Lucene的真正優化來自於這樣一個事實,即您從不搜索與查詢匹配的所有文檔,而是搜索頂部k。」。在多面搜索的情況下,我認爲所有比賽都必須考慮在內。 – ron 2011-04-06 16:13:31

+0

@ron:是的,我不知道Lucene的分面查詢性能非常好。但我不是這方面的專家。 – Xodarap 2011-04-06 23:45:38

3

的解釋後,可以發現在:http://yonik.wordpress.com/2008/11/25/solr-faceted-search-performance-improvements/

新的方法通過非反向索引字段是多方面,允許在該領域的術語快速查找任何給定的文件。這實際上是一種混合方法 - 爲了節省內存並提高速度,出現在許多文檔中的術語(超過5%)不是非反轉的,而是使用傳統的集合交集邏輯來獲取計數。