Performances d'ArcGIS Engine en utilisant plusieurs géodatabases fichier par opposition à une seule?

J'essaie de décider de la meilleure façon d'organiser mes données pour une application ArcGIS Engine. Je suis particulièrement intéressé par l'affichage des cartes et la vitesse des requêtes. Actuellement, j'ai toutes mes données séparées dans des géodatabases fichier distinctes basées sur le thème. J'ai donc Transportation.gdb, Utilities.gdb, etc.

Je vais faire mes propres tests, mais je voulais poser la question à la communauté.

En général, l'utilisation d'une géodatabase fichier unique est-elle plus rapide que l'utilisation de plusieurs (environ 7) plus petites? Je suis également intéressé par d'autres avantages / inconvénients.

REMARQUE: le logiciel et toutes les données seront sur la machine locale du client. Aucune donnée diffusée sur le Web ou sur un réseau, et la quantité de données est assez faible (environ 100 000 fonctionnalités).

Je vais aller dans l'autre sens et dire en fait que non, ce n'est pas une bonne amélioration des performances de séparer les géodatabases pour ce cas d'utilisation particulier que vous avez décrit .

Vous devez vous rappeler qu'il y a un coût associé à une connexion à une base de données. Dans le cas de la GeoDatabase, elle charge toutes les tables de métadonnées associées. Ainsi, chaque fois que vous séparez vos données en plusieurs GDB, vous augmentez simplement ce coût, car vous devez maintenant ouvrir plusieurs versions de ces tables (une pour chaque base de données). Le multiplexage pour interroger les différentes bases de données peut généralement également signifier des E / S avec un cache qui est invalidé.

Néanmoins, il existe quelques cas où plusieurs bases de données peuvent fonctionner mieux. Par exemple. Prenons le cas d'une gdb personnelle (et non filegdb) de 700 Mo contre deux de 350 Mo d'une pièce. Le pilote MS Jet (qui est utilisé pour interagir avec les fichiers .mdb) va mapper en mémoire les fichiers inférieurs à 500 Mo - donc si la machine a suffisamment de mémoire, vous interagirez avec les bases de données entièrement en mémoire par rapport à toute entrée / sortie de disque. Beaucoup plus rapide. Le fichier 700 Mo ne sera pas mappé en mémoire.

En retirant ce cas de l'équation, il n'est pas logique de faire des dbs séparés. ArcMap, lors de sa boucle à travers les couches, interrogera chaque couche séquentiellement, vous n'aurez donc aucun parallélisme.

Vous feriez mieux de reconstruire vos index FileGDB à la place.

Et oui, un SSD serait certainement utile.

En fait, c'est normalement l'inverse; les petites bases de données interrogent plus rapidement. C'est comme demander si vous pouvez trouver des trucs plus rapidement si vous jetez tout dans un gros tas au sous-sol plutôt que de le trier dans des classeurs individuels. Lorsque vous avez des bases de données individuelles, c'est comme avoir 6 classeurs que vous pouvez ignorer dès le départ et que vous n'avez pas besoin de parcourir. Bien sûr, cela suppose que vous savez quelle base de données doit être interrogée - si vous devez les parcourir de toute façon, une grande peut en effet être plus rapide (car elle peut optimiser l'ensemble de données dans son ensemble).

À une époque, j'avais une configuration similaire avec ArcReader sur des appareils qui n'étaient pas très bien spécifiés pour SIG et j'ai eu la chance de maintenir une connexion réseau stable avec le serveur SIG ( nous parlons de connexions filaires instables ... pas sans fil ).

J'avais de nombreuses bases de données qui étaient généralement divisées par "thème", et aussi par fréquence de mise à jour. Je les ai répartis par jour, mois, annuellement ou tous les trois ans (qui était le calendrier de mise à jour aérienne / planimétrique). Depuis qu'ils ont été mis à jour via robocopy, je ne voulais pas déplacer de données inutiles sur ces appareils.

Si vous êtes dans un environnement où vous n'avez pas de capacité de réplication de géodatabase robuste ou si vous recevez simplement la géodatabase fichier pour distribution, il peut être plus facile à gérer en répartissant votre stockage de données de cette manière.

Pour répondre à votre question sur les performances: je n'ai jamais remarqué de baisse de vitesse en répartissant mes magasins de données dans des géodatabases fichier distinctes. Cela ne veut pas dire qu'il n'y en avait pas, mais s'il y en avait, ce n'était pas perceptible par l'homme. Il convient de noter que ces configurations avaient toutes les géodatabases fichier sur 1 disque dur - vous pourriez obtenir un gain de performances si vous les étaliez sur les périphériques SCSI / SSD.

J'ai déjà eu environ cinq applications Web ArcGIS Server WebADF qui couvraient chacune une zone géographique différente, mais elles partageaient toutes des ensembles de données communs. Le tueur était que les applications étaient toutes dynamiques (rien n'était mis en cache) et que nous avions des puits de pétrole et de gaz pouvant atteindre des centaines de milliers (des millions en fait pour l'ensemble des États-Unis). Faire des requêtes sur l'intégralité de l'ensemble de données était pénible - en fait, elles expiraient généralement. Couper les données pour chaque zone et les placer dans un magasin de données séparé a maintenu nos performances et nos clients satisfaits. Comme vous, nous avons également conservé les géodatabases fichier stockées sur le disque dur du serveur, ce qui a également aidé ALOT. Nous avions un processus automatisé qui coupait les données dans chaque géodatabase fichier chaque nuit.

Pas exactement une réponse, mais plutôt une étude de cas dans quelque chose de similaire à ce que vous pensez faire. Si nous n'avions pas eu autant de fonctionnalités dynamiques à gérer, nous n'aurions peut-être pas dû le faire. Parfois, faire des choses un peu hors de l'ordinaire est nécessaire.