PostgreSQL vs. MySQL: Vergleich der räumlichen Merkmale

Wir sind dabei, eine Webanwendung mit einer Geodatenkomponente zu entwickeln. Zu Beginn nehmen unsere Geodatenvergleiche einen bestimmten Punkt und geben übereinstimmende überlappende räumliche Polygone zurück.

Abgesehen davon enthält unsere Datenbank viele andere Komponenten, die all die typischen Dinge enthalten, die Sie in Ihrer allgemeinen relationalen Datenbank finden würden.

Wir befinden uns an dem Punkt in unserem Projekt, an dem wir die zu verwendende Datenbanklösung auswählen müssen.

Alle Projektmitglieder sind mit der Implementierung und Administration von MySQL besser vertraut, jedoch deuten alle Untersuchungen darauf hin, dass PostgreSQL die bessere Lösung ist - insbesondere in Bezug auf Geodaten unter Verwendung von postGIS.

Wir erwarten (hoffen), dass unsere Anwendung bei vielen gleichzeitigen Benutzern eine Menge Action erleben wird.

Hat jemand mit Erfahrung in der Verwendung von MySQL als RDBMS mit einer Geodatenkomponente langfristige Ratschläge / Erfahrungen?

Gibt es Nachteile bei der Verwendung von PostGIS mit Ausnahme der Vertrautheit?

Ich kann nicht mit Vor- und Nachteilen gegenüber MySQL sprechen, aber der PostGIS-Code wird allgemein als einer der besten (in Bezug auf Geschwindigkeit / Funktionalität) und ausgereiftesten (in Bezug auf Tests / reale Belichtung) angesehen ) verfügbar.

Auf der PGEast 2010 sprachen beispielsweise einige FAA-Mitglieder über die Umstellung ihrer Flughafendatenbank (die von AeroNav und anderen zur Erstellung von Karten verwendet wird) auf Postgres / PostGIS von Oracle.
Die avationDB-Site basiert ebenfalls auf Postgres (8.0).

Wenn GIS-bezogene Fragen im Mittelpunkt Ihrer Aktivitäten stehen, würde ich vorschlagen, mit Postgres zusammenzuarbeiten. Es kann sicherlich auch alles andere verarbeiten, was Sie normalerweise in einer relationalen Datenbank tun würden.

In Bezug auf den Wechsel von MySQL ist die Dokumentation hinter Postgres erstklassig, und es gibt auch einen Abschnitt im Oostgres-Wiki über den Wechsel von MySQL zu Postgres .
Die anfängliche Lernkurve mag etwas steil sein und Sie müssen möglicherweise Ihre Datenbank und alle gespeicherten Prozeduren optimieren (falls Sie sie bereits für MySQL geschrieben haben), aber es ist keine unüberwindliche Aufgabe.

Sie sollten in der Lage sein, in ein paar Wochen genug zu lernen, um den Wechsel durchzuführen, und wenn Sie eine Entwicklungsdatenbank einrichten, können Sie sich wahrscheinlich innerhalb eines Monats mit Routineaufgaben auskennen und sicher sein, dass Sie wissen, wo Sie im Handbuch nachschlagen müssen für die nicht so Routine.

Apropos einige sehr wichtige Dinge. Hier ist eine Liste der Dinge, die PostGIS unterstützt und die in MySQL und MariaDB überhaupt nicht vorhanden sind.

• Geben Sie in Berechnungen für die SRID Ihren Punkten eine andere SRID und Sie erhalten andere Werte zurück. Dies ist prop Aggregatfunktionen: Meines Wissens bietet MySQL keine räumlichen Aggregatfunktionen

K nächster Nachbar: Nur PostGIS unterstützt KNN. Finden Sie den nächsten Punkt zu einem beliebigen Punkt mit nur einem Index: Es ist nicht erforderlich, die Entfernung von allen Punkten zu berechnen! MySQL bricht die Spezifikation und überprüft nur, ob zwei Werte dieselbe SRID haben. PostGIS wird mit einer Datenbank mit pro4j-Definitionen geliefert , um eine nahtlose SRID- Erkennung zu ermöglichen. Das Setzen einer SRID und das Aufrufen ST_Transform( eine Funktion, die MySQL fehlt ), projizieren Ihre Koordinaten neu.

