PostgreSQL против MySQL: сравнение пространственных объектов

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

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

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

Все участники проекта более знакомы с реализацией и администрированием MySQL, однако все исследования показывают, что PostgreSQL является лучшим решением, особенно в отношении пространственных данных, использующих postGIS.

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

Кто-нибудь с опытом использования MySQL в качестве СУБД с компонентом пространственных данных имеет какие-либо долгосрочные советы / опыт?

Есть ли какие-либо недостатки использования PostGIS, за исключением знакомых?

Я не могу говорить о преимуществах / недостатках по сравнению с MySQL, но код PostGIS довольно широко считается одним из лучших (с точки зрения скорости / функциональности) и наиболее зрелым (с точки зрения тестирования / использования в реальных условиях). ) доступный.

В качестве примера, на PGEast 2010 говорили некоторые люди из FAA о преобразовании своей базы данных аэропорта (используемой AeroNav и другими для составления карт) в Postgres / PostGIS из Oracle.
Сайт avationDB также построен на основе Postgres (8.0).

Если в основе того, что вы делаете, лежат вопросы, связанные с ГИС, я бы предложил обратиться к Postgres. Конечно, он может обрабатывать все, что вы обычно делаете в реляционной базе данных.

С точки зрения перехода с MySQL документация, лежащая в основе Postgres, является первоклассной, а также есть раздел вики Oostgres о переходе с MySQL на Postgres .
Начальная кривая обучения может быть немного крутой, и вам может потребоваться настроить вашу базу данных и любые хранимые процедуры (если вы уже написали их для MySQL), но это не является непреодолимой задачей.

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

Говоря о некоторых очень важных вещах. Вот список вещей, которые PostGIS поддерживает, которые полностью отсутствуют в MySQL и MariaDB.

• SRID в расчетах, присвойте своим баллам другой SRID, и вы получите обратно разные значения. Это проп Агрегатные функции: насколько мне известно, MySQL не предлагает пространственных агрегатных функций.

K ближайший сосед: только PostGIS поддерживает KNN. Найти ближайшую точку к любой точке, используя только индекс: нет необходимости вычислять расстояние от всех точек! Er. MySQL нарушает спецификацию и только проверяет, что два значения имеют одинаковый SRID. PostGIS поставляется с базой данных определений pro4j для обеспечения полной осведомленности о SRID. Установка SRID и вызов ST_Transform( функции, которой нет в MySQL ) перепроектируют ваши координаты.

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

• Растры : здесь есть масса функций от создания растров до извлечения. Вы можете создавать тепловые карты и тому подобное.

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

• Топология , отличная от векторной геометрии, вершины хранят узлы и отношения. Переместите узел, край тоже переместится, и вы получите новое лицо. Это также заставляет ребра быть направленными, что делает их идеальными для маршрутизации. В качестве подпункта 100% того, что делает PgRouting , недоступно для MySQL - поэтому вы просто не можете создать Google Maps или тому подобное поверх него.

• Геокодирование: в каталоге contrib есть расширение геокодера, которое обрабатывает данные переписи, и загрузчик для установки этих данных.

• Стандартизация адресов: есть расширение, которое обрабатывает нормализующие адреса для удобного анализа, хранения и сравнения.

• Функции SQL-MM вы просто не найдете CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVEили MULTISURFACEв MySQL.

• nd шнуры: PostGIS может поддерживать формы и точки 3dm, 3dz и 4d, MySQL просто не может

• MySQL поддерживает только индексы r-дерева. PostGIS поддерживает r-дерево (gist / gin) и BRIN (для больших таблиц геометрии)

• Агрегатные функции: насколько мне известно, MySQL не предлагает пространственных агрегатных функций.

• K ближайший сосед: только PostGIS поддерживает KNN . Найти ближайшую точку к любой точке, используя только индекс: не нужно рассчитывать расстояние от всех точек!

• Индексирование. PostgreSQL позволяет хранить любые данные в вашем пространственном индексе (который является индексом gist / gin). Например, вы можете хранить year(или другие непространственные данные) и данные geomв одном индексе. Смотрите btree_ginи btree_gistдля получения дополнительной информации о том, как это сделать.

Кроме того, вероятно, существует около 200 или более функций, поддерживаемых PostGIS.

Короче говоря, MySQL не поддерживает PostGIS и знает это. ПостГИС это зверь. Просто хотел объяснить кое-что из этого.

Я полностью согласен со всеми утверждениями первого ответа, но делюсь своим собственным опытом - я сделал это в Национальной администрации автомобильных дорог моей страны: производственный критик, сайт с высоким трафиком. Я предлагаю, чтобы веб-приложение поддерживалось как MySQL, так и PostgreSQL / PostGIS.

Для всех «типичных» вещей, веб-приложение работает безупречно с CMS на основе MySQL. Для всех пространственных задач одно и то же веб-приложение работает - также без нареканий;) с PostgreSQL / PostGIS, основанным на индивидуальной разработке. Первый компонент был разработан и поддерживается без особых усилий с обычными навыками MySQL. Второй компонент включал немного больше исследовательских усилий в начале.

Вам не нужно форсировать дорогостоящую полную реализацию типичных вещей в не очень знакомом PostgreSQL / PostGIS, и вам не нужно форсировать неоптимальную реализацию геопространственных вещей в MySQL. Пусть каждый игрок играет, где он может ударить.