約80億レコードをArcGIS Utility Networkを含むPostgreSQL Enterprise Geodatabaseに移行する必要があります。データ量の制限により、同じUtility Networkに複数のバッチで増分的にデータをロードします。以下についてESRI推奨のアプローチは何ですか： * 増分バッチロード * 既存のUtility Networkへのバッチ統合 * ロード中のトポロジ管理 * 関連付けとダーティエリアの処理 * 数十億レコード規模でのパフォーマンス維持この規模のUtility Networkに関するドキュメント化されたベストプラクティス、スケーラビリティ推奨事項、またはリファレンスアーキテクチャはありますか？ご指導いただければ幸いです。

It is my understanding you are already in touch with support about the performance issues you are experiencing. You are already aware that enabling the network topology is a resource intensive process, so faster CPU, plenty of RAM, lots of storage for processing the transaction (locally and on the DBMS), and also a low-latency connection between all clients and components (client performing build, and DBMS). Best practices are practices that can be generally applied across all situations and said to be the best. You are dealing with exceptional circumstances that most customers are not likely to experience, so you are likely going to have some extraordinary hardware requirements as well as processes for managing this data load. If you need help working through these questions I recommend you reach out to an experienced business partner or Esri Professional Services to help your organization. If you are loading data in batches, it would be best if each batch was error free before loading data and that the master database is error free as well. Creating errors requires additional CPU and Memory during the build process, so reducing the number of errors before you enable the network topology will make the process more efficient. You can do think like Enabling the network topology in the batches, or use tools like Analyze Network Data to identify topology errors before you enable.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

既存のUtility Networkに約80億レコードを増分ロードするためのESRI推奨方法

JayaramBT

約80億レコードをArcGIS Utility Networkを含むPostgreSQL Enterprise Geodatabaseに移行する必要があります。データ量の制限により、同じUtility Networkに複数のバッチで増分的にデータをロードします。

以下についてESRI推奨のアプローチは何ですか：

増分バッチロード
既存のUtility Networkへのバッチ統合
ロード中のトポロジ管理
関連付けとダーティエリアの処理
数十億レコード規模でのパフォーマンス維持

この規模のUtility Networkに関するドキュメント化されたベストプラクティス、スケーラビリティ推奨事項、またはリファレンスアーキテクチャはありますか？

ご指導いただければ幸いです。

タグ付きの投稿をもっと見る

Accepted answers

RobertKrisher

お客様はすでにサポートと連絡を取っており、現在経験しているパフォーマンスの問題について話し合っていると理解しています。ネットワークトポロジーを有効にすることはリソース集約型のプロセスであることはご存知の通りですので、高速なCPU、十分なRAM、トランザクション処理用の大量のストレージ（ローカルおよびDBMS上）、そしてすべてのクライアントとコンポーネント（ビルドを実行するクライアントとDBMS）間の低遅延接続が必要です。

ベストプラクティスとは、一般的にあらゆる状況に適用でき、最良とされる方法です。お客様はほとんどの顧客が経験しない特別な状況に直面しているため、並外れたハードウェア要件やこのデータ負荷を管理するためのプロセスが必要になる可能性があります。これらの問題を解決するために支援が必要な場合は、経験豊富なビジネスパートナーやEsri Professional Servicesにご相談されることをお勧めします。

データをバッチでロードしている場合は、各バッチがロード前にエラーなしであること、そしてマスターデータベースもエラーなしであることが望ましいです。エラーがあるとビルドプロセス中に追加のCPUとメモリが必要になるため、ネットワークトポロジーを有効にする前にエラー数を減らすことで処理がより効率的になります。バッチごとにネットワークトポロジーを有効にしたり、Analyze Network Dataのようなツールを使って有効化前にトポロジーエラーを特定したりすることができます。

All comments

RobertKrisher

@JayaramBT

参照アーキテクチャはArcGIS Architecture Centerで見つけることができます。

ベストプラクティスは、ネットワークトポロジーを無効にした状態で、バージョン管理されていないジオデータベースにデータをロードすることです。これには私たちのアソシエーションも含まれます。

トポロジーエラーの処理に関するベストプラクティスは、移行中に可能な限り多くのエラーを解決し、残りのエラーはデータベースをバージョン管理として登録しネットワークトポロジーを有効にする前に解決することです。これには無効または重複したアソシエーションをインポートしていないことを確認することも含まれます。

サブネットワークのベストプラクティスは、データがトポロジー的にクリーンであり、有効で完全に接続されたサブネットワークとなるようすべてのデータ修正が、サブネットワークコントローラーをインポートし初期のサブネットワーク更新を行う前に完了していることを確認することです。

