We moeten ongeveer 8 miljard records migreren naar een PostgreSQL Enterprise Geodatabase met een ArcGIS Utility Network. Vanwege beperkingen in het datavolume wordt de data incrementeel in meerdere batches geladen in hetzelfde Utility Network. Wat is de door ESRI aanbevolen aanpak voor: * Incrementeel batchladen * Samenvoegen van batches in een bestaand Utility Network * Beheer van topologie tijdens het laden * Afhandelen van associaties en dirty areas * Behouden van prestaties op schaal van miljarden records Zijn er gedocumenteerde best practices, schaalbaarheidsaanbevelingen of referentiearchitecturen voor Utility Networks van deze omvang? Alvast bedankt voor alle begeleiding.

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

ESRI-aanbeveling voor incrementele laad van ~8 miljard records in een bestaand Utility Network

JayaramBT

We moeten ongeveer 8 miljard records migreren naar een PostgreSQL Enterprise Geodatabase met een ArcGIS Utility Network. Vanwege beperkingen in het datavolume wordt de data incrementeel in meerdere batches geladen in hetzelfde Utility Network.

Wat is de door ESRI aanbevolen aanpak voor:

Incrementeel batchladen
Samenvoegen van batches in een bestaand Utility Network
Beheer van topologie tijdens het laden
Afhandelen van associaties en dirty areas
Behouden van prestaties op schaal van miljarden records

Zijn er gedocumenteerde best practices, schaalbaarheidsaanbevelingen of referentiearchitecturen voor Utility Networks van deze omvang?

Alvast bedankt voor alle begeleiding.

Vind meer berichten getagd met

Accepted answers

RobertKrisher

Het is mijn begrip dat u al contact heeft met de support over de prestatieproblemen die u ervaart. U bent zich er al van bewust dat het inschakelen van de network topology een resource-intensief proces is, dus een snellere CPU, veel RAM, veel opslagruimte voor het verwerken van de transactie (lokaal en op de DBMS), en ook een verbinding met lage latentie tussen alle clients en componenten (client die de build uitvoert, en DBMS) zijn nodig.

Best practices zijn praktijken die over het algemeen in alle situaties kunnen worden toegepast en als de beste worden beschouwd. U heeft te maken met uitzonderlijke omstandigheden die de meeste klanten waarschijnlijk niet zullen ervaren, dus u zult waarschijnlijk buitengewone hardwarevereisten hebben evenals processen voor het beheren van deze datalast. Als u hulp nodig heeft bij het doorlopen van deze vragen, raad ik u aan contact op te nemen met een ervaren business partner of Esri Professional Services om uw organisatie te helpen.

Als u gegevens in batches laadt, is het het beste als elke batch foutloos is voordat u gegevens laadt en dat de master database ook foutloos is. Het creëren van fouten vereist extra CPU en geheugen tijdens het buildproces, dus het verminderen van het aantal fouten voordat u de network topology inschakelt, maakt het proces efficiënter. U kunt dingen doen zoals het inschakelen van de network topology in batches, of tools gebruiken zoals Analyze Network Data om topologiefouten te identificeren voordat u inschakelt.

All comments

RobertKrisher

@JayaramBT

Je kunt referentiearchitectuur vinden in het ArcGIS Architecture Center.

De beste praktijk is om gegevens te laden in een niet-versiebeheerde geodatabase, met de netwerktopologie uitgeschakeld. Dit omvat onze associaties.

De beste aanpak voor het afhandelen van topologiefouten is om er zoveel mogelijk op te lossen tijdens de migratie, en de rest op te lossen voordat je de database registreert als versiebeheerd en de netwerktopologie inschakelt. Dit houdt ook in dat je ervoor zorgt dat je geen ongeldige of dubbele associaties importeert.

De beste praktijk voor subnetwerken is om ervoor te zorgen dat je gegevens topologisch schoon zijn en dat alle correcties van gegevens om geldige, volledig verbonden subnetwerken te hebben plaatsvinden voordat je je subnetwork controllers importeert en de initiële update van het subnetwork uitvoert.

Als je besluit om gegevens incrementeel te laden in een versiebeheerde omgeving, brengt dit extra overwegingen met zich mee, maar het grootste risico dat je toevoegt is dat je mogelijk dubbele global IDs of associaties introduceert tijdens je laadprocessen. We houden incrementele laadprocessen sneller door sommige van onze validatiecontroles te versoepelen, maar dit legt ook de verantwoordelijkheid bij de data loader om ervoor te zorgen dat ze geen slechte gegevens laden. Er zijn veel andere zorgen en overwegingen bij het laden van gegevens in een versiebeheerde omgeving, vooral als je een ingeschakelde topologie en subnetwerken hebt, daarom wordt dit niet als beste praktijk beschouwd. Het wordt ondersteund, maar vereist zorgvuldige overweging, planning en testen van de tools en processen die je van plan bent te gebruiken.

