web-dev-qa-db-ja.com

GIS：PostGIS / PostgreSQL vs. MySql vs. SQL Server？

編集：私はPostgresをPostGISで数か月使用しており、満足しています。

ジオコーディングされた数百万のレコードを分析する必要があります。各レコードには緯度と経度が含まれます。これらのレコードには、少なくとも3つの異なるタイプのデータが含まれており、各セットが他のセットに影響を与えるかどうかを確認しようとしています。

このすべてのデータの基礎となるデータストアに最適なデータベースはどれですか？私の欲望は次のとおりです。

  • 私はDBMSに精通しています。私はPostgreSQLに最も弱いですが、他のすべてがチェックアウトするかどうかを知りたいと思っています。
  • GISクエリに適しています。 Google検索では、PostgreSQL + PostGISが最も強力である可能性がありますか？少なくとも多くの製品がそれを使用しているようです。 MySqlのSpatial Extensionsは比較的最小限に見えますか？
  • 低コスト SQL Server Express 2008 R2には10GBのDB制限がありますが、無料版のこの制限やその他の制限に耐えたいとは思いません。
  • Microsoft .NET Frameworkと拮抗しません。 Connector/Net 6.3.4のおかげで、MySqlはC＃および.NET Framework 4プログラムでうまく機能します。 .NET 4のEntity Frameworkを完全にサポートしています。 DevartのPostgreSQL Professional EditionのdotConnectに180ドルを支払うことに反対するつもりはないが、PostgreSQLに相当する非商用のPostgreSQLは見つかりません。
  • Rと互換性がありますこれら3つすべてがODBCを使用してRと通信できるようであるため、問題ではない可能性があります。

MySqlを使用して既にいくつかの開発を行っていますが、必要に応じて変更できます。

mysqlpostgresqlgisgeocodingpostgis
65
Aren Cambre

徹底的な比較に興味がある場合は、 「SQL Server 2008 Spatialの比較、PostgreSQL/PostGIS 1.3-1.4、MySQL 5-6」 および/または "SQL Server 2008の比較R2、Oracle 11G R2、PostgreSQL/PostGIS 1.5空間機能 " ボストンGIS。

あなたのポイントを考慮して：

  • 私はDBMSに精通しています：WindowsでのPostGISデータベースの設定は簡単で、PgAdmin3管理を使用するのも簡単です
  • これはGISクエリに適しています：PostGISは3つの中で最も強力であり、Oracle Spatialのみが同等ですが、コストを考慮すると失格となります
  • 低コスト：確かにPostGISの+1
  • Microsoft .NET Frameworkと拮抗しない：少なくともODBC（- Postgres wikiを参照してください ）
  • R：と互換性があります
51
underdark

私は3つのデータベースすべてで作業し、それらの間で移行を行ったので、古い投稿に何かを追加できることを願っています。 10年前、私はGMLから空間データベースに4億5000万の空間オブジェクトである大規模なデータセットを配置することを任されました。私はMySQLとPostgisを試してみることにしました。当時はSQL Serverに空間がなく、小さなスタートアップの雰囲気があったので、MySQLはぴったりのようでした。その後、MySQLに関与し、いくつかの会議に参加/スポークし、最終的にバージョン5.5でリリースされたMySQLのよりGISに準拠した機能のベータテストに深く関与しました。その後、空間データをPostgisに、企業データ（空間要素を含む）をSQL Serverに移行しました。これらは私の発見です。

MySQL

1）。安定性の問題。 5年間で、データベース破損の問題がいくつか発生しました。これは、インデックスファイルでmyismachkを実行することによってのみ修正できます。このプロセスは、4億5000万行のテーブルで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関数はまだありません。これは、私が最も頻繁に実行するクエリの1つです。つまり、次のように書くことはできません。

_select attribute, ST_Union(geom) from some_table group by some_attribute
_

gISコンテキストで非常に便利です。 Select ST_Union(geom1, const_geom) from some_table、つまり、ジオメトリの1つはハードコーディングされた定数ジオメトリであり、比較ではビット制限です。

4）。ラスターはサポートされていません。データベース内でベクトルラスター解析を組み合わせて実行できることは、GISの非常に便利な機能です。

5）。ある空間参照系から別の空間参照系への変換はサポートされていません。

6）。 Oracleによる買収以来、空間は実際に保留にされています。

全体として、MySQLに公平であるために、数年間にわたってWebサイト、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）。 GeoServerやGDALなど、OSGeo傘下の他のアプリケーションと非常によく連携します。

5）。ストアドプロシージャは、PythonまたはR.）など、デフォルトのplpgsql以外の多くの言語で作成できます。

5）。 Postgresは、非常に標準に準拠した、フル機能のRDBMSであり、ANSI標準に近い状態を維持することを目的としています。

6）。ウィンドウ関数と再帰クエリのサポート-MySQLではなく、SQL Serverで。これにより、より複雑な空間クエリの記述が簡潔になりました。

SQLサーバー。

私はSQL Server 2008の空間機能のみを使用しましたが、そのリリースの多くの煩わしさ（あるCRSから別のCRSへの変換のサポートの欠如、独自のパラメーターを空間インデックスに追加する必要性）が解決されました。

1）。 SQL Serverの空間オブジェクトは基本的にCLRオブジェクトであるため、構文は逆に感じられます。 ST_Area（geom）の代わりにgeom.STArea（）を記述します。これは、関数を一緒にチェーンするとさらに明白になります。関数名にアンダースコアを削除することは、ささいな面倒です。

2）。 SQL Serverで受け入れられた無効なポリゴンが多数ありましたが、ST_MakeValid関数がないため、これが少し苦痛になります。

3）。 Windowsのみ。一般に、Microsoft製品（ESRI製品など）は互いに非常にうまく機能するように設計されていますが、標準のコンプライアンスと相互運用性が主な目的として常にあるとは限りません。 Windowsのみのショップを運営している場合、これは問題ではありません。

[〜＃〜] update [〜＃〜]：SQL Server 2012で少し遊んだことで、大幅に改善されたと言えます。現在、優れたジオメトリ検証機能があり、複数の半球を占めるオブジェクトの表現を可能にするFULL GLOBEオブジェクトを含むGeographyデータタイプの適切なサポートと 複合曲線と円形文字列 のサポートがあります。これは、とりわけ円弧（および円）の正確でコンパクトな表現に役立ちます。サードパーティのライブラリで座標を1つのCRSから別のCRSに変換する必要がありますが、これはほとんどのアプリケーションのショーストッパーではありません。

私はSQL ServerでPostgis/MySQLと1対1で比較するのに十分な大きさのデータセットを使用していませんが、関数が正しく動作するのを見て、Postgisほど完全には機能していませんが、MySQLの製品の大きな改善です。

このような長い回答を申し訳ありませんが、長年苦しんできた痛みや喜びが誰かの助けになることを願っています。

59
John Powell

PostGisは間違いなく。その理由は次のとおりです。

  1. Postgresは、パフォーマンスがMySQLよりもはるかに優れています。サーバーはよりフォールトトレラントであり、負荷分散、キャッシュ、および最適化のためのすぐに使えるツールを備えています。
  2. PostGISはGISアプリの標準になりつつあります。
  3. それは無料です。
18
dekomote

PostGISは最近のGISアプリケーションの標準になりつつあり、PostGISは無料であるため、最高です。パフォーマンスにおいてMySQLよりもはるかに優れています

0
Khalid Mahmood

MySQLが最終的に適切なGISロジックに追加したことに注意してください。

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

しかし、私はこの段階でコストやパフォーマンスについてコメントすることはできません

0
ErichBSchulz