ArcGIS Pro では、ローカル データ (ファイル ジオデータベースやモバイル ジオデータベースなど) とリモート データ (エンタープライズ ジオデータベースやサービス データ (Web レイヤー) など) をどちらも使用できます。
一度に 1 人のユーザーまたは 1 つのプロセスだけがデータにアクセスする場合は、クライアントに対してローカルなデータを使用することができます。 一方で、複数のユーザーがデータにアクセスする必要のあるエンタープライズ システムの場合は、データを中央の場所に格納する必要があります。 この場所は、アクセスするほとんどのユーザーとクライアントからリモートになります。
リモート データには、独自の需要があります。 同時に複数のユーザーがアクセスする場合のリモート データの使用方法を評価する必要があります。 ArcGIS Pro とリモート データ ソース間のデータ転送は遅延感度が高いため、データの表示および編集中やデータ スキーマの操作および変更中に小規模なリクエストが多数発生します。 通常は 1 人のユーザーだけがアクセスするローカル データとは異なり、実行時間の長いデータベース クエリはリモート データのすべてのユーザーに影響を与えます。 このため、マップがどのように ArcGIS Pro で作成されて、リモート データ ソースとして使用されるかを考慮することが特に重要となります。
ヒント:
このトピックと関連リンクでは、ArcGIS Pro に固有のパターンと演習に重点が置かれています。 ArcGIS システム全体を設計して実装するための推奨パターンと演習については、ArcGIS Architecture Center をご覧ください。
ローカル データ ソース
ローカル データ ソースは、データにアクセスするクライアントが実行されているコンピューターと同じコンピューターに格納されているデータ ソースです。 モバイル ジオデータベース、Open Geospatial Consortium (OGC) GeoPackage ファイル、ファイル ジオデータベース、シェープファイル、SQLite データベースなど、ほとんどのローカル データ ソースは、同時に複数のユーザーが使用できるように設計されていません。
データが格納されているコンピューター上でクライアントから 1 人のユーザーがデータにアクセスする場合は、クライアントとデータ ソース間のネットワーク遅延が短くなります。 ネットワーク遅延が短いだけでなく、ローカル データにアクセスする複数のユーザー間で競合がほとんど発生しないか、まったく発生しません。 つまり、使用可能なすべてのリソースを 1 つのクライアント専用にすることができるため、データ ソースで強制されているロックやその他のメカニズムによってデータの取得に遅延が生じることがありません。
リモート データ ソース
リモート データ ソースは、データにアクセスするクライアントと同じコンピューター上で実行されていないデータ ソースです。 すべてのクラウド データ ウェアハウスとほとんどのリレーショナル データベースはこのカテゴリに分類されます。 クライアントがデータからどれだけ離れているか (つまり、クライアントとデータの間にどれだけ物理的な隔たりがあるか) によって、クライアントとデータの間でのクエリの送信にかかる時間が変わってきます。 たとえば、ローカル コンピューターとローカル ネットワーク上で ArcGIS Pro を使用して、建物内のサーバー ルームに配置されているコンピューター上で実行されているデータベース内のデータにアクセスする場合、ローカル インストールを使用して、クラウドに配置されているデータベースにアクセスする場合ほど時間がかかることはまずありません。
データと ArcGIS Pro の場所がパフォーマンスに与える影響の詳細
ネットワーク遅延は、ローカル データ ソースよりもリモート データ ソースの方がはるかに長くなり、ネットワークの速度とスループットもパフォーマンスに影響を与えます。
低速の転送プロトコル (HTTP など) とハードウェアを使用してリモート データにアクセスする場合、データは遅い転送速度で遠くまで移動しなければなりません。 この遅延がパフォーマンスやスケーラビリティ上の問題の根本原因になることはほとんどありませんが、リモート データ ソースに準拠したワークフローは、高頻度または大規模なデータ アクセス リクエストに大きく影響されます。 マルチユーザー環境のデータ サーバーは、同時に複数のユーザーが共有できる 1 つまたは一連のリソースです。 マップとワークフローを設計する際には、システムのすべてのユーザーのアクションを考慮する必要があります。 可能な限りリクエストの総数とリクエストのサイズを削減する手法が採用されていない場合は、十分に設計されたシステムであっても、データ アクセス リクエストが殺到することがあります。