¿Rendimiento de ArcGIS Engine utilizando múltiples bases de datos de archivos en lugar de una?

Question

Estoy tratando de decidir la mejor manera de organizar mis datos para una aplicación de ArcGIS Engine. Estoy particularmente interesado en la visualización de mapas y la velocidad de consulta. Actualmente tengo todos mis datos separados en geodatabases de archivos separados basados en el tema. Así que tengo Transportation.gdb, Utilities.gdb, etc. Los datos no tienen que estar necesariamente organizados por temas, y estoy considerando ponerlos todos en una sola geodatabase de archivos.

Voy a hacer mis propias pruebas, pero quería lanzar la pregunta a la comunidad.

En general, ¿es más rápido utilizar una geodatabase de un solo archivo que 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 se sirven datos en la web o en una red, y la cantidad de datos es bastante pequeña (aproximadamente 100.000 características).

Answer 1

Voy a ir por el otro lado y decir realmente que no, no es una buena mejora de rendimiento separar las GeoDatabases para este caso de uso particular que has descrito .

Hay que recordar que la conexión a una base de datos tiene un coste asociado. En el caso de la GeoDatabase, es cargar todas las tablas de metadatos relacionadas. Así que cuando separas tus datos en múltiples GDBs, sólo estás aumentando ese coste, porque ahora tienes que abrir múltiples versiones de estas tablas (una para cada DB). La multiplexación para consultar las diferentes BD suele ser puede también significa i/o con caché que se invalida.

Sin embargo, hay algunos casos en los que tener varias bases de datos puede trabajar mejor. Por ejemplo. Consideremos el caso de un gdb personal (no filegdb) que ocupa 700MB frente a dos que ocupan 350MB cada uno. El controlador de MS Jet (que se utiliza para interactuar con los archivos .mdb) mapa de memoria archivos de menos de 500MB - así que si la máquina tiene suficiente memoria, usted estará interactuando con las DBs completamente en memoria frente a cualquier i/o de disco. Mucho más rápido. El archivo de 700MB no será mapeado en memoria.

Si se excluye este caso de la ecuación, entonces no tiene sentido hacer dbs separadas. ArcMap, como está haciendo un bucle a través de las capas, consultará cada capa secuencialmente, por lo que no tiene ningún paralelismo.

Es mejor reconstruir los índices de FileGDB.

Y sí, un SSD definitivamente ayudaría.

Answer 2

En realidad, normalmente es al revés: las bases de datos más pequeñas consultan más rápido. Es como preguntar si se pueden encontrar las cosas más rápido si se tira todo en un gran montón en el sótano en lugar de clasificarlo en archivadores individuales. Cuando tienes bases de datos individuales, es como tener 6 archivadores que puedes desechar directamente desde el principio, y no necesitas buscar en ellos. Por supuesto, esto supone que se sabe qué base de datos hay que consultar; si hay que buscar en todas de todos modos, entonces una sola grande podría ser más rápida (porque puede optimizar el conjunto de datos).

Answer 3

En su día, tuve una configuración similar con ArcReader en dispositivos que no estaban muy bien especificados para SIG y que tenían suerte de mantener una conexión de red estable con el servidor SIG( estamos hablando de conexiones por cable inestables... no de inalámbricas ).

Tenía numerosas bases de datos que generalmente estaban divididas por "tema", y también por frecuencia de actualización. Los dividí en diarios, mensuales, anuales y trianuales (que era el programa de actualización aéreo/planimétrico). Como se actualizaban mediante robocopia, no quería trasladar a estos dispositivos ningún dato que fuera innecesario.

Si se encuentra en un entorno en el que no dispone de una sólida capacidad de replicación de la geodatabase o simplemente recibe la geodatabase de archivo para su distribución, puede ser más fácil de gestionar dividiendo el almacenamiento de datos de esta manera.

Para responder a su pregunta sobre el rendimiento: I nunca he notado una disminución de la velocidad al dividir mis almacenes de datos en geodatabases de archivos separados. Eso no significa que no haya habido ninguna, pero si la hubo, no fue perceptible para el ser humano. Vale la pena señalar que estas configuraciones tenían todas las geodatabases de archivos en un solo disco duro; podrías obtener un aumento de rendimiento si las tuvieras repartidas en dispositivos SCSI/SSD.

Answer 4

Una vez tuve unas cinco aplicaciones web ArcGIS Server WebADF que cubrían cada una un área geográfica diferente, pero todas compartían conjuntos de datos comunes. El problema era que todas las aplicaciones eran dinámicas (no se almacenaba nada en la caché) y en ellas había pozos de petróleo y gas que podían llegar a ser cientos de miles (millones en realidad para todo Estados Unidos). Hacer consultas en todo el conjunto de datos era doloroso; de hecho, normalmente se agotaba el tiempo de espera. Recortar los datos de cada zona y ponerlos en un almacén de datos separado mantuvo nuestro rendimiento y a nuestros clientes contentos. Al igual que usted, también mantuvimos las geodatabases de archivos almacenadas en el disco duro del servidor, lo que también ayudó MUCHO. Teníamos un proceso automatizado que recortaba los datos en cada geodatabase de archivos cada noche.

No es exactamente una respuesta, sino más bien un caso práctico de algo parecido a lo que estás pensando hacer. Si no hubiéramos tenido que lidiar con tantas características dinámicas, quizá no hubiéramos tenido que hacer eso. A veces es necesario hacer cosas un poco fuera de lo normal.