Wir müssen ungefähr 8 Milliarden Datensätze in eine PostgreSQL Enterprise Geodatabase mit einem ArcGIS Utility Network migrieren. Aufgrund von Datenmengenbeschränkungen werden die Daten inkrementell in mehreren Chargen in dasselbe Utility Network geladen. Was ist der von ESRI empfohlene Ansatz für: * Inkrementelles Laden in Chargen * Zusammenführen von Chargen in ein bestehendes Utility Network * Verwaltung der Topologie während des Ladens * Umgang mit Assoziationen und Dirty Areas * Aufrechterhaltung der Leistung im Milliarden-Datensatz-Bereich Gibt es dokumentierte Best Practices, Skalierungsempfehlungen oder Referenzarchitekturen für Utility Networks dieser Größe? Vielen Dank im Voraus für jede Unterstützung.

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-Empfehlung für inkrementelles Laden von ~8 Milliarden Datensätzen in ein bestehendes Utility Network

JayaramBT

Wir müssen ungefähr 8 Milliarden Datensätze in eine PostgreSQL Enterprise Geodatabase mit einem ArcGIS Utility Network migrieren. Aufgrund von Datenmengenbeschränkungen werden die Daten inkrementell in mehreren Chargen in dasselbe Utility Network geladen.

Was ist der von ESRI empfohlene Ansatz für:

Inkrementelles Laden in Chargen
Zusammenführen von Chargen in ein bestehendes Utility Network
Verwaltung der Topologie während des Ladens
Umgang mit Assoziationen und Dirty Areas
Aufrechterhaltung der Leistung im Milliarden-Datensatz-Bereich

Gibt es dokumentierte Best Practices, Skalierungsempfehlungen oder Referenzarchitekturen für Utility Networks dieser Größe?

Vielen Dank im Voraus für jede Unterstützung.

Finde mehr Beiträge mit dem Tag

Accepted answers

RobertKrisher

Meines Wissens stehen Sie bereits mit dem Support bezüglich der Leistungsprobleme, die Sie erleben, in Kontakt. Ihnen ist bereits bekannt, dass das Aktivieren der Netzwerk-Topologie ein ressourcenintensiver Prozess ist, daher sind eine schnellere CPU, viel RAM, viel Speicherplatz für die Verarbeitung der Transaktion (lokal und im DBMS) sowie eine latenzarme Verbindung zwischen allen Clients und Komponenten (Client, der den Build durchführt, und DBMS) erforderlich.

Best Practices sind Vorgehensweisen, die allgemein auf alle Situationen angewendet werden können und als die besten gelten. Sie haben es mit außergewöhnlichen Umständen zu tun, die die meisten Kunden wahrscheinlich nicht erleben, daher werden Sie wahrscheinlich außergewöhnliche Hardwareanforderungen sowie Prozesse zur Verwaltung dieser Datenlast haben. Wenn Sie Hilfe bei der Bearbeitung dieser Fragen benötigen, empfehle ich Ihnen, sich an einen erfahrenen Geschäftspartner oder Esri Professional Services zu wenden, um Ihre Organisation zu unterstützen.

Wenn Sie Daten in Chargen laden, wäre es am besten, wenn jede Charge fehlerfrei wäre, bevor die Daten geladen werden, und dass auch die Master-Datenbank fehlerfrei ist. Fehler zu erzeugen erfordert während des Build-Prozesses zusätzliche CPU und Speicher, daher macht es den Prozess effizienter, die Anzahl der Fehler vor dem Aktivieren der Netzwerk-Topologie zu reduzieren. Sie können Dinge tun wie das Aktivieren der Netzwerk-Topologie in Chargen oder Tools wie Analyze Network Data verwenden, um Topologiefehler zu identifizieren, bevor Sie sie aktivieren.

All comments

RobertKrisher

@JayaramBT

Sie finden die Referenzarchitektur im ArcGIS Architecture Center.

Die beste Vorgehensweise ist, Daten in eine nicht versionierte Geodatabase zu laden, wobei die Netzwerktopologie deaktiviert ist. Dies schließt unsere Assoziationen ein.

Die beste Methode zur Behandlung von Topologiefehlern besteht darin, so viele wie möglich während der Migration zu beheben und die restlichen zu klären, bevor Sie die Datenbank als versioniert registrieren und die Netzwerktopologie aktivieren. Dazu gehört auch, sicherzustellen, dass keine ungültigen oder doppelten Assoziationen importiert werden.

Die beste Praxis für Subnetze ist sicherzustellen, dass Ihre Daten topologisch sauber sind und alle Datenkorrekturen für gültige, vollständig verbundene Subnetze erfolgen, bevor Sie Ihre Subnetz-Controller importieren und das erste Update des Subnetzes durchführen.

Wenn Sie sich entscheiden, Daten inkrementell in eine versionierte Umgebung zu laden, bringt dies zusätzliche Überlegungen mit sich. Das größte Risiko besteht jedoch darin, dass Sie möglicherweise doppelte globale IDs oder Assoziationen während des Ladens einführen. Wir halten inkrementelle Ladevorgänge schneller, indem wir einige unserer Validierungsprüfungen lockern, aber das legt die Verantwortung auf den Datenlader, sicherzustellen, dass keine fehlerhaften Daten geladen werden. Es gibt viele weitere Bedenken und Überlegungen beim Laden von Daten in eine versionierte Umgebung, insbesondere wenn eine aktivierte Topologie und Subnetze vorhanden sind. Deshalb wird dies nicht als beste Praxis angesehen. Es wird unterstützt, erfordert jedoch sorgfältige Überlegung, Planung und Tests der Werkzeuge und Prozesse, die Sie verwenden möchten.

