¿Desempeño de ArcGIS Engine utilizando múltiples geodatabases de archivos en lugar de una?

Estoy tratando de decidir la mejor manera de organizar mis datos para una aplicación ArcGIS Engine. Estoy particularmente interesado en la visualización del mapa y la velocidad de consulta. Actualmente tengo todos mis datos separados en geodatabases de archivos separadas según el tema. Así que tengo Transportation.gdb, Utilities.gdb, etc. No es necesario que los datos estén organizados en función de los temas, y estoy considerando poner todo en una geodatabase de archivos.

Haré mis propias pruebas, pero quería lanzar la pregunta a la comunidad.

En general, ¿está usando una geodatabase de un solo archivo más rápido que usar varias (aproximadamente 7) más pequeñas? Estoy interesado en cualquier otro pros / contras también.

NOTA: el software y todos los datos estarán en la máquina local del cliente. No hay datos servidos en la web o en una red, y la cantidad de datos es bastante pequeña (aproximadamente 100,000 características).

Voy a ir hacia otro lado y en realidad digo que no, no es una buena mejora de rendimiento separar las GeoDatabases para este caso de uso en particular que usted describió .

Debe recordar que hay un costo asociado con una conexión a una base de datos. En el caso de GeoDatabase, está cargando todas las tablas de metadatos relacionadas. Entonces, cada vez que separa sus datos en múltiples GDB, solo está aumentando ese costo, porque ahora tiene que abrir varias versiones de estas tablas (una para cada DB). La multiplexación para consultar las diferentes bases de datos generalmente también puede significar E / S con caché que se invalida.

Sin embargo, hay algunos casos en los que tener múltiples bases de datos puede funcionar mejor. Por ejemplo. Considere el caso de un gdb personal (no filegdb) que es de 700 MB frente a dos que son 350 MB por pieza. El controlador MS Jet (que se usa para interactuar con archivos .mdb) almacenará en memoria archivos de menos de 500 MB, por lo que si la máquina tiene suficiente memoria, interactuará con los DB completamente en la memoria frente a cualquier E / S de disco. Mucho, mucho más rápido. El archivo de 700 MB no se asignará en memoria.

Tomando este caso fuera de la ecuación, entonces no tiene sentido hacer dbs separados. ArcMap, a medida que recorre las capas en bucle, consultará cada capa secuencialmente, para que no tenga ningún paralelismo.

Es mejor reconstruir sus índices FileGDB en su lugar.

Y sí, un SSD definitivamente ayudaría.

En realidad, normalmente es al revés; bases de datos más pequeñas consultan más rápido. Es como preguntar si puedes encontrar cosas más rápido si arrojas todo en un gran montón en el sótano en lugar de ordenarlo en archivadores individuales. Cuando tiene bases de datos individuales, es como tener 6 archivadores que puede ignorar directamente desde el principio, y no necesita revisarlos. Por supuesto, esto supone que usted sabe qué base de datos necesita consulta; si necesita revisarlos todos de todos modos, entonces uno grande podría ser más rápido (porque puede optimizar el conjunto de datos en su conjunto).

En un momento, tuve una configuración similar con ArcReader en dispositivos que no estaban muy bien especificados para GIS y tuve la suerte de mantener una conexión de red estable al servidor GIS ( estamos hablando de conexiones por cable inestables ... no inalámbricas )

Tenía numerosas bases de datos que generalmente estaban divididas por "tema" y también por frecuencia de actualización. Los separé diariamente, mensualmente, anualmente o trianualmente (que era un calendario de actualización aérea / planimétrica). Como se actualizaron mediante robocopy, no quería mover ningún dato que fuera innecesario a estos dispositivos.

Si se encuentra en un entorno en el que no tiene una capacidad sólida de replicación de geodatabase o simplemente está recibiendo la geodatabase de archivos para su distribución, puede ser más fácil de administrar separando su almacenamiento de datos de esta manera.

Para responder a su pregunta de rendimiento: nunca noté una disminución de la velocidad al dividir mis almacenes de datos en geodatabases de archivos separadas. Eso no significa que no haya ninguno, pero si lo hubo, no fue perceptible para los humanos. Vale la pena señalar que estas configuraciones tenían todas las geodatabases de archivos en 1 disco duro; podría obtener una ganancia de rendimiento si las extendiera a través de dispositivos SCSI / SSD.

Una vez tuve alrededor de cinco aplicaciones web ArcGIS Server WebADF que cubrían un área geográfica diferente, pero todas compartían conjuntos de datos comunes. El factor decisivo fue que todas las aplicaciones eran dinámicas (no se almacenó nada en caché) y teníamos pozos de petróleo y gas en ellas que podrían sumar cientos de miles (millones en realidad para todo Estados Unidos). Hacer consultas en todo el conjunto de datos fue doloroso, en realidad, por lo general, solo agotaban el tiempo de espera. Recortar los datos para cada área y ponerlos en un almacén de datos separado mantuvo nuestro rendimiento y nuestros clientes felices. Al igual que usted, también guardamos las geodatabases de archivos almacenadas en el HDD en el servidor, lo que también ayudó MUCHO. Teníamos un proceso automatizado que recortaba los datos a cada geodatabase de archivos cada noche.

No es exactamente una respuesta, sino más bien un estudio de caso en algo similar a lo que está pensando hacer. Si no hubiéramos tenido tantas características dinámicas con las que lidiar, podríamos no haber tenido que hacer eso. A veces es necesario hacer cosas un poco fuera de lo común.