Potřebujeme migrovat přibližně 8 miliard záznamů do PostgreSQL Enterprise Geodatabase obsahující ArcGIS Utility Network. Kvůli omezením objemu dat budou data načítána inkrementálně ve více dávkách do stejné Utility Network. Jaký je doporučený postup ESRI pro: * Inkrementální načítání dávek * Sloučení dávek do existující Utility Network * Správu topologie během načítání * Zpracování asociací a nevyčištěných oblastí * Udržení výkonu při škálování na miliardové množství záznamů Existují nějaké zdokumentované osvědčené postupy, doporučení pro škálovatelnost nebo referenční architektury pro Utility Networks této velikosti? Předem děkuji za jakoukoli radu.

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

Doporučení ESRI pro inkrementální načítání přibližně 8 miliard záznamů do existující Utility Network

JayaramBT

Potřebujeme migrovat přibližně 8 miliard záznamů do PostgreSQL Enterprise Geodatabase obsahující ArcGIS Utility Network. Kvůli omezením objemu dat budou data načítána inkrementálně ve více dávkách do stejné Utility Network.

Jaký je doporučený postup ESRI pro:

Inkrementální načítání dávek
Sloučení dávek do existující Utility Network
Správu topologie během načítání
Zpracování asociací a nevyčištěných oblastí
Udržení výkonu při škálování na miliardové množství záznamů

Existují nějaké zdokumentované osvědčené postupy, doporučení pro škálovatelnost nebo referenční architektury pro Utility Networks této velikosti?

Předem děkuji za jakoukoli radu.

Najděte více příspěvků označených jako

Accepted answers

RobertKrisher

Podle mého chápání jste již v kontaktu s podporou ohledně problémů s výkonem, které zažíváte. Už víte, že povolení network topology je proces náročný na zdroje, takže je potřeba rychlejší CPU, dostatek RAM, hodně úložiště pro zpracování transakce (lokálně i na DBMS) a také nízkolatenční připojení mezi všemi klienty a komponentami (klient provádějící build a DBMS).

Best practices jsou postupy, které lze obecně aplikovat ve všech situacích a považují se za nejlepší. Vy se však potýkáte s výjimečnými okolnostmi, které většina zákazníků pravděpodobně nezažije, takže pravděpodobně budete mít mimořádné hardwarové požadavky i procesy pro správu tohoto datového zatížení. Pokud potřebujete pomoc s řešením těchto otázek, doporučuji obrátit se na zkušeného obchodního partnera nebo Esri Professional Services, kteří pomohou vaší organizaci.

Pokud načítáte data po dávkách, bylo by nejlepší, kdyby každá dávka byla bez chyb před načtením dat a také aby hlavní databáze byla bez chyb. Vytváření chyb vyžaduje během build procesu další CPU a paměť, takže snížení počtu chyb před povolením network topology učiní proces efektivnějším. Můžete například povolit network topology po dávkách nebo použít nástroje jako Analyze Network Data k identifikaci topologických chyb před povolením.

All comments

RobertKrisher

@JayaramBT

Referenční architekturu najdete v ArcGIS Architecture Center.

Nejlepší praxí je načíst data do neverzionované geodatabáze s vypnutou síťovou topologií. To zahrnuje i naše asociace.

Nejlepší praxí při řešení chyb topologie je vyřešit co nejvíce z nich během migrace a zbytek vyřešit před tím, než zaregistrujete databázi jako verzionovanou a povolíte síťovou topologii. To zahrnuje i zajištění, že neimportujete žádné neplatné nebo duplicitní asociace.

Nejlepší praxí pro podsítě je zajistit, aby vaše data byla topologicky čistá a všechny opravy dat vedly k platným, plně propojeným podsítím před tím, než importujete své kontrolory podsítí a provedete počáteční aktualizaci podsítě.

Pokud se rozhodnete načítat data postupně do verzionovaného prostředí, přináší to další úvahy, ale největším rizikem je, že můžete během načítání zavést duplicitní globální ID nebo asociace. Postupné načítání udržujeme rychlejší tím, že uvolňujeme některé naše validační kontroly, ale to také klade odpovědnost na načítače dat, aby zajistil, že nenačítá špatná data. Existuje mnoho dalších obav a úvah při načítání dat do verzionovaného prostředí, zejména pokud máte povolenou topologii a podsítě, což je důvod, proč to není považováno za nejlepší praxi. Je to podporováno, ale vyžaduje pečlivé zvážení, plánování a testování nástrojů a procesů, které plánujete používat.

