Производительность ArcGIS Engine при использовании нескольких файловых баз геоданных, а не одной?

Я пытаюсь решить, как лучше организовать свои данные для приложения ArcGIS Engine. Я особенно заинтересован в отображении карты и скорости запросов. В настоящее время все мои данные разделены на отдельные файловые базы геоданных на основе темы. Итак, у меня есть Transportation.gdb, Utilities.gdb и т. Д. Данные не обязательно должны быть организованы по темам, и я собираюсь поместить их все в одну файловую базу геоданных.

Я буду проводить собственное тестирование, но я хотел передать вопрос сообществу.

В общем, быстрее ли использовать одну файловую базу геоданных, чем несколько (примерно 7) меньших? Меня также интересуют любые плюсы и минусы.

ПРИМЕЧАНИЕ: программное обеспечение и все данные будут на локальном компьютере клиента. Нет данных, передаваемых через Интернет или по сети, и объем данных довольно мал (примерно 100 000 функций).

Я собираюсь пойти другим путем и на самом деле сказать, что нет, улучшение производительности не является хорошим разделением баз геоданных для этого конкретного варианта использования, который вы описали .

Вы должны помнить, что с подключением к БД связана стоимость. В случае базы геоданных она загружает все связанные таблицы метаданных. Поэтому, когда вы разделяете ваши данные на несколько GDB, вы просто увеличиваете эту стоимость, потому что теперь вам нужно открывать несколько версий этих таблиц (по одной для каждой БД). Мультиплексирование для запроса различных БД обычно может также означать ввод-вывод с кэшем, который становится недействительным.

Тем не менее, есть несколько случаев, когда наличие нескольких БД может работать лучше. Например. Рассмотрим случай с персональным GDB (не filegdb), который равен 700 МБ, а два - 350 МБ за штуку. Драйвер MS Jet (используемый для взаимодействия с файлами .mdb) будет отображать файлы карты памяти размером менее 500 МБ - поэтому, если на компьютере достаточно памяти, вы будете взаимодействовать с БД, полностью находящимися в памяти, по сравнению с любым дисковым вводом-выводом. Гораздо быстрее. Файл 700 МБ не будет отображаться в памяти.

Если исключить этот случай из уравнения, то нет смысла делать отдельные БД. ArcMap, поскольку он проходит по слоям, будет запрашивать каждый слой последовательно, поэтому у вас не будет никакого параллелизма.

Вместо этого вам лучше перестроить индексы FileGDB.

И да, SSD определенно поможет.

На самом деле это обычно наоборот; меньшие базы данных запрашивают быстрее. Это все равно что спросить, можете ли вы найти вещи быстрее, если вы бросите все в большую кучу в подвале, а не разберете их в отдельные шкафы. Когда у вас есть отдельные базы данных, это похоже на 6 шкафов для хранения документов, которые вы можете игнорировать прямо с самого начала, и вам не нужно просматривать их. Конечно, это предполагает, что вы знаете, какая база данных нуждается в запросах - если вам все равно нужно просмотреть все из них, то одна большая действительно может быть быстрее (потому что она может оптимизировать набор данных в целом).

Одно время у меня была похожая установка с ArcReader на устройствах, которые не очень хорошо подходили для ГИС, и мне посчастливилось поддерживать стабильное сетевое соединение с ГИС-сервером ( мы говорим о нестабильных проводных соединениях ... не беспроводных ).

У меня было множество баз данных, которые обычно разбивались по «теме», а также по частоте обновления. Я разбил их по дням, месяцам, годам или раз в три года (это был график обновления с воздуха / по планетрике). Поскольку они были обновлены с помощью robocopy, я не хотел переносить какие-либо ненужные данные на эти устройства.

Если вы находитесь в среде, где у вас нет надежной возможности репликации базы геоданных, или вы просто получаете файловую базу геоданных для распространения, вам может быть проще управлять, разбив хранилище данных таким образом.

Чтобы ответить на ваш вопрос производительности: я никогда не замечал снижения скорости, разбивая мои хранилища данных на отдельные файловые базы геоданных. Это не значит, что их не было, но если они были, они не были восприняты человеком. Стоит отметить, что в этих конфигурациях были все файловые базы геоданных на 1 жестком диске - вы могли бы получить выигрыш в производительности, если бы они распространялись на устройства SCSI / SSD.

Однажды у меня было около пяти веб-приложений ArcGIS Server WebADF, каждое из которых охватывало разные географические области, но все они имели общие наборы данных. Убийством было то, что все приложения были динамичными (ничего не кэшировалось), и у нас были нефтяные и газовые скважины, которые могли исчисляться сотнями тысяч (миллионы фактически на весь США). Выполнение запросов по всему набору данных было болезненным - на самом деле они обычно просто зависали. Вырезание данных для каждой области и помещение их в отдельное хранилище данных позволило нам повысить производительность и порадовать наших клиентов. Как и вы, мы также сохранили файловые базы геоданных на жестком диске на сервере, что также помогло ALOT. У нас был автоматизированный процесс, который каждую ночь вырезал данные в каждой файловой базе геоданных.

Не совсем ответ, а скорее тематическое исследование в чем-то вроде того, о чем вы думаете. Если бы у нас не было так много динамических функций, нам бы не пришлось это делать. Иногда необходимо делать что-то необычное.