1. 程式人生 > >深入淺出空間索引:為什麼需要空間索引

深入淺出空間索引:為什麼需要空間索引

一、問題

  先思考個常見的問題:如何根據自己所在位置查詢來查詢附近50米的POI(point of interest,比如商家、景點等)呢(圖1a)?

每個POI都有經緯度資訊,我用圖1b的SQL語句在mySQL中建立了POI_spatial的表,其中lat和lng兩個欄位來代表緯度和經度。為後續分析方便起見,我人造了40萬個POI資料。

 二、傳統的解決思路

方法一:暴力方法

  該方法的思路很直接:計算位置與所有POI的距離,並保留距離小於50米的POI。

  插句題外話,計算經緯度之間的距離不能像求歐式距離那樣平方開根號,因為地球是個不規整的球體(圖2a),按最簡單的完美球體假設,兩點之間的距離函式應該如圖2b所示。

   該方法的複雜度為:40萬*距離函式。我們將球體距離函式寫為mysql儲存過程distance,之後我們執行查詢操作(圖3),發現花費了4.66秒。

該方法耗時的原因顯而易見,執行了40萬次複雜的距離計算函式。

方法二:矩形過濾方法

  該方法分為兩部:

  a)先用矩形框過濾(圖4a),判斷一個點在矩形框內很簡單,只要進行兩次判斷(LtMin<lat<LtMax; LnMin<lng<LnMax),落在矩形框內的POI個數為n(n<<40萬);

  b)用球面距離公式計算位置與矩形框內n個POI的距離(圖4b),並保留距離小於50米的POI

  矩形過濾方法的複雜度為:40萬*矩形過濾函式 + n*距離函式(n<<40萬)。

  根據這個思路我們執行SQl查詢(圖5)(注: 經度或緯度每隔0.001度,距離相差約100米,由此推算出矩形左下角和右上角座標),發現過濾後正好剩下兩個POI。

  此查詢花費了0.36秒,相比於方法一查詢時間大大降低,但是對於一次查詢來說還是很長。時間長的原因在於遍歷了40萬次。

方法三:B樹對經度或緯度建立索引

  方法二耗時的原因在於執行了遍歷操作,為了不進行遍歷,我們自然想到了索引。我們對緯度進行了B樹索引。

  此方法包括三個步驟:

  a)通過B樹快速找到某緯度範圍的POI(圖6a),個數為m(m<40萬),複雜度為Log(40萬)*過濾函式;

  b)在步驟a過濾得到的m個POI中查詢某經度範圍的POI(圖6b),個數為n(n<m),複雜度為m*過濾函式;

  c) 用球面距離公式計算位置與步驟b得到的n個POI的距離(圖6c),並保留距離小於50米的POI

  執行SQL查詢(圖7),發現時間已經大大降低,從方法2的0.36秒下降到0.01秒。

三、B樹能索引空間資料嗎?

  這時候有人會說了:“方法三效果如此好,能夠滿足我們附近POI查詢問題啊,看來B樹用來索引空間資料也是可以的嘛!”

  那麼B樹真的能夠索引空間資料嗎?

1)只能對經度或緯度索引(一維索引),與期望的不符

  我們期待的是快速找出落在某一空間範圍的POI(如矩形)(圖8a),而不是快速找出落在某緯度或經度範圍的POI(圖8b),想象一下,我要查詢北京某區的POI,但是B樹索引不僅給我找出了北京的,還有與北京同一維度的天津、大同、甚至國外城市的POI,當資料量很大時,效率很低。

2)當資料是多維,比如三維(x,y,z),B樹怎麼索引?

  比如z可能是高程值,也可能是時間。有人會說B樹其實可以對多個欄位進行索引,但這時需要指定優先順序,形成一個組合欄位,而空間資料在各個維度方向上不存在優先順序,我們不能說緯度比經度更重要,也不能說緯度比高程更重要。

3)當空間資料不是點,而是線(道路、地鐵、河流等),面(行政區邊界、建築物等),B樹怎麼索引?

  對於面來說,它由一系列首尾相連的經緯度座標點組成,一個面可能有成百上千個座標,這時資料庫怎麼儲存,B樹怎麼索引,這些都是問題。

  既然傳統的索引不能很好的索引空間資料,我們自然需要一種方法能對空間資料進行索引,即空間索引。

下節將對空間索引分類體系、原理、優缺點及資料庫支援情況進行闡述(正在寫)。