webentwicklung-frage-antwort-db.com.de

GIS: PostGIS / PostgreSQL vs. MySQL vs. SQL Server?

BEARBEITEN: Ich benutze Postgres seit einigen Monaten mit PostGIS und bin zufrieden.

Ich muss einige Millionen geokodierte Datensätze analysieren, von denen jeder Breiten- und Längengrad hat. Diese Datensätze enthalten Daten von mindestens drei verschiedenen Typen, und ich werde versuchen, herauszufinden, ob jeder Satz den anderen beeinflusst.

Welche Datenbank eignet sich am besten für den zugrunde liegenden Datenspeicher für all diese Daten? Hier sind meine Wünsche:

  • Ich bin mit dem DBMS vertraut. Ich bin mit PostgreSQL am schwächsten, aber ich bin bereit zu lernen, ob alles andere auscheckt.
  • Das funktioniert gut mit GIS-Abfragen. Die Google-Suche deutet darauf hin, dass PostgreSQL + PostGIS möglicherweise die stärkste ist. Zumindest scheinen viele Produkte damit zu arbeiten. Die räumlichen Erweiterungen von MySql scheinen vergleichsweise minimal zu sein?
  • Niedrige Kosten. Trotz des DB-Limits von 10 GB in SQL Server Express 2008 R2 bin ich mir nicht sicher, ob ich mit diesen und anderen Einschränkungen der kostenlosen Version leben möchte.
  • Kein Widerspruch zu Microsoft .NET Framework. Dank Connector/Net 6.3.4 funktioniert MySql gut mit C # - und .NET Framework 4-Programmen. Es unterstützt das Entity Framework von .NET 4 vollständig. Ich kann kein nicht-kommerzielles PostgreSQL-Äquivalent finden, obwohl ich nicht dagegen bin, 180 US-Dollar für Devarts dotConnect für PostgreSQL Professional Edition zu zahlen.
  • Kompatibel mit R. Es sieht so aus, als ob alle 3 mit R über ODBC kommunizieren können, sodass dies möglicherweise kein Problem darstellt.

Ich habe bereits einige Entwicklungen mit MySql durchgeführt, kann diese aber bei Bedarf ändern.

65
Aren Cambre

Wenn Sie an einem gründlichen Vergleich interessiert sind, empfehle ich "Vergleiche SQL Server 2008 Spatial, PostgreSQL/PostGIS 1.3-1.4, MySQL 5-6" und/oder "Vergleiche SQL Server 2008") R2, Oracle 11G R2, PostgreSQL/PostGIS 1.5 Spatial Features " von Boston GIS.

Berücksichtigung Ihrer Punkte:

  • Ich bin mit dem DBMS vertraut: Das Einrichten einer PostGIS-Datenbank unter Windows ist einfach, auch die Verwendung der PgAdmin3-Verwaltung ist unkompliziert
  • Bei GIS-Abfragen ist es gut: PostGIS ist definitiv das stärkste der drei, nur Oracle Spatial wäre vergleichbar, wird jedoch disqualifiziert, wenn man die Kosten berücksichtigt
  • Niedrige Kosten: + 1 für PostGIS sicher
  • Kein Widerspruch zu Microsoft .NET Framework: Sie sollten zumindest in der Lage sein, eine Verbindung über ODBC ( siehe Postgres wiki )
  • Kompatibel mit R: sollte bei keinem der drei Probleme geben
51
underdark

Ich habe mit allen drei Datenbanken gearbeitet und Migrationen zwischen ihnen durchgeführt, sodass ich hoffentlich noch etwas zu einem alten Beitrag hinzufügen kann. Vor zehn Jahren wurde ich beauftragt, einen größeren Datensatz (450 Millionen Geo-Objekte) aus GML in eine Geodatenbank zu stellen. Ich habe beschlossen, MySQL und Postgis auszuprobieren. Zu der Zeit gab es in SQL Server keine räumliche Umgebung, und wir hatten eine kleine Startatmosphäre, sodass MySQL eine gute Lösung zu sein schien. Anschließend war ich an MySQL beteiligt, nahm an mehreren Konferenzen teil und war maßgeblich am Betatest der GIS-konformeren Funktionen in MySQL beteiligt, die schließlich mit Version 5.5 veröffentlicht wurden. Anschließend war ich an der Migration unserer Geodaten zu Postgis und unserer Unternehmensdaten (mit räumlichen Elementen) zu SQL Server beteiligt. Das sind meine Erkenntnisse.