JayaramBT

Děkuji, Roberte, za rychlou odpověď. Pokud Utility Network nakonec bude obsahovat přibližně 8 miliard záznamů, doporučuje Esri stále počkat, až budou všechny dávky načteny, než se povolí topologie, nebo by Esri doporučovalo průběžně povolovat topologii a ověřovat části sítě, aby se snížilo riziko objevení problémů s daty až na konci migrace?

Existují nějaké otestované referenční architektury, doporučení pro velikost databáze nebo implementace u zákazníků, kde dataset Utility Network přesáhl 1 miliardu záznamů, a pokud ano, jaká strategie načítání a povolení topologie byla použita?

Příklad v reálném čase níže:
Během našeho testování vyžadovalo povolení síťové topologie na přibližně 300 milionech záznamů asi 60 hodin k dokončení.
Náš cílový dataset se očekává, že poroste na přibližně 8 miliard záznamů. Na základě této zkušenosti máme obavy, že povolení topologie by mohlo být provozně náročné ve finální fázi migrace.
Má Esri nějaké pokyny, osvědčené postupy nebo referenční implementace pro povolení topologie v tomto rozsahu?
Konkrétně:
Existují nějaké zdokumentované nasazení Utility Network přesahující 1 miliardu záznamů? Doporučuje Esri fázovou strategii povolení topologie pro extrémně velké datasety? Jsou známy charakteristiky škálování nebo doporučení pro velikost při povolení topologie u objemů v řádu miliard záznamů? Jakou infrastrukturu (CPU, RAM, architektura úložiště) by Esri doporučilo pro datasety této velikosti? Doporučuje Esri průběžnou validaci během migrace místo čekání, až bude načteno všech 8 miliard záznamů?

"300 milionů trvalo 60 hodin, takže 8 miliard bude trvat 1 600 hodin."???

RobertKrisher

JayaramBT

Děkuji, Roberte, za vaše návrhy. Můj zájem se týká konečné konsolidace dat. Pokud je každá dávka načítána samostatně, jaký je doporučený přístup Esri pro sloučení více datasetů Utility Network do jednoho Utility Network?

Konkrétně:

Lze použít nástroj Append ke sloučení datasetů Utility Network z různých dávek?
Pokud Append není doporučen, jaké jsou podporované nebo nejlepší postupy pro konsolidaci více načtení Utility Network do jednoho Enterprise Geodatabase?
Jak by měly být spravovány asociace Utility Network (obsah, konektivita, strukturální připojení), Global IDs a integrita topologie během procesu slučování?
Doporučuje Esri načítat všechny dávky přímo do stejného datasetu Utility Network, nebo vytvářet samostatné Utility Networks pro každou dávku a později je sloučit?
Existují nějaké aspekty výkonu, škálovatelnosti nebo topologie, které je třeba zvážit u migrací ve velkém rozsahu při použití strategie dávkového načítání?

Ocenili bychom vedení Esri ohledně doporučeného postupu pro zpracování migrací Utility Network založených na dávkách v tomto rozsahu.

Pokud zvolím dávkové zpracování, jak mohu sloučit datasety Utility Network? Například pokud každá dávka obsahuje 100 výměn, jak mohu sloučit data z jednoho datasetu Utility Network s jiným? Mohu použít nástroj Append, nebo to nebude fungovat? Jaké jsou dostupné přístupy ke sloučení datasetů Utility Network? Prosím o upřesnění a návrh nejlepšího postupu pro sloučení dat Utility Network.

RobertKrisher

Ve svém předchozím příspěvku jsem předpokládal, že budete používat Append, protože je to nejjednodušší způsob načítání dat a zachování Global IDs, které jsou vyžadovány pro asociace.

Otázky, které kladete, přesahují rámec jednoduchého komunitního příspěvku a spadají do oblasti konzultací nebo služeb. Před tím, než někdo začne na tyto otázky odpovídat, je potřeba podrobná diskuse o vašem procesu migrace dat, procesech zajištění kvality, architektuře a časovém harmonogramu.

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

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