Necesitamos migrar aproximadamente 8 mil millones de registros a una Geodatabase Empresarial PostgreSQL que contiene una Red de Utilidad ArcGIS. Debido a las limitaciones de volumen de datos, los datos se cargarán de forma incremental en múltiples lotes en la misma Red de Utilidad. ¿Cuál es el enfoque recomendado por ESRI para: * Carga incremental por lotes * Fusión de lotes en una Red de Utilidad existente * Gestión de la topología durante las cargas * Manejo de asociaciones y áreas sucias * Mantener el rendimiento a escala de miles de millones de registros ¿Existen prácticas recomendadas documentadas, recomendaciones de escalabilidad o arquitecturas de referencia para Redes de Utilidad de este tamaño? Gracias de antemano por cualquier orientación.

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

Recomendación de ESRI para la carga incremental de ~8 mil millones de registros en una Red de Utilidad existente

JayaramBT

Necesitamos migrar aproximadamente 8 mil millones de registros a una Geodatabase Empresarial PostgreSQL que contiene una Red de Utilidad ArcGIS. Debido a las limitaciones de volumen de datos, los datos se cargarán de forma incremental en múltiples lotes en la misma Red de Utilidad.

¿Cuál es el enfoque recomendado por ESRI para:

Carga incremental por lotes
Fusión de lotes en una Red de Utilidad existente
Gestión de la topología durante las cargas
Manejo de asociaciones y áreas sucias
Mantener el rendimiento a escala de miles de millones de registros

¿Existen prácticas recomendadas documentadas, recomendaciones de escalabilidad o arquitecturas de referencia para Redes de Utilidad de este tamaño?

Gracias de antemano por cualquier orientación.

Encuentra más publicaciones etiquetadas con

Accepted answers

RobertKrisher

Tengo entendido que ya está en contacto con el soporte sobre los problemas de rendimiento que está experimentando. Ya sabe que habilitar la topología de red es un proceso que consume muchos recursos, por lo que se necesita una CPU más rápida, mucha RAM, mucho almacenamiento para procesar la transacción (localmente y en el DBMS), y también una conexión de baja latencia entre todos los clientes y componentes (cliente que realiza la compilación y DBMS).

Las mejores prácticas son prácticas que se pueden aplicar generalmente en todas las situaciones y se consideran las mejores. Usted está tratando con circunstancias excepcionales que la mayoría de los clientes probablemente no experimenten, por lo que probablemente tendrá algunos requisitos de hardware extraordinarios, así como procesos para gestionar esta carga de datos. Si necesita ayuda para resolver estas cuestiones, le recomiendo que se comunique con un socio comercial experimentado o con Esri Professional Services para ayudar a su organización.

Si está cargando datos en lotes, sería mejor que cada lote estuviera libre de errores antes de cargar los datos y que la base de datos principal también esté libre de errores. Crear errores requiere CPU y memoria adicionales durante el proceso de compilación, por lo que reducir el número de errores antes de habilitar la topología de red hará que el proceso sea más eficiente. Puede hacer cosas como habilitar la topología de red en los lotes o usar herramientas como Analyze Network Data para identificar errores de topología antes de habilitarla.

All comments

RobertKrisher

@JayaramBT

Puedes encontrar la arquitectura de referencia en el ArcGIS Architecture Center.

La mejor práctica es cargar los datos en una geodatabase no versionada, con la topología de red deshabilitada. Esto incluye nuestras asociaciones.

La mejor práctica para manejar errores de topología es resolver tantos como sea posible durante la migración, y resolver el resto antes de registrar la base de datos como versionada y habilitar la topología de red. Esto incluye asegurarse de no importar asociaciones inválidas o duplicadas.

La mejor práctica para las subredes es asegurarse de que tus datos estén topológicamente limpios y que todas las correcciones de datos para tener subredes válidas y completamente conectadas ocurran antes de importar tus controladores de subred y realizar la actualización inicial de la subred.

Si decides cargar datos incrementalmente en un entorno versionado, esto implicará consideraciones adicionales, pero el mayor riesgo que añades es que podrías introducir IDs globales duplicados o asociaciones durante tus cargas. Mantenemos las cargas incrementales más rápidas relajando algunas de nuestras verificaciones de validación, pero esto también pone la responsabilidad en el cargador de datos para asegurar que no esté cargando datos erróneos. Hay muchas otras preocupaciones y consideraciones al cargar datos en un entorno versionado, especialmente si tienes una topología y subredes habilitadas, por lo que no se considera una mejor práctica. Está soportado, pero requiere un pensamiento cuidadoso, planificación y pruebas de las herramientas y procesos que planeas usar.