JayaramBT

Vielen Dank, Robert, für deine schnelle Antwort. Wenn das Utility Network letztendlich etwa 8 Milliarden Datensätze enthält, empfiehlt Esri dann immer noch, mit der Aktivierung der Topologie zu warten, bis alle Chargen geladen sind, oder würde Esri empfehlen, die Topologie periodisch zu aktivieren und Teile des Netzwerks zu validieren, um das Risiko zu verringern, Datenprobleme erst am Ende der Migration zu entdecken?

Gibt es getestete Referenzarchitekturen, Empfehlungen zur Datenbankgröße oder Kundenimplementierungen, bei denen Utility Network-Datensätze mehr als 1 Milliarde Datensätze überschritten haben, und wenn ja, welche Strategie für das Laden und die Aktivierung der Topologie wurde verwendet?

Echtzeitbeispiel unten:
Während unserer Tests erforderte die Aktivierung der Netzwerktopologie bei etwa 300 Millionen Datensätzen rund 60 Stunden.
Unser Ziel-Datensatz wird voraussichtlich auf etwa 8 Milliarden Datensätze anwachsen. Basierend auf dieser Erfahrung befürchten wir, dass die Aktivierung der Topologie in der finalen Migrationsphase operativ herausfordernd werden könnte.
Hat Esri irgendwelche Richtlinien, bewährte Verfahren oder Referenzimplementierungen für die Aktivierung der Topologie in diesem Umfang?
Insbesondere:
Gibt es dokumentierte Utility Network-Einsätze mit mehr als 1 Milliarde Datensätzen?Empfiehlt Esri eine schrittweise Strategie zur Aktivierung der Topologie für extrem große Datensätze?Gibt es bekannte Skalierungseigenschaften oder Empfehlungen zur Dimensionierung für die Aktivierung der Topologie bei Volumina von mehreren Milliarden Datensätzen?Welche Infrastruktur (CPU, RAM, Speicherarchitektur) würde Esri für Datensätze dieser Größenordnung empfehlen?Würde Esri eine periodische Validierung während der Migration empfehlen, anstatt zu warten, bis alle 8 Milliarden Datensätze geladen sind?

„300 Millionen dauerten 60 Stunden, also werden 8 Milliarden 1.600 Stunden dauern.“???

RobertKrisher

JayaramBT

Vielen Dank, Robert, für deine Vorschläge. Meine Sorge betrifft die endgültige Konsolidierung der Daten. Wenn jede Charge separat geladen wird, welcher Esri-Ansatz wird empfohlen, um mehrere Utility Network-Datensätze zu einem einzigen Utility Network zusammenzuführen?

Konkret:

Kann das Append-Werkzeug verwendet werden, um Utility Network-Datensätze aus verschiedenen Chargen zusammenzuführen?
Falls Append nicht empfohlen wird, welche unterstützten oder bewährten Methoden gibt es, um mehrere Utility Network-Ladevorgänge in einer einzigen Enterprise Geodatabase zu konsolidieren?
Wie sollten Utility Network-Verknüpfungen (Containment, Connectivity, Structural Attachment), Global IDs und die Topologie-Integrität während des Zusammenführungsprozesses verwaltet werden?
Würde Esri empfehlen, alle Chargen direkt in denselben Utility Network-Datensatz zu laden oder für jede Charge separate Utility Networks zu erstellen und diese später zusammenzuführen?
Gibt es Leistungs-, Skalierbarkeits- oder topologiebezogene Überlegungen bei groß angelegten Migrationen unter Verwendung einer Batch-Lade-Strategie?

Wir würden Esris Empfehlungen zum empfohlenen Vorgehen bei batchbasierten Utility Network-Migrationen in diesem Umfang sehr schätzen.

Wenn ich mich für die Batch-Verarbeitung entscheide, wie kann ich die Utility Network-Datensätze zusammenführen? Zum Beispiel, wenn jede Charge 100 Exchanges enthält, wie kann ich die Daten eines Utility Network-Datensatzes mit einem anderen zusammenführen? Kann ich das Append-Werkzeug verwenden oder funktioniert das nicht? Welche Möglichkeiten gibt es, Utility Network-Datensätze zusammenzuführen? Bitte klären Sie das und schlagen Sie den besten Ansatz zum Zusammenführen von Utility Network-Daten vor.

RobertKrisher

In meinem vorherigen Beitrag bin ich davon ausgegangen, dass Sie Append verwenden würden, da dies die einfachste Methode ist, Daten zu laden und Global IDs zu erhalten, die für Verknüpfungen erforderlich sind.

Die Fragen, die Sie stellen, gehen über den Rahmen eines einfachen Community-Beitrags hinaus und ähneln eher einer Beratungs- oder Dienstleistungsvereinbarung. Es muss eine eingehende Diskussion über Ihren Datenmigrationsprozess, Qualitätssicherungsprozesse, Architektur und Zeitplan geben, bevor jemand diese Fragen beantworten sollte.

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

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