ГИС: PostGIS / PostgreSQL против MySql против SQL Server? [закрыто]

РЕДАКТИРОВАТЬ: Я использую Postgres с PostGIS в течение нескольких месяцев, и я доволен.

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

Какая база данных лучше всего подходит для основного хранилища данных со всеми этими данными? Вот мои желания:

Я знаком с СУБД. Я слабее всего с PostgreSQL, но я хочу узнать, все ли проверено.Это хорошо с запросами ГИС. Поиски в Google показывают, что PostgreSQL + PostGIS могут быть самыми сильными? По крайней мере, многие продукты используют его. Пространственные расширения MySql кажутся сравнительно минимальными?Бюджетный. Несмотря на ограничение в 10 ГБ БД в SQL Server Express 2008 R2, я не уверен, что хочу жить с этим и другими ограничениями бесплатной версии.Не противоречит Microsoft .NET Framework. Благодаря Connector / Net 6.3.4 MySql хорошо работает на C # и .NET Framework 4 программах. Он полностью поддерживает .NET 4 Entity Framework. Я не могу найти никакого некоммерческого эквивалента PostgreSQL, хотя я не против того, чтобы платить 180 долларов за Devart dotConnect для PostgreSQL Professional Edition.Совместим с R. Похоже, что все 3 из них могут общаться с R, используя ODBC, поэтому это не проблема.

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

 OMG Ponies18 сент. 2010 г., 23:51
PostGIS был бы самым зрелым из вариантов.
 Aren Cambre21 мар. 2019 г., 12:45
Да. Также принятому ответу сейчас 8,5 лет. С тех пор развилось мышление? Будет ли новый ответ лучше сейчас?
 ErichBSchulz03 июн. 2014 г., 22:29
Отличный и важный вопрос. Мнения, основанные на фактах, являются ценными. Не должен был быть закрыт.
 Dave21 мар. 2019 г., 01:32
Как будто есть приз за закрытие темы на SO. Существует много актуальных вопросов, которые требуют мнения и опыта, подкрепленных ссылками. Вместо того, чтобы закрывать вопрос о предвзятом ожидании некачественных ответов, почему бы не смягчить некачественные ответы, если и когда они появятся.
 Wolph18 сент. 2010 г., 23:56
PostGIS - безусловно, самое зрелое ГИС-решение. И если вы используете R, вы даже можете использовать PL / R для написания хранимых процедур в R. Пространственные расширения MySQL довольно тонкие и не стоит их пытаться, возможности ГИС SQL Server довольно новы и кажутся несколько ограниченными, но у меня есть нет опыта с этим еще.

Ответы на вопрос(5)

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

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

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

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

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

 Mike T23 мая 2012 г., 07:33
похоже, что вместо использования пространственной библиотеки, такой как GEOS, вся пространственная логика находится вsql/item_geofunc.cc
 John Powell03 июн. 2014 г., 16:28
@MikeT. Правильно, я знаю, потому что я был одним из бета-тестеров. Пространственная функциональность MySQL очень далека от Posgis и на самом деле не прогрессировала с тех пор, как Oracle вступил во владение. Для меня настоящим убийцей было то, что нет какой-либо группы ST_Union (geom) .... по какой-либо функциональности типа атрибута. Только ST_Union (geom1, geom2). Также не поддерживается преобразование из одного SRID в другой. И список продолжается.
Решение Вопроса

Если вы заинтересованы в тщательном сравнении, я рекомендую«Перекрестное сравнение SQL Server 2008 Spatial, PostgreSQL / PostGIS 1.3-1.4, MySQL 5-6» и / или«Сравните пространственные характеристики SQL Server 2008 R2, Oracle 11G R2, PostgreSQL / PostGIS 1.5» Бостон ГИС.

Учитывая ваши очки:

Я знаком с СУБД: Настроить базу данных PostGIS в Windows легко, используя управление PgAdmin3 также простоЭто хорошо с запросами ГИС: PostGIS определенно самый сильный из трех, только Oracle Spatial будет сопоставим, но будет дисквалифицирован, если учесть его стоимостьБюджетный: +1 за PostGIS точноНе антагонистично с Microsoft .NET Framework: Вы должны хотя бы иметь возможность подключиться через ODBC (см. вики Postgres)Совместим с R: не должно быть проблемой с любым из трех
 OMG Ponies19 сент. 2010 г., 00:57
