GeoDjango：加速GEOS的幾何操作

我正在使用GeoDjango + PostGIS開發空間排名應用程序。基本上，它會檢索查詢邊界框內的所有幾何，使用我創建的自定義函數計算相似度分數，然後返回具有最高分數的形狀。GeoDjango：加速GEOS的幾何操作

目前每個查詢的往返時間都很慢。正在運行的分析器顯示瓶頸來自threadsafe.py，在我的相似度函數內部被GEOSGeometry操作（即相交，聯合，包含等）調用。以下是來自單個查詢的示例profiler result。看起來GEOSGeometry的線程安全性質是造成性能問題的原因。單獨來說，40ms的操作看起來並不是什麼大問題，但是因爲與查詢比較的形狀數量通常很大，即〜1000個形狀，所以40ms的操作總計達40秒。

因此，我的問題是如何優化功能以最小化週轉時間。我的一些初步設想是：

關閉/避免GEOSGeometry的theadsafety檢查，因爲這些物體是短暫的，不共享任何其他線程。如果可能的話，這將是理想的情況，因爲現在花費的大部分時間在threadsafe.py
使用另一個幾何非API的幾何API。
~~在PostGIS級別而不是對象級別執行空間操作。這會使代碼看起來很醜陋。~~ （更新：此選項不起作用單獨的SQL查詢的開銷，使操作更慢。）

什麼是你的想法？

來源

2011-07-05 ejel

我試着用'GDALGeometry'附帶GeoDjango內置作爲替代'GEOSGeometry'。 'GDALGeometry'原來依賴於threadsafe.py，結果執行得更糟。 – ejel

我們轉而使用shapely進行地理位置操作。它讓我們圍繞線程安全問題。

僅供參考，身材勻稱使用長，土地增值稅，而不是緯度，長的很像GeoDjango內置確實

來源

2011-09-17 23:33:14

由於它的空間操作取決於GEOS，我認爲它應該遭受同樣的問題。有趣。我會試一試。 – ejel

你有沒有設法使用geodjango模型勻稱？ – linqu

實際上，threadsafe.py只是將每個調用包裝到底層的C函數中。要更好地瞭解您的瓶頸，請查看cumtime列。請參閱此處以獲取列的說明：http://docs.python.org/library/profile.html#module-pstats。

來源

2011-07-05 22:44:28 arghbleargh

你說得對，'threadsafe.py'是C函數的一個包裝。我已經仔細檢查了配置文件的結果，並且'threadsafe.py'仍然是瓶頸。我的意思是，每次調用空間操作（例如相交，內聯合）時都會調用它。實際上在這些操作中花費的時間與線程安全所花的時間相比非常小。這就是爲什麼我想如果我可以避免使用線程安全，問題就可以解決。 – ejel

看着你的分析器結果，它 – arghbleargh

GeoDjango：加速GEOS的幾何操作

回答

相關問題