ГИС: PostGIS/PostgreSQL против MySql против SQL Server?

Ответ 1

Если вы заинтересованы в тщательном сравнении, я рекомендую "Cross Compare SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6" и/или "Сравнить SQL Server 2008 R2, Oracle 11G R2, PostgreSQL/PostGIS 1.5 Пространственные функции" от Boston GIS.

Учитывая ваши баллы:

• Я знаком с СУБД: настройка базы данных PostGIS в Windows проста, использование управления PgAdmin3 также прямолинейно.
• Он отлично справляется с запросами GIS: PostGIS определенно сильнейший из трех, только Oracle Spatial будет сопоставим, но дисквалифицирован, если вы считаете, что он стоит
• Низкая стоимость: +1 для PostGIS.
• Не противоречит Microsoft.NET Framework:. Вы должны хотя бы иметь возможность подключаться через ODBC (см. Postgres wiki)
• Совместимо с R: не должно быть проблемой ни с одним из трех

Ответ 2

Я работал со всеми тремя базами данных и делал миграции между ними, поэтому, надеюсь, я все равно могу добавить что-то в старый пост. Десять лет назад мне было поручено разместить довольно большие 450 миллионов пространственных объектов - набор данных из GML в пространственную базу данных. Я решил опробовать MySQL и Postgis, в то время, когда в SQL Server не было пространств, и у нас была небольшая атмосфера запуска, поэтому MySQL казался подходящим. Впоследствии я был вовлечен в MySQL, я присутствовал/выступал на нескольких конференциях и активно участвовал в бета-тестировании более совместимых с ГИС функций в MySQL, который был наконец выпущен с версией 5.5. Впоследствии я участвовал в переносе наших пространственных данных на Postgis и наши корпоративные данные (с пространственными элементами) на SQL Server. Это мои выводы.

MySQL

1). Проблемы стабильности. В течение 5 лет у нас было несколько проблем с повреждением базы данных, которые можно было устранить только за счет запуска myismachk в индексном файле, что может занять более 24 часов в таблице из 450 миллионов строк.

2). До недавнего времени только таблицы MyISAM поддерживали тип пространственных данных. Это означает, что если вам нужна поддержка транзакций, вам не повезло. Тип таблицы InnoDB теперь поддерживает пространственные типы, но не индексы на них, которые при типичных размерах пространственных наборов данных, не очень полезны. См. http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html. Мой опыт перехода к конференциям состоял в том, что пространственное звучание было очень запоздалым - мы реализовали репликацию, разбиение на разделы и т.д., Но это не работает с пространственным. EDIT: В предстоящем выпуске 5.7.5 InnoDB, наконец, поддержит индексы в пространственных столбцах, что означает, что ACID, внешние ключи и пространственные индексы, наконец, будут доступны в одном и том же движке.

3). Пространственная функциональность чрезвычайно ограничена по сравнению с пространством Postgis и SQL Server. Функция ST_Union по-прежнему отсутствует, которая действует на все поле геометрии, один из наиболее часто выполняемых запросов, т.е. Вы не можете писать:

select attribute, ST_Union(geom) from some_table group by some_attribute

что очень полезно в контексте ГИС. Select ST_Union(geom1, const_geom) from some_table, т.е. одна из геометрий представляет собой жестко закодированную константную геометрию, которая немного сравнивается.

4). Нет поддержки для растров. Возможность комбинированного векторно-растрового анализа в db - очень полезная функциональность ГИС.

5). Нет поддержки для преобразования из одной пространственной системы координат в другую.

6). С момента приобретения Oracle, пространственное положение действительно приостановлено.

В целом, если быть честным с MySQL, он поддерживал наш веб-сайт, WMS и общую пространственную обработку в течение нескольких лет, и его было легко настроить. С другой стороны, повреждение данных было проблемой, и, будучи вынужденным использовать таблицы MyISAM, вы отказываетесь от многих преимуществ РСУБД.

PostGIS

Учитывая проблемы, возникшие с MySQL, мы в конечном итоге перешли на Postgis. Ключевыми моментами этого опыта были.

1). Крайняя стабильность. Нет повреждения данных за 5 лет, и теперь у нас есть около 25 полей Postgres/GIS на виртуальных машинах centos при различной степени нагрузки.

2). Быстрые темпы развития - растровая, топологическая, трехмерная поддержка - вот недавние примеры этого.

3). Очень активное сообщество. Канал Postgis irc и список рассылки - отличные ресурсы. Справочное руководство Postgis также отлично. http://postgis.net/docs/manual-2.0/

4). Хорошо работает с другими приложениями под зонтиком OSGeo, такими как GeoServer и GDAL.

5). Хранимые процедуры могут быть записаны на многих языках, кроме по умолчанию plpgsql, таких как Python или R.

5). Postgres - это полнофункциональная RDBMS, совместимая со стандартами, которая направлена ​​на то, чтобы оставаться рядом со стандартами ANSI.

6). Поддержка оконных функций и рекурсивных запросов - не в MySQL, а в SQL Server. Это упростило запись более сложных пространственных запросов.

SQL Server.

Я использовал пространственную функциональность SQL Server 2008, и многие из неприятностей этой версии - отсутствие поддержки конверсий из одной CRS в другую, необходимость добавления ваших собственных параметров в пространственные индексы - теперь разрешены.

1). Поскольку пространственные объекты в SQL Server являются в основном объектами CLR, синтаксис ощущается назад. Вместо ST_Area (geom) вы пишете geom.STArea(), и это становится еще более очевидным, когда вы объединяете функции вместе. Отбрасывание подчеркивания в именах функций является лишь незначительным раздражением.

2). У меня было несколько недопустимых полигонов, которые были приняты SQL Server, и отсутствие функции ST_MakeValid может сделать это немного болезненным.

3). Только Windows. В целом продукты Microsoft (например, ESRI) разработаны для того, чтобы работать очень хорошо друг с другом, но не всегда имеют стандартную совместимость и функциональную совместимость в качестве основных целей. Если вы используете только магазин с окнами, это не проблема.

UPDATE: немного поиграв с SQL Server 2012, могу сказать, что он значительно улучшился. В настоящее время существует хорошая функция проверки геометрии, существует хорошая поддержка типа данных географии, включая объект FULL GLOBE, который позволяет представлять объекты, которые занимают более одного полушария и поддерживают сложные кривые и Circular Strings, который полезен для точных и компактных представлений дуг (и кругов) между прочим. Преобразование координат из одной CRS в другую все еще должно выполняться в сторонних библиотеках, хотя это не является пробной пробкой в ​​большинстве приложений.

Я не использовал SQL Server с достаточно большими наборами данных для сравнения один на один с Postgis/MySQL, но из того, что я видел, что функции ведут себя корректно и хотя не совсем так полно, как Postgis, это огромное улучшение на предложениях MySQL.

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

Ответ 3

PostGis определенно. Вот почему.

• Postgres намного превосходит MySQL в производительности. Сервер более отказоустойчив, имеет из коробки инструменты для балансировки нагрузки, кэширования и оптимизации.
• PostGIS становится стандартом в приложениях ГИС.
• Это бесплатно.

Ответ 4

Просто обратите внимание на то, что MySQL, наконец, добавил в правильную логику ГИС.

http://dev.mysql.com/doc/refman/5.6/en/functions-for-testing-spatial-relations-between-geometric-objects.html

Но я не могу комментировать стоимость или производительность на этом этапе

Ответ 5

PostGIS лучше, потому что в наши дни он становится стандартом в приложениях ГИС, и PostGIS является бесплатным. Он превосходит MySQL в производительности