Хех - Oracle Spatial была лицензией на 1 миллион долларов, как я слышал
 Aren Cambre02 янв. 2019 г., 02:38
@StefanSteiger Я в конечном итоге использовал Npgsql! Некоторые продвинутые функции в то время не были полностью выпечены, поэтому не могли использовать Entity Framework, но все же сделали свою работу!
 Aren Cambre08 мар. 2012 г., 04:08
Просто хочу сказать, почти 1,5 года спустя, что Postgres + PostGIS был абсолютно правильным ответом.
 Aren Cambre19 сент. 2010 г., 02:30
Спасибо. Вторая ссылка сравнения полезна. Я только нашел первый ранее, потому что у меня был MySql в моих поисковых терминах. Похоже, это PostgreSQL для меня!
 Stefan Steiger19 нояб. 2013 г., 07:54
почему ODBC? Вы можете использовать бесплатный и полностью функциональный открытый источник (MIT или MIT-подобная лицензия) Npgsql ADO.NET разъем ...

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

 j0k22 сент. 2012 г., 23:39
Какой-нибудь эталонный тест?

Я работал со всеми тремя базами данных и провел миграцию между ними, так что, надеюсь, я все еще смогу что-то добавить к старому посту. Десять лет назад мне было поручено поместить большой массив данных - 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 Мой опыт посещения конференций заключался в том, что пространственное было очень запоздалой мыслью - мы реализовали репликацию, разбиение и т. Д., Но это не работает с пространственным. РЕДАКТИРОВАТЬ: Впредстоящий релиз 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). Нет поддержки растров. Возможность выполнять комбинированный векторно-растровый анализ в БД - очень полезная функция ГИС.

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

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

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

PostGIS

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

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

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

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

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

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

5). Postgres - это полнофункциональная СУБД, полностью соответствующая стандартам, которая стремится быть близкой к стандартам 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) разработаны так, что они очень хорошо работают друг с другом, но не всегда имеют соответствие стандартам и совместимость в качестве основных целей. Если вы работаете в магазине только для Windows, это не проблема.

ОБНОВИТЬ: немного поиграв с SQL Server 2012, могу сказать, что он значительно улучшился. Теперь есть хорошая функция проверки геометрии, есть хорошая поддержка для типа данных Geography, включая объект FULL GLOBE, который позволяет представлять объекты, которые занимают более одного полушария, и поддерживаетСоставные кривые и круглые струны что полезно для точного и компактного представления дуг (и окружностей) среди прочего. Преобразование координат из одного CRS в другое по-прежнему необходимо выполнять в сторонних библиотеках, хотя в большинстве приложений это не является ограничителем показа.

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

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

 John Powell25 мая 2016 г., 13:03
@SandeepKumar. Вероятно, будет лучше, если вы зададите новый вопрос с описанием того, что вы уже пробовали, какова была производительность, какие у вас показатели и т. Д. Слишком много неизвестных, чтобы дать хороший ответ. Postgres имеет хорошую поддержку запросов диапазона дат. MySQL, как правило, не подходит для пространственной обработки, но может подойти для запросов, подобных приведенным выше.
 Sandeep Kumar25 мая 2016 г., 11:28
У меня есть таблица, которая содержит точку широты и долготы в типе данных географии, а один столбец содержит дату и время точки. Мы хотим найти записи с некоторым диапазоном дат и менее 1000 м или пересекаем любую точку или нет? Какая производительность лучше, если в моей таблице 99 миллионов записей? Пожалуйста, предложите мне .. Я ищу это за последние 7 дней и проверил на PostGIS и SQL Server, и я создал пространственный индекс. Похоже, SQL-сервер лучше, чем PostGIS, но я никогда не писал MYSQL, поэтому не знаю, как сравнить с MYSQL. Скажите, пожалуйста, что лучше?

Ваш ответ на вопрос