1つではなく複数のファイルジオデータベースを使用したArcGIS Engineのパフォーマンス?


11

ArcGIS Engineアプリケーションのデータを整理する最適な方法を決定しようとしています。特に地図の表示とクエリの速度に興味があります。現在、すべてのデータをテーマに基づいて個別のファイルジオデータベースに分割しています。Transportation.gdb、Utilities.gdbなどがあります。データは必ずしもテーマに基づいて整理する必要はなく、すべてを1つのファイルジオデータベースに入れることを検討しています。

私は自分でテストを行いますが、コミュニティに質問を投げかけたかったのです。

一般に、単一のファイルジオデータベースの使用は、複数(約7)の小さいジオデータベースの使用よりも高速ですか?他の賛否両論にも興味があります。

注:ソフトウェアとすべてのデータは、お客様のローカルマシンにあります。Web上またはネットワーク経由でデータが提供されず、データ量がかなり少ない(約100,000個の機能)。

回答:


5

別の方法で説明しますが、実際、いや、説明したこの特定のユースケースのGeoDatabaseを分離することは、パフォーマンスの向上にはなりません

DBへの接続にはコストがかかることを覚えておく必要があります。GeoDatabaseの場合、関連するすべてのメタデータテーブルをロードしています。したがって、データを複数のGDBに分割するときはいつでも、コストを増やすだけです。これは、これらのテーブルの複数のバージョン(DBごとに1つ)を開く必要があるためです。異なるDBを照会するための多重化は、通常、無効化されるキャッシュとの入出力を意味する場合もあります。

それでも、複数のDBを使用する方が適切な場合がいくつかあります。例えば。個々のgdb(filegdbではない)が700MBであるのに対し、2つが350MBである場合を考えてみましょう。MS Jetドライバ(.mdbファイルとのやり取りに使用されるもの)は、500MB未満のメモリマップファイルをメモリします。したがって、マシンに十分なメモリがある場合、メモリとすべてのディスクI / OでDBと完全にやり取りします。はるかに高速。700MBファイルはメモリマップされません。

このケースを方程式から外すと、dbを個別に実行する意味がなくなります。ArcMapはレイヤーをループしているため、各レイヤーを順番にクエリするため、並列処理は行われません。

代わりにFileGDBインデックスを再構築することをお勧めします。

はい、SSDは間違いなく役立ちます。


1
ああ。<500mb .mdbのメモリマッピングは興味深いものです。私は個人的なgdbを、arcgisで必要な痛みを伴うコピーと削除の追加プロセスではなく、ms-accessのフィールドの並べ替えと名前変更以外には何も良くないと書いていました。たぶん今、私は時々それらを使用する別の理由があります。500MBのティッピングポイントファイルはディスクサイズですか?(たとえば、jpegはディスク上で30 kbになりますが、開いているときに数メガバイトのRAMを消費します)。
マットウィルキー

1
私の記憶では、これはJetエンジン自体の動作であり、ESRIトリガーではありませんでした。また、500MBよりもわずかに小さかった。ファイルサイズとメモリに関する良い質問です。私はそれがファイルサイズだったと思う-私はあなたと正直に言うと、正確に覚えていない
Ragi Yaser Burhum

4

実際には、通常は逆です。小さいデータベースはより高速にクエリします。それは、すべてを個別のファイリングキャビネットに分類するのではなく、地下の大きな山にすべてを投げた場合、より速く物を見つけることができるかどうかを尋ねるようなものです。個別のデータベースがある場合、6つのファイリングキャビネットを持っているようなもので、最初から直接無視でき、目を通す必要はありません。もちろん、これはどのデータベースにクエリが必要かを知っていることを前提としています-とにかくすべてのデータベースを調べる必要がある場合、1つの大きなデータベースが実際に高速になる可能性があります(データセット全体を最適化できるため)。


3

かつて、GISの仕様があまりよくないデバイスでArcReaderを使用して同様のセットアップを行い、GISサーバーへの安定したネットワーク接続を維持できたのは幸運でした(不安定な有線接続...)。

私は、「テーマ」や更新の頻度によって一般に破損する多数のデータベースを所有していました。私はそれらを毎日、毎月、毎年、または半年ごとに展開しました(これは空中/平面の更新スケジュールでした)。ロボコピーを介して更新されたため、これらのデバイスに不要なデータを移動したくありませんでした。

堅牢なジオデータベースレプリケーション機能がない環境にいる場合、または単に配布用のファイルジオデータベースを受け取っている場合は、この方法でデータストレージを分割することで管理が容易になる場合があります。

パフォーマンスの質問に答えるために、データストアを個別のファイルジオデータベースに分割することで速度が低下することに気付きませんでした。それは何もなかったという意味ではありませんが、もしあったとしても、人間が知覚できるものではありませんでした。これらの構成では、すべてのファイルジオデータベースが1台のハードディスク上にあることに注意してください。SCSI/ SSDデバイスに分散させると、パフォーマンスが向上する可能性があります。


2

以前、それぞれ異なる地理的領域をカバーする5つのArcGIS Server WebADF Webアプリケーションがありましたが、それらはすべて共通のデータセットを共有していました。致命的なのは、アプリがすべて動的で(何もキャッシュされていない)、数十万(実際には米国全体で数百万)に達する石油とガスの井戸があったことです。データセット全体に対してクエリを実行するのは苦痛でした。実際、通常はタイムアウトするだけです。各エリアのデータを切り取って別のデータストアに格納することで、パフォーマンスが向上し、顧客は満足しています。あなたと同じように、ファイルジオデータベースもサーバーのHDDに保存されていました。これはALOTにも役立ちました。毎晩、各ファイルジオデータベースにデータをクリップする自動化プロセスがありました。

正確な答えではありませんが、あなたが考えていることと似たようなケーススタディです。それほど多くの動的な機能を扱う必要がなければ、そうする必要はなかったでしょう。時々、普通とは少し違うことをする必要があります。


答えてくれてありがとう。私の状況とは完全には一致しませんが、同様の状況にある他の人にとっては良い洞察です。ソフトウェアと一緒にすべてのデータが顧客のローカルマシン上にあることは言及しませんでした。インターネット経由でデータが提供されていません(ソフトウェアの更新をインストールする必要がある場合を除く)。また、作業しているデータの量は、作業していた量のごく一部です。
タナー

4
あなたがウェブ上でサービスを提供しているとは思いませんでしたが、ネットワーク共有にFGDBを配置しても、データがパイプを通過することで速度が低下する可能性があります。巨大なデータセットを使用していない場合、個別のFGDBで十分な効果が得られるとは思いません。価値があるというよりも苦痛になるかもしれません。
チャドクーパー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.