Nous devons migrer environ 8 milliards d'enregistrements dans une Enterprise Geodatabase PostgreSQL contenant un ArcGIS Utility Network. En raison des limitations de volume de données, les données seront chargées de manière incrémentale en plusieurs lots dans le même Utility Network. Quelle est l'approche recommandée par ESRI pour : * Chargement incrémental par lots * Fusion des lots dans un Utility Network existant * Gestion de la topologie pendant les chargements * Gestion des associations et des zones modifiées * Maintien des performances à l'échelle de milliards d'enregistrements Existe-t-il des bonnes pratiques documentées, des recommandations de scalabilité ou des architectures de référence pour des Utility Networks de cette taille ? Merci d'avance pour toute orientation.

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; } } }

Recommandation ESRI pour le chargement incrémental d'environ 8 milliards d'enregistrements dans un Utility Network existant

JayaramBT

Nous devons migrer environ 8 milliards d'enregistrements dans une Enterprise Geodatabase PostgreSQL contenant un ArcGIS Utility Network. En raison des limitations de volume de données, les données seront chargées de manière incrémentale en plusieurs lots dans le même Utility Network.

Quelle est l'approche recommandée par ESRI pour :

Chargement incrémental par lots
Fusion des lots dans un Utility Network existant
Gestion de la topologie pendant les chargements
Gestion des associations et des zones modifiées
Maintien des performances à l'échelle de milliards d'enregistrements

Existe-t-il des bonnes pratiques documentées, des recommandations de scalabilité ou des architectures de référence pour des Utility Networks de cette taille ?

Merci d'avance pour toute orientation.

Trouver plus de publications taguées avec

Accepted answers

RobertKrisher

Je comprends que vous êtes déjà en contact avec le support concernant les problèmes de performance que vous rencontrez. Vous savez déjà que l'activation de la network topology est un processus gourmand en ressources, nécessitant un processeur plus rapide, beaucoup de RAM, beaucoup d'espace de stockage pour traiter la transaction (localement et sur le DBMS), ainsi qu'une connexion à faible latence entre tous les clients et composants (client effectuant la build, et DBMS).

Les meilleures pratiques sont des pratiques généralement applicables à toutes les situations et considérées comme les meilleures. Vous faites face à des circonstances exceptionnelles que la plupart des clients ne sont pas susceptibles de rencontrer, donc vous aurez probablement des exigences matérielles extraordinaires ainsi que des processus pour gérer cette charge de données. Si vous avez besoin d'aide pour résoudre ces questions, je vous recommande de contacter un partenaire commercial expérimenté ou Esri Professional Services pour aider votre organisation.

Si vous chargez des données par lots, il serait préférable que chaque lot soit exempt d'erreurs avant de charger les données et que la base de données principale soit également sans erreur. La création d'erreurs nécessite un CPU et une mémoire supplémentaires pendant le processus de build, donc réduire le nombre d'erreurs avant d'activer la network topology rendra le processus plus efficace. Vous pouvez faire des choses comme activer la network topology par lots, ou utiliser des outils comme Analyze Network Data pour identifier les erreurs de topologie avant l'activation.

All comments

RobertKrisher

@JayaramBT

Vous pouvez trouver l'architecture de référence dans le ArcGIS Architecture Center.

La meilleure pratique consiste à charger les données dans une géodatabase non versionnée, avec la topologie réseau désactivée. Cela inclut nos associations.

La meilleure pratique pour gérer les erreurs de topologie est de résoudre autant d'entre elles que possible pendant la migration, et de résoudre le reste avant d'enregistrer la base de données comme versionnée et d'activer la topologie réseau. Cela inclut de s'assurer que vous n'importez aucune association invalide ou en double.

La meilleure pratique pour les sous-réseaux est de s'assurer que vos données sont topologiquement propres et que toutes les corrections de données pour avoir des sous-réseaux valides et entièrement connectés sont effectuées avant d'importer vos contrôleurs de sous-réseau et d'effectuer la mise à jour initiale du sous-réseau.

Si vous décidez de charger les données de manière incrémentielle dans un environnement versionné, cela entraînera des considérations supplémentaires, mais le plus grand risque que vous ajoutez est que vous pourriez introduire des ID globaux ou des associations en double lors de vos chargements. Nous maintenons les chargements incrémentiels plus rapides en assouplissant certaines de nos vérifications de validation, mais cela met également la charge sur le chargeur de données pour s'assurer qu'il ne charge pas de mauvaises données. Il y a beaucoup d'autres préoccupations et considérations lorsqu'il s'agit de charger des données dans un environnement versionné, surtout si vous avez une topologie activée et des sous-réseaux, c'est pourquoi ce n'est pas considéré comme une meilleure pratique. C'est supporté, mais nécessite une réflexion, une planification et des tests minutieux des outils et processus que vous prévoyez d'utiliser.

