空間數據全文檢索初步設計和實現

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

1.背景

        地圖的基礎功能之一便爲搜索，而搜索又分爲正向搜索和逆向搜索。所謂正向搜索即輸入關鍵字後將匹配結果進行展現，而逆向搜索則指經過位置座標來反向查詢附近的POI。

        傳統方案中，咱們將須要支持查詢數據發佈成地理編碼服務，基於該服務來完成搜索。可是隨着數據的不斷豐富，點、線、面數據不斷累積，業務相關數據不斷增長，單純的興趣點搜索已不能徹底知足需求，而相似百度的全文檢索才更能知足用戶的需求。

        針對此狀況，咱們分別設計了正向和逆向的全文檢索方案。

2.數據存儲驗證

        在最初方案中，咱們考慮用ES來整合全部空間數據以支持全文的快速查詢，可是考慮ES的環境各項目須要預裝，無疑增長了項目的實施複雜度，因此咱們將目光又轉移回咱們各項目已廣泛安裝的PG上。

        因爲PG的geometry字段能夠同時寫入點、線、面，這樣咱們能夠將全部待檢索的空間數據整合至一張表中。在測試中，咱們將某市的所有空間數據經過編寫工具整合，一共250萬條，全文正向搜索能夠控制在1S之內，創建gist索引後，一公里內的逆向查詢也能控制在1S內，都可以知足要求。

3.正向查詢設計

        觀察百度的搜索，其搜索結果是進行了分類的。好比收索五一，其即會出現五一勞動節，也會出現五一大道，即其返回的結果並非徹底按照命中度大小來排列，而是類型+命中度等一些列加權後進行的結果排列。

        這裏我不討論其算法的實現，僅借鑑其分類思想，如正向搜索中，若是輸入一個關鍵字，應該在每個分頁中對各種型數據均列出一兩個知足的。可是，若是咱們將全部類型數據整合至一張表，由於同時既要分頁，又要分類，那麼對大表總體查詢其性能必然會有必定影響。咱們作了以下設計：

        a.按照大類將數據分別拆分至對應表中，查詢時，分別觸發對這幾張表的搜索，因爲咱們定義的大類目前只有四類，即四張表，雖然須要多表查詢，可是性能比以前是有提高的。

        b.因爲每種類型，知足條件的結果個數並不會一致，分頁上沒法保證每頁出現的各種數據同樣多。這裏咱們採用每頁內容數支持浮動的方案。好比，第一頁能夠作到每種類型興趣點均有兩個，可是第二頁中，因爲部分類型興趣點無，這第二頁中展現其餘幾種興趣點數據等等，且每頁興趣點的總數無需一致（以便於後臺對結果的組織）。

        c.對一些類型數據優先展現，好比道路等。

        d.爲減小搜索時數據返回量，檢索時僅返回類型和編碼以及描述。當鼠標移入到POI上時，則觸發二次請求以獲取POI詳細信息。

        如下爲目前全文檢索實現結果：

 

4.逆向查詢設計

        谷歌地圖中提供了點擊地圖時，彈出一個搜索框，能夠搜索周邊數據。借用該設計邏輯，同時爲了減小數據查詢次數，咱們將設計規定爲以下：

        a.經過配置以肯定是否開啓逆向搜索開關，並點擊該開關才最終開啓逆向搜索功能。

        b.每一次搜索時，默認只搜索POI數據。

        c.切換分類面板時，才觸發對應類型的查詢。

        d.定義好前端接受的數據格式，支持第三方的查詢URL快速接入。

        最終實現結果以下：

 

 

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

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