Личные базы геоданных лучше подходят для быстрого запроса индексированных атрибутов, чем файловые базы геоданных?

Я готовлю данные для приложения ArcGIS Engine, которое запрашивает данные для поиска адреса. Иногда мы ищем только в поле названия улицы, просто в поле номера дома или в обоих. При использовании персональных баз геоданных или баз геоданных SDE можно добавить индекс атрибута с несколькими столбцами в дополнение к индексам с одним столбцом. По какой-то причине, согласно статье ESRI « Создание индексов атрибутов», индексы атрибутов с несколькими столбцами невозможны при использовании файловых баз геоданных. Они не упоминают, почему это так - может быть, файловым базам геоданных по каким-то причинам они не нужны?

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

У меня сложилось впечатление, что Esri хочет, чтобы мы отошли от личных баз геоданных, но разве в этом случае личные базы геоданных являются лучшим вариантом? Если у вас есть опыт с этим, я хотел бы знать.

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

Порядок, в котором поля появляются в многоколоночном индексе, важен. В многоколоночном индексе со столбцом A, предшествующим столбцу B, столбец A будет использоваться для проведения начального поиска. Кроме того, такой индекс будет гораздо более полезным для запросов, включающих только столбец A, чем для запросов, включающих только столбец B.
Создайте многоколонный индекс для A и B. Этот индекс обычно будет более эффективным для запросов, включающих оба столбца. Для запросов, включающих только A, этот индекс будет медленнее, чем индекс только A. Этот индекс будет малопригоден для запросов, включающих только B. Чтобы компенсировать это, вы можете создать дополнительный индекс для B.

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

Я нашел ссылку на старый, но интересный документ ESRI с указанием 9 причин выбрать файл вместо личной GDB . Это интересно тем, что в качестве одной из причин он называет производительность. Частично это увеличение производительности происходит из-за файловой системы хранения. Я думаю, что это также может повлиять на отсутствие поддержки нескольких столбцов. В отличие от персональной GDB, которая представляет собой один файл, индекс в файловой GDB хранится как отдельный файл в структуре GDB. Это означает, что файл индекса и файл атрибута для определенного класса объектов должны быть связаны и доступны вместе. Я мог видеть, где многостолбцовый индекс приведет к переходу назад и вперед между индексным файлом и файлом атрибутов и потенциально может привести к снижению производительности, которое перевешивает прирост производительности индексирования.

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

Из моего опыта работы с обоими типами GDB я видел, что Personal GDB работает примерно на 50% больше, чем файл. Исходя из предоставленных вами данных относительно вашей файловой GDB, если бы вы конвертировали в PGDB, вы, вероятно, в итоге получили бы персональную GDB ~ 300 МБ. Из того, что я видел, работая с базами данных MS Access, как в продуктах ESRI, так и по отдельности, можно увидеть снижение производительности, как только размер файлов .mdb значительно превысит размер более 100 МБ.

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

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

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

Я полагаю, что основной целью FGDB по сравнению с PGDB является емкость и производительность пространственных данных (скорость рисования, поиск, пространственное индексирование, пространственные запросы и т. Д.), А не функциональность, такая как многостолбцовые «атрибутные» индексы и другие расширенные функции SQL, которые обычно являются такой неотъемлемой частью любой СУБД. (Какой PGDB на основе MS Access является, а собственной FGDB ESRI нет). Максимальный размер файла базы данных MS Access составляет 2 ГБ, что также является максимальным размером любой отдельной PGDB. Напротив, предел размера файла FGDB составляет 1 ТБ, расходуемый до 256 ТБ.

ESRI также утверждает, что: Синтаксис, который вы используете для построения выражения SQL, зависит от источника данных. Это потому, что, хотя SQL является стандартом, не все программное обеспечение для баз данных реализует один и тот же диалект SQL. и Для запроса данных на основе файлов, включая файловые базы геоданных, покрытия, шейп-файлы, таблицы INFO, таблицы dBASE, данные CAD и VPF, вы используете диалект SQL, реализованный в ArcGIS, который поддерживает подмножество функций и функций, доступных в личных и Базы геоданных ArcSDE.

Другими словами (а PGDB и ArcSDE GDB - доказательство этого), если база геоданных, лежащая в основе СУБД, поддерживает эту функцию, она должна быть доступна . Вероятно, именно поэтому вы можете создать многостолбцовый индекс в PGDB, которая имеет базовую базу данных MS Access. То же самое с любой базой геоданных ArcSDE с базовой СУБД, которая поддерживает эту функцию.

Что касается Файловой Геодабазы ; в выпуске 9.2 FGDB ESRI намекнул, что некоторые из этих функций и функций могут быть добавлены в будущих выпусках FGDB, цитируя; «Файловые базы геоданных не поддерживают все функции и функции, доступные для личных баз геоданных. В ArcGIS 9.2 наиболее часто используемые функции, не поддерживаемые файловыми базами геоданных, включают DISTINCT, GROUP BY и ORDER BY, а также набор функций AVG, COUNT, MIN, MAX и SUM не поддерживаются внешними подзапросами. Поддержка некоторых из них, вероятно, будет добавлена ​​в будущих выпусках ".

Четыре года спустя в версии 10 ни одна из этих функций и возможностей не доступна. ( Список доступных функций )

Похоже, что FGDB находится в стадии разработки, и ему нужны возможности многоколоночного индексирования, а также все необходимые функции СУБД SQL. Я предполагаю, что мы застрянем с PGDB, пока разработчики ESRI не решат, что важно расширить его функциональность до FGDB.

Возродив эту тему / проблему, я обнаружил, что было бы полезно объединить, где это возможно, FGDB и PGDB. Например, сделать базу данных геоданных PGDB очень помогло в производительности запросов. Размер PGDB не должен слишком увеличиваться, как указано выше.