4
ArcGISScriptingおよび大規模な空間データセットのパフォーマンス
現在、arcgisscriptingモジュールを使用して、少数のテーブル(合計8つ)で正規化されたかなり大きなデータセット(合計で約10,000レコード)を処理するPythonスクリプトを作成しています。このプロセスは、座標タプル(x、y)に基づいて機能を作成し、他の7つの表にある関係を使用してグラフ(ノードと線)を作成することで構成されます。最終的な出力は、関係を視覚的に表すノードおよびエッジの空間データセットを持つパーソナルジオデータベース(pgdb / fgdb)です。 私の最初の試みは、新しいジオデータベーステーブルとSearchCursorレコードセットのクエリを使用して、発生する多対多のリレーションシップのリンクテーブル(InsertCursor)を作成することでした。15〜20分の処理時間を除いて、これは非常にうまく機能しました。 PythonでcProfilerモジュールを使用すると、検索クエリを実行してリンクテーブルにカーソル(検索カーソルと挿入カーソル)の要求を取り込むときにパーソナルジオデータベースを「スラッシング」すると、パフォーマンスがひどくなります。 少しのリファクタリングで、処理時間を2.5分未満に抑えることができました。トレードオフは、コードでのジオデータベーススキーマの部分的な構築と、すべての関係が照合された後のarcgisscriptingカーソルの要求をInsertCursorsに制限することでした。 私の質問はパフォーマンスです。 大規模なデータセットを扱う際に、合理的な計算時間を維持するために人々が使用したテクニックは何ですか? 最適化の検索で見逃したESRI推奨の方法はありますか? 特にパーソナルジオデータベースからの場合は、アークギスクリプティングカーソルを作成するときに発生するオーバーヘッドを理解していますが、このサイトとGoogleからパフォーマンスに関連する回答を長時間検索した後、パフォーマンスは人々の努力の最前線ではないという印象を受けています。 ESRI製品のユーザーとして、これらのパフォーマンスラグを予想し、容認しますか? 更新 この製品でいくつかの作業を行った後、空間情報を適切な形式からジオデータベースに変換するプロセスを採用した最適化手法のリストを蓄積しました。これは、パーソナルジオデータベースおよびファイルジオデータベース用に開発されました。ちょっとしたこと: データを読み取り、メモリ内で合理化します。これにより、時間を半分に短縮できます。 メモリ内にフィーチャクラスとテーブルを作成します。フィーチャデータセットキーワーク「in_memory」を使用してメモリをRAMディスクとして使用し、そこで機能を実行してからディスクに書き込みます ディスクに書き出すには、フィーチャクラスにはCopyFeatureclassを使用し、テーブルにはCopyRowを使用します。 これら3つのことには、100,000以上のフィーチャを30分から30〜40秒にジオデータベースに変換するスクリプトが必要でした。これには、リレーションシップクラスが含まれます。それらは軽く使用されるべきではありません。上記の方法のほとんどは大量のメモリを使用するため、注意を払っていないと問題が発生する可能性があります。