MySQL

1). Stabilitätsprobleme. Innerhalb von 5 Jahren hatten wir mehrere Probleme mit Datenbankbeschädigungen, die nur durch Ausführen von myismachk für die Indexdatei behoben werden konnten. Dieser Vorgang kann bei einer 450-Millionen-Zeilentabelle weit über 24 Stunden dauern.

2). Bis vor kurzem unterstützten nur MyISAM-Tabellen den räumlichen Datentyp. Das bedeutet, wenn Sie Transaktionsunterstützung wünschen, haben Sie Pech. InnoDB-Tabellentyp unterstützt jetzt räumliche Typen, aber keine Indizes für diese, was angesichts der typischen Größe von räumlichen Datensätzen nicht besonders nützlich ist. Siehe http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html Meine Erfahrung mit dem Besuch von Konferenzen war, dass räumliche Aspekte sehr viel nachträglicher waren - wir haben Replikation, Partitionierung usw. implementiert, funktioniert aber nicht mit räumlichen. BEARBEITEN: In der kommenden Version 5.7.5 unterstützt InnoDB endlich Indizes für räumliche Spalten, was bedeutet, dass ACID, Fremdschlüssel und räumliche Indizes endlich in derselben Engine verfügbar sind.

3). Die räumliche Funktionalität ist im Vergleich zu Postgis und SQL Server räumlich extrem eingeschränkt. Es gibt immer noch keine ST_Union-Funktion, die auf ein gesamtes Geometriefeld einwirkt. Dies ist eine der Abfragen, die ich am häufigsten ausführe. Sie können also nicht schreiben:

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

das ist sehr nützlich in einem GIS-Kontext. Select ST_Union(geom1, const_geom) from some_table, dh eine der Geometrien ist eine fest codierte konstante Geometrie, ist im Vergleich ein wenig einschränkend.

4). Keine Unterstützung für Raster. Die Möglichkeit einer kombinierten Vektor-Raster-Analyse in einer Datenbank ist eine sehr nützliche GIS-Funktionalität.

5). Keine Unterstützung für die Konvertierung von einem Raumbezugssystem in ein anderes.

6). Seit der Übernahme durch Oracle wurde Spatial tatsächlich ausgesetzt.

Um fair zu MySQL zu sein, unterstützte es unsere Website, WMS und die allgemeine räumliche Verarbeitung über mehrere Jahre hinweg und war einfach einzurichten. Andererseits war Datenkorruption ein Problem, und wenn Sie gezwungen sind, MyISAM-Tabellen zu verwenden, geben Sie viele Vorteile eines RDBMS auf.

Postgis

Angesichts der Probleme, die wir mit MySQL hatten, sind wir letztendlich auf Postgis umgestiegen. Die wichtigsten Punkte dieser Erfahrung waren.

1). Extreme Stabilität. Keine Datenbeschädigung in 5 Jahren und wir haben jetzt rund 25 Postgres/GIS-Boxen auf virtuellen Maschinen von Centos mit unterschiedlichen Belastungsgraden.

2). Schnelles Entwicklungstempo - Raster, Topologie und 3D-Unterstützung sind aktuelle Beispiele dafür.

3). Sehr aktive Community. Der Postgis-IRC-Kanal und die Mailingliste sind ausgezeichnete Ressourcen. Das Postgis-Referenzhandbuch ist ebenfalls exzellent. http://postgis.net/docs/manual-2.0/

4). Spielt sich sehr gut mit anderen Anwendungen unter dem Dach von OSGeo, wie GeoServer und GDAL.