JayaramBT

Merci Robert pour votre réponse rapide. Si le Utility Network contient finalement environ 8 milliards d'enregistrements, la recommandation d'Esri est-elle toujours d'attendre que tous les lots soient chargés avant d'activer la topologie, ou Esri recommanderait-il d'activer périodiquement la topologie et de valider des portions du réseau afin de réduire le risque de découvrir des problèmes de données à la fin de la migration ?

Existe-t-il des architectures de référence testées, des recommandations de dimensionnement de base de données ou des implémentations clients où les ensembles de données Utility Network ont dépassé 1 milliard d'enregistrements, et si oui, quelle stratégie de chargement et d'activation de la topologie a été utilisée ?

Exemple en temps réel ci-dessous:
Lors de nos tests, l'activation de la topologie réseau sur environ 300 millions d'enregistrements a nécessité environ 60 heures pour être terminée.
Notre ensemble de données cible devrait atteindre environ 8 milliards d'enregistrements. Sur la base de cette expérience, nous craignons que l'activation de la topologie ne devienne opérationnellement difficile lors de l'étape finale de la migration.
Esri dispose-t-il de conseils, bonnes pratiques ou implémentations de référence pour l'activation de la topologie à cette échelle ?
Plus précisément :
Existe-t-il des déploiements documentés du Utility Network dépassant 1 milliard d'enregistrements ? Esri recommande-t-il une stratégie d'activation progressive de la topologie pour des ensembles de données extrêmement volumineux ? Existe-t-il des caractéristiques connues d'évolution ou des recommandations de dimensionnement pour l'activation de la topologie à des volumes multi-milliardaires ? Quelle infrastructure (CPU, RAM, architecture de stockage) Esri recommanderait-il pour des ensembles de données de cette ampleur ? Esri recommanderait-il une validation périodique pendant la migration plutôt que d'attendre que les 8 milliards d'enregistrements soient chargés ?

"300 millions ont pris 60 heures, donc 8 milliards prendront 1 600 heures."???

RobertKrisher

JayaramBT

Merci Robert pour vos suggestions. Ma préoccupation concerne la consolidation finale des données. Si chaque lot est chargé séparément, quelle est l'approche recommandée par Esri pour fusionner plusieurs ensembles de données Utility Network en un seul Utility Network ?

Plus précisément :

L'outil Append peut-il être utilisé pour fusionner des ensembles de données Utility Network provenant de différents lots ?
Si Append n'est pas recommandé, quelles sont les approches prises en charge ou les meilleures pratiques pour consolider plusieurs chargements Utility Network dans une seule Enterprise Geodatabase ?
Comment gérer les associations Utility Network (containment, connectivity, structural attachment), les Global IDs et l'intégrité topologique lors du processus de fusion ?
Esri recommanderait-il de charger tous les lots directement dans le même ensemble de données Utility Network, ou de créer des Utility Networks séparés pour chaque lot et de les fusionner ensuite ?
Y a-t-il des considérations liées à la performance, à la scalabilité ou à la topologie pour les migrations à grande échelle utilisant une stratégie de chargement par lots ?

Nous apprécierions les conseils d'Esri sur l'approche recommandée pour gérer les migrations Utility Network basées sur des lots à cette échelle.

Si j'opte pour le traitement par lots, comment puis-je fusionner les ensembles de données Utility Network ? Par exemple, si chaque lot contient 100 échanges, comment puis-je fusionner les données d'un ensemble de données Utility Network avec un autre ? Puis-je utiliser l'outil Append, ou cela ne fonctionnera-t-il pas ? Quelles sont les approches disponibles pour fusionner des ensembles de données Utility Network ? Veuillez clarifier et suggérer la meilleure approche pour fusionner les données Utility Network.

RobertKrisher

Dans mon précédent message, je supposais que vous utiliseriez Append, car c'est la manière la plus simple de charger des données et de préserver les Global IDs, qui sont nécessaires pour les associations.

Les questions que vous posez dépassent le cadre d'un simple message communautaire et relèvent plutôt d'une mission de conseil ou de services. Il est nécessaire d'avoir une discussion approfondie sur votre processus de migration des données, les processus d'assurance qualité, l'architecture et le calendrier avant que quiconque ne puisse envisager de répondre à ces questions.

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

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