GIS:PostGIS/PostgreSQL与MySql与SQL Server的对比？

Question

编辑:我已经使用Postgres和PostGIS几个月了,我很满意.

我需要分析几百万个地理编码记录,每个记录都有纬度和经度.这些记录包括至少三种不同类型的数据,我将试图看看每一组是否影响另一组.

什么数据库最适合所有这些数据的底层数据存储？这是我的愿望:

• 我熟悉DBMS.我对PostgreSQL最弱,但我愿意学习其他所有东西.
• 它适用于GIS查询.谷歌搜索表明PostgreSQL + PostGIS可能是最强的吗？至少很多产品似乎都在使用它.MySql的Spatial Extensions似乎相对最小？
• 低成本.尽管SQL Server Express 2008 R2中的数据库限制为10GB,但我不确定是否要接受免费版本的此限制和其他限制.
• 与Microsoft .NET Framework不矛盾.感谢Connector/Net 6.3.4,MySql适用于C#和.NET Framework 4程序.它完全支持.NET 4的实体框架.虽然我不反对为Devart的dotConnect for PostgreSQL专业版支付180美元,但我找不到任何非商业性的PostgreSQL等价物.
• 与R兼容.看起来所有这三个都可以使用ODBC与R通信,因此可能不是问题.

我已经使用MySql进行了一些开发,但如果有必要我可以更改.

Answer 1

我已经使用了所有三个数据库并完成了它们之间的迁移,所以希望我仍然可以在旧帖子中添加一些东西.十年前,我的任务是将一个较大的--4.5亿个空间物体 - 从GML的数据集放到空间数据库中.我决定试用MySQL和Postgis,当时SQL Server中没有空间,我们的启动氛围很小,所以MySQL似乎很合适.我随后参与了MySQL,我参加了几次会议,并参与了对MySQL中更多符合GIS的功能的beta测试,这些功能最终在5.5版本中发布.我随后参与了将我们的空间数据迁移到Postgis以及将我们的公司数据(带有空间元素)迁移到SQL Server.这是我的发现.

MySQL的

1).稳定性问题.在5年的时间里,我们遇到了几个数据库损坏问题,这些问题只能通过在索引文件上运行myismachk来解决,这个过程在4.5亿行表上可以超过24小时.

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

这在GIS环境中非常有用.Select ST_Union(geom1, const_geom) from some_table,即,其中一个几何形状是硬编码的常数几何形状,相比之下有点限制.

4).不支持栅格.能够在db中进行组合矢量栅格分析是非常有用的GIS功能.

5).不支持从一个空间参照系转换到另一个空间参考系.

6).自Oracle收购以来,空间已被搁置.

总的来说,为了公平对待它,它支持我们的网站,WMS和一般空间处理多年,并且易于设置.在缺点方面,数据损坏是一个问题,并且通过被迫使用MyISAM表,您放弃了RDBMS的许多好处.

POSTGIS

鉴于我们对MySQL的问题,我们最终转换为Postgis.这次经历的关键点是.

1).极端稳定.5年内没有数据损坏,我们现在在不同程度的负载下,在centos虚拟机上有大约25个Postgres/GIS框.

2).快速发展 - 光栅,拓扑,3D支持是最近的例子.

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到另一个CRS的转换的支持,需要将自己的参数添加到空间索引 - 现在已经解决了.

1).由于SQL Server中的空间对象基本上是CLR对象,因此语法会感觉倒退.您可以编写geom.STArea()而不是ST_Area(geom),这在将函数链接在一起时变得更加明显.在函数名称中删除下划线只是一个小麻烦.

2).我有一些SQL Server接受的无效多边形,缺少ST_MakeValid函数会让这有点痛苦.

3).仅限Windows.通常,Microsoft产品(如ESRI)可以很好地相互协作,但并不总是将标准的合规性和互操作性作为主要目标.如果您正在运行仅限Windows的商店,这不是问题.

更新:在SQL Server 2012上玩了一下,我可以说它已经有了很大的改进.现在有一个很好的几何验证功能,对Geography数据类型有很好的支持,包括一个FULL GLOBE对象,它允许表示占据多个半球的对象,并支持复合曲线和圆形弦,这对于精确和紧凑有用弧形(和圆形)等的表示.将坐标从一个CRS转换到另一个CRS仍然需要在第三方库中完成,尽管在大多数应用程序中这不是一个显示阻塞.

我没有使用具有足够大的数据集的SQL Server来一对一地与Postgis/MySQL进行比较,但是从我看到的函数表现正确,虽然不如Postgis那么完整,但它对MySQL的产品有很大改进.

对不起这么长的答案,我希望我多年来所经历的一些痛苦和喜悦可能对某人有所帮助.

Answer 2

如果您对彻底比较感兴趣,我推荐"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 Spatial功能"通过波士顿GIS.

考虑你的观点:

• 我熟悉DBMS:在Windows上设置PostGIS数据库很容易,使用PgAdmin3管理也很简单
• 它适用于GIS查询: PostGIS绝对是三者中最强的,只有Oracle Spatial具有可比性,但如果考虑其成本则被取消资格
• 低成本:肯定是PostGIS的+1
• 与Microsoft .NET Framework没有对立:你至少应该能够通过ODBC连接(参见Postgres wiki)
• 与R兼容:三者中的任何一个都不应该是问题

Answer 3

PostGis肯定.这就是原因.

1. Postgres在性能方面远远优于MySQL.服务器具有更强的容错能力,具有用于负载平衡,缓存和优化的开箱即用工具.
2. PostGIS正在成为GIS应用程序的标准.
3. 免费.