In MySQL werden alle Berechnungen mit der Annahme von SRID 0 durchgeführt, unabhängig vom tatsächlichen SRID-Wert. SRID 0 repräsentiert eine unendliche flache kartesische Ebene, deren Achsen keine Einheiten zugewiesen sind. In Zukunft werden bei Berechnungen möglicherweise die angegebenen SRID-Werte verwendet. Um das Verhalten von SRID 0 sicherzustellen, erstellen Sie Geometriewerte mit SRID 0. SRID 0 ist die Standardeinstellung für neue Geometriewerte, wenn keine SRID angegeben ist.

• Raster : Hier gibt es eine Vielzahl von Funktionen, von der Rastererstellung bis zur Extraktion. Sie können Heatmaps und ähnliches erstellen.

• Geografie , PostGIS unterstützt einen nicht projizierten Geografietyp, der überhaupt keine kartesische Mathematik verwendet. Es hat eine ganze Reihe von Funktionen, die mit abgeflachten Sphäroiden zusammenhängen. Umgekehrt kann MySQL in einem geografischen SRS nicht einmal von zwei Punkten aus einen Begrenzungsrahmen erstellen.

• Die Topologie unterscheidet sich von den Vektorgeometrien und speichert Knoten und Beziehungen. Bewegen Sie einen Knoten, bewegt sich auch die Kante und Sie erhalten eine neue Fläche. Dadurch werden auch Kanten gezwungen, ausgerichtet zu werden, wodurch sie sich ideal zum Fräsen eignen. Als Unterpunkt ist 100% dessen, was PgRouting tut, für MySQL nicht verfügbar - Sie können also einfach kein Google Maps oder ähnliches darüber erstellen.

• Geokodierung: Im Contrib-Verzeichnis gibt es eine Geokodierer-Erweiterung , die Volkszählungsdaten verarbeitet, und einen Loader zum Installieren dieser Daten.

• Adressstandardisierung: Es gibt eine Erweiterung , die das Normalisieren von Adressen für einfaches Parsen, Speichern und Vergleichen übernimmt.

• SQL-MM verfügt , werden Sie einfach nicht finden CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVEoder MULTISURFACEin MySQL.

• nd cords: PostGIS unterstützt 3DM-, 3DZ- und 4D-Formen und -Punkte, die MySQL einfach nicht unterstützt

• MySQL unterstützt nur R-Tree-Indizes. PostGIS unterstützt R-Tree (Gist / Gin) und BRIN (für große Geometrietabellen)

• Aggregatfunktionen: Meines Wissens bietet MySQL keine räumlichen Aggregatfunktionen

• K nächster Nachbar: Nur PostGIS unterstützt KNN . Finden Sie den nächsten Punkt zu jedem Punkt mit nur einem Index: Sie müssen nicht die Entfernung von allen Punkten berechnen!

• Indizierung. Mit PostgreSQL können Sie alle Daten in Ihrem räumlichen Index (der ein Gist / Gin-Index ist) speichern. Beispielsweise können Sie die year(oder andere nicht räumliche) Daten und die geomim selben Index speichern . Weitere Informationen hierzu finden Sie unter btree_ginund btree_gist.

Es gibt wahrscheinlich auch 200 oder mehr Funktionen, die von PostGIS unterstützt werden.

Kurz gesagt, MySQL hält sich nicht an PostGIS und es weiß es. PostGIS ist ein Biest. Ich wollte nur einige dieser Sachen erklären.

Ich stimme allen Aussagen der ersten Antwort voll und ganz zu, teile jedoch meine eigenen Erfahrungen. Ich schlage vor, dass eine Web-App sowohl von MySQL als auch von PostgreSQL / PostGIS gespeist wird.

Für all das "typische" Zeug funktioniert die Web-App einwandfrei mit einem MySQL-basierten CMS. Für alle räumlichen Aufgaben funktioniert dieselbe Web-App - auch einwandfrei;) mit einer auf PostgreSQL / PostGIS basierenden benutzerdefinierten Entwicklung. Die erste Komponente wurde entwickelt und wird mit normalen MySQL-Kenntnissen mühelos gewartet. Die zweite Komponente war anfangs mit etwas mehr Forschungsaufwand verbunden.

Sie müssen im nicht so vertrauten PostgreSQL / PostGIS keine kostspielige vollständige Implementierung von typischen Inhalten erzwingen, und Sie müssen auch keine suboptimale Implementierung der Geodaten in MySQL erzwingen. Lassen Sie jeden Spieler dort spielen, wo er treffen kann.