2011-09-08 44 views
0

對於我們的客戶之一,我們提供了一個系統,用於從用戶郵政編碼位置檢索最近的N個地標。 我們有一個數據庫,包含所有可用的郵政編碼(650,000+)以及相應的座標(經度和緯度)以及全國400多個地標。在地圖上優化搜索

現在我們使用的是從尋找最近ñ地標

以下過程
  1. 檢索選定郵編
  2. 的緯度和經度通過使用獲取所有的地標座標
  3. 令他們地理距離公式
  4. 取最接近的N + 2個地標,並使用以下過程獲得與它們的實際距離
    • 檢查是否座標之間的距離存儲在距離緩存表
    • 如果不是去一個地圖引擎,檢索緩存中的
  5. 的距離,並將其存儲重新排序列表,並返回前N個最接近的地標

問題是我們需要從數據庫訪問角度和第三方訪問都優化這一點。

我們試圖緩存所有郵編到距離最近的M個地標的距離,但該表會獲得額外的6Gb數據,並且需要大約250天的時間才能填充,因爲請求需要約30秒。

我們正在考慮對數據進行分區並將緊密郵編編組在一起,但這會使確切的距離無效。

什麼優化解決方案,你看到在這種情況下。 謝謝。

回答

1

你可以嘗試重複的方法。

  1. 選擇通過所有結果作爲你的「半徑」
  2. 去使用,並挑選唯一的+值 - 半徑水平和垂直方向(根據地理位置
  3. 如果沒有足夠的行返回,增加「半徑」並再次開始
  4. 現在執行距離計算,並使用一個PriorityQueue,以儘量減少在這種計算中使用的號碼,並選擇所需的項目
+0

這是具有里程碑意義的aprox的距離很好的優化,但是我們需要確切的道路距離,因此額外的步驟,以第三方供應商是仍然需要。 – Pasman

+0

噢,你可以保持這種優化,只有半徑比實際要求的大3倍,但如果要達到7英里以外的點,你需要行駛21英里以上。對於距離計算,你的緩存方法非常好,但是找到距離提供者的距離的30秒看起來非常緩慢...... – Kurru

+0

我想它會成爲你的最佳改進 – Kurru

1

這應該在數據庫 - 水平來完成。ÿ ou應該使用具有地理擴展名的數據庫作爲SQL Server 2008 R2,或者優秀的開源選擇PostGre SQL和PostGIS擴展。有了那些你存儲地理BLOB而不是座標,並且有許多內置的函數可以計算出地理位置,爲你處理第2步到第5步。

我建議你從這裏開始: http://postgis.refractions.net/

問候

+0

問題是我們需要通過公路距離進行精確的旅行,這就是爲什麼我們在最後一步依靠谷歌地圖和雅虎地圖。數據庫部分運行非常流暢。這很可能是創建高速緩存的問題,所以我們不需要去Google/Yahoo – Pasman