WebGIS中解決使用Lucene進行興趣點搜索排序的兩種思路

文章版權由做者李曉暉和博客園共有，若轉載請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/。

1.背景

目前跟信息採集相關的一個項目提出了這樣的一個需求：中國銀行等一些部門和政府關係較好，須要在興趣點搜索時優先顯示他們。

咱們的興趣點查詢是使用的Lucene進行分詞查詢的，這涉及到咱們要對咱們搜索出來的結果進行一次優先級排序。這裏，我和你們一塊兒探討解決此問題的兩種方案。

2.字典創立時對字典文檔設置優先級

2.1.經過Document的setBoost來創建文檔優先級

在Lucene4.0前，Document能夠經過setBoost來設立文檔的優先級。流程圖爲：

                       

可是，此方法在Lucene4.0以後不能使用，由於此以後去掉了Document能夠直接setBoost的方法。

2.2.經過對數據源進行排序來解決創建字典文檔優先級

在項目中，數據存放在數據庫中，索引是創建在數據庫的該興趣點表上，因而咱們能夠改變咱們的思路，即直接對查詢所得的數據先進行排序，而後再創建索引。

下面咱們具體講下實施方案。

2.2.1.修改興趣點表，增長排序字段

 

這裏，咱們增長了一個ORDERINDEX排序字段。

2.2.2.在代碼中對數據源進行排序，而後生成字典

 

2.2.3.測試例子

符合郵局關鍵字段的數據有多個，咱們將北新橋郵局後面的ORDERINDEX修改成1，若是咱們輸入郵局，能將北新橋郵局後門首先返回，則表示方法成功。

 

結果展現：

 

3. 分詞查詢時，經過設置query 影響排序

3.1.思路分析

咱們首先能夠在建立Document時，增長一個field。該field默認值爲false。當咱們須要建立的字符串知足優先查詢字符串時，則將該field的值改成true.

而後，再建立查詢條件時，增長一個創建在field的查詢條件，該查詢條件爲should型，查詢值爲true，而且設置其對query的影響爲低。

流程圖爲：

 

3.2.具體實現

3.2.1增長類score字段

 

3.2.2增長query影響條件

 

4.總結

在代碼中經過setBoost有以下幾個缺點：

a.增長了代碼開發量

b.在構建索引字典中遍歷是否知足優先條件，比較耗時。

鑑於以上缺點，選擇直接經過數據源排序構建索引字典是比較好的方式。

5.擴展

因爲Lucene中分詞的粒度很難控制，好比郵局二字。當咱們輸入郵或者郵局時，是能夠有查詢結果的。可是輸入局時卻不能。

針對此種問題，基於Lucene的分詞條件進行修改和擴展，是能根本解決問題的方法之一，可是學習成本略大。

此處我選擇了一種折中的方式來解決，即分詞查詢後判斷查詢結果是否爲空，若是是空，則觸發數據庫查詢。

固然，觸發數據庫查詢的前提是，興趣點不能過多。通常項目中興趣點均在10W之內，因此數據庫查詢消耗時間是有限的。

而爲何不直接使用數據庫查詢是在於：

a.分詞查詢能夠加速查詢效率。

b.分詞查詢避免數據庫查詢使用過多的like關鍵字。

c.分詞查詢能夠創建對拼音檢索的支持。

 

                                                                 -----歡迎轉載，但保留版權，請於明顯處標明出處：http://www.cnblogs.com/naaoveGIS/

                                                                           若是您以爲本文確實幫助了您，能夠微信掃一掃，進行小額的打賞和鼓勵，謝謝 ^_^