Desempenho do ArcGIS Engine usando vários bancos de dados geográficos em vez de um?


11

Estou tentando decidir a melhor maneira de organizar meus dados para um aplicativo ArcGIS Engine. Estou particularmente interessado na exibição do mapa e na velocidade da consulta. Atualmente, tenho todos os meus dados separados em geodatabases de arquivos separados com base no tema. Então, eu tenho o Transportation.gdb, o Utilities.gdb, etc. Os dados não precisam necessariamente ser organizados com base em temas, e estou pensando em colocar tudo isso em um geodatabase de arquivo.

Farei meus próprios testes, mas eu queria fazer a pergunta para a comunidade.

Em geral, o uso de um geodatabase de arquivo único é mais rápido do que o uso de vários (aproximadamente 7) menores? Também estou interessado em outros prós / contras.

NOTA: o software e todos os dados estarão na máquina local do cliente. Nenhum dado é exibido na Web ou em uma rede, e a quantidade de dados é bastante pequena (aproximadamente 100.000 recursos).

Respostas:


5

Eu vou para o outro lado e realmente digo que não, não é uma boa melhoria de desempenho separar os GeoDatabases para esse caso de uso específico que você descreveu .

Você deve se lembrar que existe um custo associado à conexão com um banco de dados. No caso do GeoDatabase, ele está carregando todas as tabelas de metadados relacionadas. Portanto, sempre que você separa seus dados em vários GDBs, você apenas aumenta esse custo, porque agora você precisa abrir várias versões dessas tabelas (uma para cada banco de dados). A multiplexação para consultar os diferentes bancos de dados geralmente também pode significar E / S com cache que é invalidado.

No entanto, existem alguns casos em que ter vários bancos de dados pode funcionar melhor. Por exemplo. Considere o caso de um gdb pessoal (não filegdb) com 700 MB vs dois com 350 MB por peça. O driver MS Jet (o que é usado para interagir com arquivos .mdb) vontade mapa de memória arquivos menores que 500MB - por isso, se a máquina tem memória suficiente, você estará interagindo com bancos de dados totalmente na memória vs qualquer disco i / o. Muito, muito mais rápido. O arquivo de 700 MB não será mapeado para memória.

Retirando esse caso da equação, não faz sentido fazer dbs separados. O ArcMap, ao percorrer as camadas, consultará cada camada seqüencialmente, para que você não tenha paralelismo.

É melhor recriar seus índices FileGDB.

E sim, um SSD definitivamente ajudaria.


1
Oh O mapeamento de memória de <500mb .mdb's é interessante. Eu havia descartado o gdb pessoal como inadequado para reorganizar e renomear os campos no ms-access em vez do doloroso processo de adicionar-copiar-e-excluir necessário no arcgis. Talvez agora eu tenha outro motivo para usá-los de tempos em tempos. O arquivo do ponto de inflexão de 500 MB está no tamanho do disco ou algo mais? (por exemplo, um jpeg pode ter 30kb no disco, mas consome vários megabytes de memória RAM quando aberto).
27512

1
Tanto quanto me lembro, esse era o comportamento do próprio mecanismo Jet, e não o ESRI acionado. Além disso, era um pouco menor que 500 MB. Boa pergunta sobre tamanho de arquivo e memória. Eu acho que era o tamanho do arquivo - mas não me lembro exatamente, para ser sincero com você
Ragi Yaser Burhum

4

Na verdade, é normalmente o contrário; bancos de dados menores consultam mais rapidamente. É como perguntar se você pode encontrar as coisas mais rapidamente se jogar tudo em um grande monte no porão, em vez de classificá-lo em armários individuais. Quando você tem bancos de dados individuais, é como ter 6 arquivos que você pode desconsiderar desde o início e não precisa procurar. Obviamente, isso pressupõe que você saiba qual banco de dados precisa ser consultado - se você precisar examinar todos eles de qualquer maneira, um deles poderá ser mais rápido (porque pode otimizar o conjunto de dados como um todo).


3

Ao mesmo tempo, eu tinha uma configuração semelhante com o ArcReader em dispositivos que não eram muito bons para o GIS e tive a sorte de manter uma conexão de rede estável com o servidor GIS ( estamos falando de conexões com fio instáveis ​​... não sem fio )

Eu tinha vários bancos de dados que geralmente eram quebrados por "tema" e também pela frequência da atualização. Dividi-os diariamente, mensalmente, anualmente ou trienalmente (que era o cronograma de atualização aérea / planimétrica). Como eles foram atualizados via robocopy, eu não queria mover nenhum dado desnecessário para esses dispositivos.

Se você estiver em um ambiente em que não possui capacidade robusta de replicação de banco de dados geográficos ou estiver simplesmente recebendo o banco de dados geográfico de arquivos para distribuição, pode ser mais fácil gerenciar gerenciando o armazenamento de dados dessa maneira.

Para responder à sua pergunta sobre desempenho: nunca notei reduções de velocidade dividindo meus repositórios de dados em geodatabases de arquivos separados. Isso não significa que não havia, mas se havia, não era perceptível ao ser humano. É importante notar que essas configurações tinham todos os bancos de dados geográficos em um disco rígido - você pode obter um ganho de desempenho se os tiver espalhado pelos dispositivos SCSI / SSD.


2

Certa vez, eu tinha cerca de cinco aplicativos da Web ArcGIS Server WebADF que cobriam uma área geográfica diferente, mas todos compartilhavam conjuntos de dados comuns. O principal foi que os aplicativos eram todos dinâmicos (nada estava armazenado em cache) e tínhamos poços de petróleo e gás que podiam chegar a centenas de milhares (milhões, na verdade, para todos os EUA). Fazer consultas em todo o conjunto de dados foi doloroso - na verdade, eles normalmente acabavam com o tempo limite. Recortar os dados de cada área e colocá-los em um armazenamento de dados separado manteve nosso desempenho e nossos clientes satisfeitos. Como você, também mantivemos os bancos de dados geográficos de arquivos armazenados no disco rígido do servidor, o que também ajudou MUITO. Tivemos um processo automatizado que cortou os dados em cada geodatabase de arquivo a cada noite.

Não é exatamente uma resposta, mas mais um estudo de caso, algo semelhante ao que você pensa em fazer. Se não tivéssemos tantos recursos dinâmicos para lidar, talvez não precisássemos fazer isso. Às vezes, é necessário fazer coisas um pouco fora do comum.


Obrigado pela resposta. Não corresponde exatamente à minha situação, mas é um bom insight para outras pessoas com uma situação semelhante. Não mencionei que todos os dados estarão na máquina local do cliente, junto com o software. Nenhum dado está sendo veiculado pela Internet (exceto quando eles precisam instalar atualizações para o software). Além disso, a quantidade de dados com os quais estou trabalhando é uma pequena fração da quantidade com a qual você estava trabalhando.
Tanner

4
Eu não pensei que você estivesse veiculando através da Web, mas até mesmo ter os FGDBs em um compartilhamento de rede poderia desacelerar as coisas com dados passando pelos canais. Se você não estiver trabalhando com grandes conjuntos de dados, não acho que FGDBs separados farão muito bem - pode ser mais trabalhoso do que valeria a pena.
Chad Cooper
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.