5). Gespeicherte Prozeduren können außer in plpgsql in mehreren Sprachen geschrieben werden, z. B. Python oder R.

5). Postgres ist ein sehr standardkonformes RDBMS mit vollem Funktionsumfang, dessen Ziel es ist, den ANSI-Standards nahe zu kommen.

6). Unterstützung für Fensterfunktionen und rekursive Abfragen - nicht in MySQL, sondern in SQL Server. Dies hat das Schreiben komplexerer räumlicher Abfragen übersichtlicher gemacht.

SQL Server.

Ich habe nur die räumliche Funktionalität von SQL Server 2008 verwendet, und viele der Probleme dieser Version - mangelnde Unterstützung für Konvertierungen von einem CRS zu einem anderen, Hinzufügen eigener Parameter zu räumlichen Indizes - wurden behoben.

1). Da räumliche Objekte in SQL Server grundsätzlich CLR-Objekte sind, ist die Syntax verkehrt. Anstelle von ST_Area (geom) schreiben Sie geom.STArea (). Dies wird noch deutlicher, wenn Sie Funktionen miteinander verketten. Das Löschen des Unterstrichs in Funktionsnamen ist nur ein kleiner Ärger.

2). Ich hatte eine Reihe ungültiger Polygone, die von SQL Server akzeptiert wurden, und das Fehlen einer ST_MakeValid-Funktion kann dies etwas schmerzhaft machen.

3). Nur für Windows. Im Allgemeinen sind Microsoft-Produkte (wie auch ESRI-Produkte) so konzipiert, dass sie sehr gut miteinander funktionieren, aber die Einhaltung von Standards und die Interoperabilität sind nicht immer die Hauptziele. Wenn Sie einen Windows-Shop betreiben, ist dies kein Problem.

[~ # ~] Update [~ # ~] : Nachdem ich ein bisschen mit SQL Server 2012 gespielt habe, kann ich sagen, dass es erheblich verbessert wurde. Es gibt jetzt eine gute Geometrieüberprüfungsfunktion und eine gute Unterstützung für den Geografie-Datentyp, einschließlich eines FULL GLOBE-Objekts, mit dem Objekte dargestellt werden können, die mehr als eine Halbkugel belegen, und die Unterstützung für Compound Curves and Circular Strings Dies ist unter anderem nützlich für genaue und kompakte Darstellungen von Bögen (und Kreisen). Das Transformieren von Koordinaten von einem CRS in ein anderes muss noch in Bibliotheken von Drittanbietern durchgeführt werden, obwohl dies in den meisten Anwendungen kein Show Stopper ist.

Ich habe SQL Server nicht mit ausreichend großen Datenmengen verwendet, um eins zu eins mit Postgis/MySQL zu vergleichen, aber soweit ich weiß, verhalten sich die Funktionen korrekt und obwohl sie nicht ganz so umfassend wie Postgis sind, ist dies eine enorme Verbesserung der MySQL-Angebote .

Tut mir leid für eine so lange Antwort, ich hoffe, dass ein Teil der Schmerzen und Freude, die ich im Laufe der Jahre erlitten habe, jemandem helfen kann.

59
John Powell

PostGis auf jeden Fall. Hier ist der Grund.

  1. Postgres ist MySQL in der Leistung weit überlegen. Der Server ist fehlertoleranter und verfügt über sofort einsatzbereite Tools für den Lastenausgleich, das Caching und die Optimierung.
  2. PostGIS wird zum Standard in GIS-Apps.
  3. Es ist kostenlos.
18
dekomote

PostGIS ist das Beste, weil es heutzutage zum Standard in GIS-Anwendungen wird und PostGIS kostenlos ist. Es ist MySQL in der Leistung weit überlegen

0
Khalid Mahmood

Nur eine Anmerkung, die MySQL endlich in die richtige GIS-Logik aufgenommen hat.

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

Zu Kosten und Leistung kann ich jedoch noch keine Angaben machen

0
ErichBSchulz