Prestazioni di ArcGIS Engine che utilizza più file di geodatabase anziché uno?


11

Sto cercando di decidere il modo migliore per organizzare i miei dati per un'applicazione ArcGIS Engine. Sono particolarmente interessato alla visualizzazione delle mappe e alla velocità delle query. Attualmente ho tutti i miei dati separati in geodatabase di file separati in base al tema. Quindi ho Transportation.gdb, Utilities.gdb, ecc. I dati non devono necessariamente essere organizzati in base ai temi e sto pensando di metterli tutti in un file geodatabase.

Farò i miei test, ma volevo porre la domanda alla comunità.

In generale, l'utilizzo di un geodatabase a file singolo è più veloce rispetto all'uso di più (circa 7) più piccoli? Sono interessato anche ad altri vantaggi / svantaggi.

NOTA: il software e tutti i dati saranno sul computer locale del cliente. Nessun dato pubblicato sul Web o su una rete e la quantità di dati è piuttosto ridotta (circa 100.000 funzioni).

Risposte:


5

Vado dall'altra parte e in realtà dico che no, non è un buon miglioramento delle prestazioni separare i database Geo per questo particolare caso d'uso che hai descritto .

Devi ricordare che esiste un costo associato a una connessione a un DB. Nel caso del GeoDatabase, sta caricando tutte le relative tabelle di metadati. Quindi, ogni volta che separi i tuoi dati in più GDB, stai solo aumentando quel costo, perché ora devi aprire più versioni di queste tabelle (una per ogni DB). Il multiplexing per interrogare i diversi DB di solito può anche significare I / O con cache che viene invalidata.

Tuttavia, ci sono alcuni casi in cui avere più DB potrebbe funzionare meglio. Per esempio. Si consideri il caso di un gdb personale (non filegdb) di 700 MB contro due di 350 MB al pezzo. Il driver MS Jet (che viene utilizzato per interagire con i file .mdb) memorizzerà i file di mappe più piccoli di 500 MB, quindi se la macchina ha memoria sufficiente, interagirai con i DB completamente in memoria rispetto a qualsiasi I / O su disco. Molto molto più veloce. Il file da 700 MB non verrà mappato in memoria.

Prendendo questo caso fuori dall'equazione, allora non ha senso fare dbs separati. ArcMap, mentre scorre ciclicamente attraverso i livelli, interrogherà ogni livello in sequenza, quindi non c'è alcun parallelismo in corso.

Invece è meglio ricostruire gli indici FileGDB.

E sì, un SSD sarebbe sicuramente di aiuto.


1
Oh. La mappatura della memoria di <500mb .mdb è interessante. Avevo cancellato i dati personali di gdb come non validi per nient'altro che riordinare e rinominare i campi in ms-access invece del doloroso processo di aggiunta-copia-e-cancellazione necessario in arcgis. Forse ora ho un altro motivo per usarli di volta in volta. Il file del punto di non ritorno 500mb è sulla dimensione del disco o qualcos'altro? (ad esempio un jpeg può essere 30kb su disco ma consuma più megabyte di RAM quando è aperto).
Matt Wilson

1
Per quanto ricordo, si trattava di un comportamento del motore Jet stesso e non innescato dall'ESRI. Inoltre, era leggermente più piccolo di 500 MB. Buona domanda sulla dimensione del file rispetto alla memoria. Penso che fosse la dimensione del file - ma non ricordo esattamente, ad essere sincero con te
Ragi Yaser Burhum,

4

In realtà è normalmente il contrario; database più piccoli eseguono query più velocemente. È come chiedere se riesci a trovare le cose più velocemente se butti tutto in un grande ammasso nel seminterrato piuttosto che ordinarlo in singoli schedari. Quando si dispone di singoli database, è come avere 6 schedari che è possibile ignorare fin dall'inizio e che non è necessario esaminare. Naturalmente questo presuppone che tu sappia quale database deve essere interrogato - se hai bisogno di esaminarli tutti comunque, uno grande potrebbe effettivamente essere più veloce (perché può ottimizzare il set di dati nel suo insieme).


3

Un tempo, avevo una configurazione simile con ArcReader su dispositivi che non erano molto adatti per GIS ed erano fortunati a mantenere una connessione di rete stabile al server GIS ( stiamo parlando di connessioni cablate instabili ... non wireless ).

Avevo numerosi database che erano generalmente interrotti dal "tema" e anche da frequenza di aggiornamento. Li ho distribuiti giornalmente, mensilmente, annualmente o ogni tre anni (che era il programma di aggiornamento aereo / planimetrico). Dato che sono stati aggiornati tramite robocopy, non volevo spostare alcun dato inutile su questi dispositivi.

Se ci si trova in un ambiente in cui non si dispone di solide funzionalità di replica del geodatabase o si sta semplicemente ricevendo il file geodatabase per la distribuzione, potrebbe essere più facile gestirlo suddividendo l'archiviazione dei dati in questo modo.

Per rispondere alla tua domanda sulle prestazioni: non ho mai notato alcuna riduzione della velocità suddividendo i miei archivi di dati in geodatabase di file separati. Ciò non significa che non ce ne fosse, ma se ci fosse, non era percepibile dall'uomo. Vale la pena notare che queste configurazioni avevano tutti i file geodatabase su 1 disco rigido: potresti ottenere un miglioramento delle prestazioni se li avessi distribuiti su dispositivi SCSI / SSD.


2

Una volta avevo circa cinque applicazioni Web ArcGIS Server WebADF che coprivano ognuna un'area geografica diversa, ma condividevano tutti set di dati comuni. Il killer era che le app erano tutte dinamiche (nulla era memorizzato nella cache) e contenevamo pozzi di petrolio e gas che potevano contare in centinaia di migliaia (milioni in realtà per tutti gli Stati Uniti). Fare query sull'intero set di dati è stato doloroso, in realtà di solito si limitavano a scadere. Ritagliare i dati per ciascuna area e inserirli in un archivio dati separato ha reso le nostre prestazioni elevate e i nostri clienti felici. Come te, abbiamo anche archiviato i file di geodatabase archiviati sull'HDD sul server, il che ha aiutato ALOT. Abbiamo avuto un processo automatizzato che ha ritagliato i dati su ogni file geodatabase ogni notte.

Non esattamente una risposta, ma più un caso di studio in qualcosa di simile a quello che stai pensando di fare. Se non avessimo avuto così tante caratteristiche dinamiche da affrontare, non avremmo dovuto farlo. A volte è necessario fare le cose un po 'fuori dal comune.


Grazie per la risposta. Non corrisponde perfettamente alla mia situazione, ma è una buona intuizione per altre persone con una situazione simile. Non ho menzionato che tutti i dati saranno sul computer locale del cliente, insieme al software. Nessun dato viene fornito su Internet (tranne quando è necessario installare gli aggiornamenti per il software). Inoltre, la quantità di dati con cui sto lavorando è una piccola parte della quantità con cui stavi lavorando.
Tanner,

4
Non pensavo fossi al servizio sul Web, ma anche avere gli FGDB su una condivisione di rete potrebbe rallentare le cose con i dati che passano attraverso le pipe. Se non stai lavorando con enormi set di dati, non credo che FGDB separati ti faranno molto bene - potrebbe essere più una seccatura di quanto varrebbe.
Chad Cooper,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.