JayaramBT

Bedankt Robert voor je snelle reactie. Als het Utility Network uiteindelijk ongeveer 8 miljard records bevat, is de aanbeveling van Esri dan nog steeds om te wachten tot alle batches zijn geladen voordat topologie wordt ingeschakeld, of zou Esri aanbevelen om periodiek topologie in te schakelen en delen van het netwerk te valideren om het risico te verkleinen dat er aan het einde van de migratie dataproblemen worden ontdekt?

Zijn er geteste referentiearchitecturen, aanbevelingen voor databasegrootte of klantimplementaties waarbij Utility Network datasets meer dan 1 miljard records bevatten, en zo ja, welke laad- en topologie-inschakelstrategie werd gebruikt?

Reëel voorbeeld hieronder:
Tijdens onze tests kostte het inschakelen van netwerktopologie op ongeveer 300 miljoen records ongeveer 60 uur.
Onze doelset wordt verwacht te groeien tot ongeveer 8 miljard records. Op basis van deze ervaring maken we ons zorgen dat het inschakelen van topologie operationeel uitdagend kan worden in de laatste migratiefase.
Heeft Esri richtlijnen, best practices of referentie-implementaties voor het inschakelen van topologie op deze schaal?
Specifiek:
Zijn er gedocumenteerde Utility Network implementaties met meer dan 1 miljard records?Raadt Esri een gefaseerde strategie voor het inschakelen van topologie aan voor extreem grote datasets?Zijn er bekende schaalkenmerken of aanbevelingen voor grootte bij het inschakelen van topologie bij volumes van meerdere miljarden records?Welke infrastructuur (CPU, RAM, opslagarchitectuur) zou Esri aanbevelen voor datasets van deze omvang?Zou Esri periodieke validatie tijdens migratie aanraden in plaats van te wachten tot alle 8 miljard records zijn geladen?

"300 miljoen kostte 60 uur, dus 8 miljard zal 1.600 uur kosten."???

RobertKrisher

JayaramBT

Bedankt Robert voor je suggesties. Mijn zorg betreft de uiteindelijke consolidatie van de data. Als elke batch afzonderlijk wordt geladen, wat is dan de aanbevolen Esri-aanpak om meerdere Utility Network datasets samen te voegen tot één enkele Utility Network?

Specifiek:

Kan de Append-tool worden gebruikt om Utility Network datasets uit verschillende batches samen te voegen?
Als Append niet wordt aanbevolen, wat zijn dan de ondersteunde of best-practice methoden om meerdere Utility Network-ladingen te consolideren in één enkele Enterprise Geodatabase?
Hoe moeten Utility Network-associaties (containment, connectivity, structural attachment), Global IDs en topologie-integriteit worden beheerd tijdens het samenvoegproces?
Zou Esri aanbevelen om alle batches direct in dezelfde Utility Network dataset te laden, of aparte Utility Networks te maken voor elke batch en deze later samen te voegen?
Zijn er prestatie-, schaalbaarheids- of topologie-gerelateerde overwegingen voor grootschalige migraties bij het gebruik van een batch-laadstrategie?

We zouden Esri's advies waarderen over de aanbevolen aanpak voor het omgaan met batch-gebaseerde Utility Network-migraties op deze schaal.

Als ik kies voor batchverwerking, hoe kan ik dan de Utility Network datasets samenvoegen? Bijvoorbeeld, als elke batch 100 uitwisselingen bevat, hoe kan ik dan de data van de ene Utility Network dataset met die van een andere samenvoegen? Kan ik de Append-tool gebruiken, of werkt dat niet? Wat zijn de beschikbare methoden om Utility Network datasets samen te voegen? Gelieve dit toe te lichten en de beste aanpak voor het samenvoegen van Utility Network-data aan te bevelen.

RobertKrisher

In mijn eerdere bericht ging ik ervan uit dat je Append zou gebruiken, omdat dit de meest eenvoudige manier is om gegevens te laden en Global IDs te behouden, die nodig zijn voor associaties.

De vragen die je stelt gaan verder dan een eenvoudig communitybericht en behoren tot het domein van een advies- of serviceopdracht. Er moet een diepgaand gesprek plaatsvinden over je datamigratieproces, kwaliteitsborgingsprocessen, architectuur en tijdlijn voordat iemand deze vragen zou moeten beantwoorden.

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

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