3

GeoDjango + PostGIS を使用して空間ランキング アプリケーションを開発しています。基本的には、クエリのバウンディング ボックス内のすべてのジオメトリを取得し、作成したカスタム関数を使用して類似度スコアを計算し、スコアが最も高い形状を返します。

現在、各クエリの往復時間は非常に遅いです。プロファイラーを実行すると、類似度関数内の操作 (つまり、交差、結合、含むなど)threadsafe.pyによって呼び出されるボトルネックが示されます。単一のクエリからのプロファイラーの結果GEOSGeometryの例を次に示します。のスレッドセーフな性質が、ここでパフォーマンスの問題を引き起こしているようです。個々に、40 ミリ秒かかる操作は大したことではないように見えますが、クエリと比較する形状の数は通常、1000 までの形状など、非常に多いため、40 ミリ秒の操作は合計で 40 秒になります。GEOSGeometry

したがって、私の質問は、ターンアラウンド タイムを最小限に抑えるために機能を最適化するにはどうすればよいかということです。私の最初のアイデアのいくつかは次のとおりです。

  1. GEOSGeometryこれらのオブジェクトは一時的なものであり、他のスレッドと共有されないため、 の adsafety チェックをオフにするか、回避してください。可能であれば、これは理想的なケースです。現在費やされている時間の大部分はthreadsafe.py
  2. トレッドセーフではない別のジオメトリ API を使用してください。
  3. オブジェクト レベルではなく、PostGIS レベルで空間操作を実行します。ただし、これによりコードが見苦しくなります。(更新:このオプションは機能しません。SQL クエリのオーバーヘッドだけで操作がさらに遅くなります。)

どう思いますか？

4

2 に答える 2

1

geos オペレーションにshapelyを使用するように切り替えました。これにより、スレッドセーフの問題を回避できました。

参考までに、GeoDjango のように lat,long ではなく long,lat を適切に使用します

于 2011-09-17T23:33:14.717 に答える
0

実際にthreadsafe.pyは、基礎となるC関数への各呼び出しをラップしているだけです。ボトルネックが何であるかについてのより良いアイデアについては、cumtimeコラムを見てください。列の説明については、http：//docs.python.org/library/profile.html#module-pstatsを参照してください。

于 2011-07-05T22:44:28.383 に答える