バージョン管理された環境にデータを段階的にロードすることを選択した場合、追加の考慮事項が発生しますが、最大のリスクはロード中に重複したグローバルIDやアソシエーションを導入してしまう可能性があることです。私たちは一部の検証チェックを緩和して段階的なロードを高速化していますが、その分データローダー側で不良データをロードしないよう注意する責任があります。特にトポロジーとサブネットワークが有効な場合、バージョン管理された環境へのデータロードには他にも多くの懸念や考慮点があり、そのためこれはベストプラクティスとは見なされていません。サポートはされていますが、使用予定のツールやプロセスについて慎重な検討、計画、およびテストが必要です。

JayaramBT

迅速なご返信ありがとうございます、Robert。ユーティリティネットワークに最終的に約80億件のレコードが含まれる場合でも、Esriの推奨はすべてのバッチがロードされるまでトポロジーを有効にしないことですか？それとも、移行の最後にデータ問題を発見するリスクを減らすために、定期的にトポロジーを有効化しネットワークの一部を検証することをEsriは推奨しますか？

ユーティリティネットワークのデータセットが10億件を超えたテスト済みの参照アーキテクチャ、データベースサイズ推奨、または顧客導入事例はありますか？もしあれば、どのようなロードおよびトポロジー有効化戦略が使われましたか？

以下は実際の例です:
テスト中、約3億件のレコードでネットワークトポロジーを有効にするのに約60時間かかりました。
対象データセットは最終的に約80億件に成長すると予想されています。この経験から、最終移行段階でトポロジー有効化が運用上困難になることを懸念しています。
この規模でのトポロジー有効化について、Esriから何かガイダンス、ベストプラクティス、または参照実装はありますか？
具体的には：
10億件を超えるユーティリティネットワーク展開の記録はありますか？非常に大規模なデータセットに対して段階的なトポロジー有効化戦略をEsriは推奨しますか？数十億レコード規模でのトポロジー有効化に関する既知のスケーリング特性やサイズ推奨はありますか？この規模のデータセットにはどのようなインフラ（CPU、RAM、ストレージアーキテクチャ）をEsriは推奨しますか？80億件すべてがロードされるまで待つよりも移行中に定期的な検証を推奨しますか？

「3億件で60時間かかったので、80億件では1,600時間かかる」ということでしょうか？？？

RobertKrisher

JayaramBT

ご提案ありがとうございます、Robertさん。私の懸念はデータの最終統合に関するものです。各バッチが個別にロードされる場合、複数のUtility Networkデータセットを単一のUtility Networkに統合するための推奨されるEsriの方法は何でしょうか？

具体的には：

Appendツールを使用して異なるバッチからのUtility Networkデータセットを統合できますか？
Appendが推奨されない場合、複数のUtility Networkロードを単一のEnterprise Geodatabaseに統合するためのサポートされているまたはベストプラクティスの方法は何ですか？
統合プロセス中にUtility Networkの関連付け（containment、connectivity、structural attachment）、Global IDs、およびトポロジ整合性はどのように管理すべきでしょうか？
Esriはすべてのバッチを直接同じUtility Networkデータセットにロードすることを推奨しますか、それとも各バッチごとに別々のUtility Networkを作成し後で統合することを推奨しますか？
バッチロード戦略を使用した大規模な移行時におけるパフォーマンス、スケーラビリティ、トポロジ関連の考慮事項はありますか？

この規模でのバッチベースのUtility Network移行を扱う際の推奨アプローチについて、Esriからのご指導をいただければ幸いです。

バッチ処理を選択した場合、Utility Networkデータセットをどのように統合できますか？例えば、各バッチに100件の交換が含まれている場合、あるUtility Networkデータセットから別のものへデータをどのように統合できますか？Appendツールは使えますか、それとも使えませんか？Utility Networkデータセットを統合するために利用可能な方法は何ですか？明確にし、Utility Networkデータ統合の最良アプローチをご提案ください。

RobertKrisher

前回の投稿では、データの読み込みと関連付けに必要なグローバルIDを保持する最も簡単な方法であるAppendを使用すると仮定していました。

あなたが尋ねている質問は、単なるコミュニティ投稿の範囲を超えており、コンサルティングやサービス契約に近い内容です。これらの質問に答える前に、データ移行プロセス、品質保証プロセス、アーキテクチャ、およびタイムラインについて詳細な議論が必要です。

会話に参加する

サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。

クイックリンク

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.