使用solr搭建搜尋引擎很容易,但是如何制定合理的打分規則(boost)做排序卻是乙個很頭痛的事情。solr本身的排序打分規則是繼承自 lucene的文字相關度的打分即boost,這一套演算法對於通用的提供全文檢索的服務來講,已經夠用了,但是對於一些專門領域的搜尋來講,文字相關度的 打分是不合適的。
如何來定製適合自身業務的排序打分規則(boost)呢?經過這段時間的思考與實踐,想到了如下三個方法
上面每一種方法都有其優劣,下面分析一下各自的優劣。
下面結合最近使用solr的實踐,著重介紹一下通過使用solr的dismaxqparserplugin通過配置來制定結果文件打分規則。
dismaxqparserplugin提供在針對文字boost打分上,支援搜尋多個schema索引字段,並針對每乙個字段設定不同的boost許可權。
pf查詢 與 qf查詢
pf:可提供對一條記錄的多個欄位做匹配的功能
qf:針對查詢的每個字段設定不同的boost權重打分,其設定的字段必須為在pf中配置的項。
edismax上面一段的意思是,查詢name,info,title三個字段,每個欄位的文字相關度打分權重分別為1,0.8,0.6。計算查詢出的每一條結果的權重方法如下:分別計算各字段的文字打分然後乘於配置的權重,最後三者相加即為該結果的boost得分。name info title
name^1 info^0.8 title^0.6
bf查詢
除去pf查詢,qf查詢之外,仍然希望索引記錄的其它字段能夠計入打分中,這時可以使用bf查詢。bf查詢支援一些資料函式,這些函式可作用在索引記錄的字段上,多為時間,數值等字段。同樣bf也支援新增權重。下面是乙個使用bf查詢配置的例子:
edismaxsum(recip(ms(now,created_time),3.16e-11,1,1),sqrt(log(max(sales,1))),sqrt(log(count)))^10
name info title
name^1 info^0.8 title^0.6
其中sum,recip,ms,sqrt,
log,max這些都是solr提供的數學方法,支援的所有數學方法可在這裡查詢到:
edismax相關資源:
Lucene打分規則
搜尋排序結果的控制 lucnen作為搜尋引擎中,應用最為廣泛和成功的開源框架,它對搜尋結果的排序,有一套十分完整的機制來控制 但我們控制搜尋結果排序的目的永遠只有乙個,那就是資訊過濾,讓使用者快速,準確的找到其想要的結果,豐富使用者體驗。以前看過乙個牛人的部落格,總結了4個地方,可對lucene檢索...
提高solr的搜尋速度
之前是使用12台機分布式搜尋,1台為主機做索引並分發給子機,8臺做大索引搜尋服務,3 臺做小索引搜尋服務,配置基本是內存在4 8g,cpu 2 8core的伺服器,索引的大小為8g。搜尋的響應時間 是150ms左右。使用solr架構的搜尋服務 在一次技術群中,中聽到一位sina的架構師,他們是採用基...
基於Solr的空間搜尋 3
本文將繼續介紹基於solr的地理位置搜尋的第二種實現方案 cartesiantiers geohash 從基於solr的地理位置搜尋 2 文章中可以看到完全基於geohash的查詢過濾,將完全遍歷整個docment文件,從效率上來看並不太合適,所以結合笛卡爾層後,能有效縮減少過濾範圍,從效能上能很大...