JayaramBT

Gracias Robert por tu rápida respuesta. Si la Utility Network finalmente contiene aproximadamente 8 mil millones de registros, ¿la recomendación de Esri sigue siendo esperar hasta que se carguen todos los lotes antes de habilitar la topología, o Esri recomendaría habilitar periódicamente la topología y validar partes de la red para reducir el riesgo de descubrir problemas de datos al final de la migración?

¿Existen arquitecturas de referencia probadas, recomendaciones de dimensionamiento de bases de datos o implementaciones de clientes donde los conjuntos de datos de Utility Network superaron los 1 mil millones de registros, y en caso afirmativo, qué estrategia de carga y habilitación de topología se utilizó?

Ejemplo en tiempo real a continuación:
Durante nuestras pruebas, habilitar la topología de red en aproximadamente 300 millones de registros requirió alrededor de 60 horas para completarse.
Se espera que nuestro conjunto de datos objetivo crezca hasta aproximadamente 8 mil millones de registros. Basándonos en esta experiencia, nos preocupa que la habilitación de la topología pueda volverse operativamente desafiante en la etapa final de la migración.
¿Tiene Esri alguna guía, mejores prácticas o implementaciones de referencia para la habilitación de topología a esta escala?
Específicamente:
¿Existen implementaciones documentadas de Utility Network que superen los 1 mil millones de registros?¿Recomienda Esri una estrategia escalonada para habilitar la topología en conjuntos de datos extremadamente grandes?¿Existen características conocidas de escalabilidad o recomendaciones de dimensionamiento para la habilitación de topología en volúmenes de varios miles de millones de registros?¿Qué infraestructura (CPU, RAM, arquitectura de almacenamiento) recomendaría Esri para conjuntos de datos de esta magnitud?¿Recomendaría Esri una validación periódica durante la migración en lugar de esperar hasta que se carguen los 8 mil millones de registros?

"300 millones tomaron 60 horas, entonces 8 mil millones tomarán 1,600 horas."???

RobertKrisher

JayaramBT

Gracias Robert por tus sugerencias. Mi preocupación es respecto a la consolidación final de los datos. Si cada lote se carga por separado, ¿cuál es el enfoque recomendado por Esri para fusionar múltiples conjuntos de datos de Utility Network en un solo Utility Network?

Específicamente:

¿Se puede usar la herramienta Append para fusionar conjuntos de datos de Utility Network de diferentes lotes?
Si no se recomienda Append, ¿cuáles son los enfoques soportados o las mejores prácticas para consolidar múltiples cargas de Utility Network en una sola Enterprise Geodatabase?
¿Cómo se deben gestionar las asociaciones de Utility Network (contención, conectividad, adjunto estructural), Global IDs e integridad topológica durante el proceso de fusión?
¿Recomendaría Esri cargar todos los lotes directamente en el mismo conjunto de datos de Utility Network, o crear Utility Networks separados para cada lote y fusionarlos después?
¿Existen consideraciones sobre rendimiento, escalabilidad o topología para migraciones a gran escala al usar una estrategia de carga por lotes?

Agradeceríamos la orientación de Esri sobre el enfoque recomendado para manejar migraciones basadas en lotes de Utility Network a esta escala.

Si opto por el procesamiento por lotes, ¿cómo puedo fusionar los conjuntos de datos de Utility Network? Por ejemplo, si cada lote contiene 100 intercambios, ¿cómo puedo fusionar los datos de un conjunto de datos de Utility Network con otro? ¿Puedo usar la herramienta Append o eso no funcionará? ¿Cuáles son los enfoques disponibles para fusionar conjuntos de datos de Utility Network? Por favor, aclaren y sugieran el mejor enfoque para fusionar datos de Utility Network.

RobertKrisher

En mi publicación anterior asumía que usarías Append, ya que es la forma más sencilla de cargar datos y preservar los Global IDs, que son necesarios para las asociaciones.

Las preguntas que estás haciendo están fuera del alcance de una simple publicación comunitaria y se asemejan a un compromiso de consultoría o servicios. Es necesario tener una discusión profunda sobre tu proceso de migración de datos, procesos de aseguramiento de calidad, arquitectura y cronograma antes de que alguien considere responder esas preguntas.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

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