PostgreSQL vs. MySQL: comparación de características espaciales

Estamos en el proceso de crear una aplicación web que tenga un componente de datos espaciales. Al principio, nuestras comparaciones de datos espaciales tomarán un punto dado y devolverán polígonos espaciales superpuestos coincidentes.

Dicho esto, nuestra base de datos tiene muchos otros componentes que incluyen todas las cosas típicas que encontrará en su base de datos relacional general.

Estamos en el punto de nuestro proyecto donde debemos elegir qué solución de base de datos usar.

Todos los miembros del proyecto están más familiarizados con la implementación y administración de MySQL, pero toda la investigación sugiere que PostgreSQL es la mejor solución, especialmente en lo que respecta a los datos espaciales que utilizan postGIS.

Esperamos (esperamos) que nuestra aplicación experimente mucha acción con muchos usuarios concurrentes.

¿Alguien con experiencia en el uso de MySQL como su RDBMS con un componente de datos espaciales tiene algún consejo / experiencia a largo plazo?

¿Hay alguna desventaja de usar PostGIS con la excepción de la familiaridad?

No puedo hablar de las ventajas / desventajas frente a MySQL, pero el código PostGIS es ampliamente considerado como uno de los mejores (en términos de velocidad / funcionalidad) y más maduro (en términos de pruebas / exposición en el mundo real ) disponible.

A modo de ejemplo, algunas personas de la FAA hablaron en PGEast 2010 sobre la conversión de su base de datos del aeropuerto (utilizada por AeroNav y otros para compilar cartas) a Postgres / PostGIS de Oracle.
El sitio avationDB también está construido sobre Postgres (8.0).

Si las consultas relacionadas con SIG están en el centro de lo que está haciendo, mi sugerencia sería ir con Postgres. Ciertamente, también puede manejar todo lo que normalmente haría en una base de datos relacional.

En términos de hacer el cambio de MySQL, la documentación detrás de Postgres es de primer nivel, y también hay una sección de Oostgres Wiki sobre el cambio de MySQL a Postgres .
La curva de aprendizaje inicial puede ser un poco empinada y es posible que deba modificar su base de datos y cualquier procedimiento almacenado (si ya los ha escrito para MySQL), pero no es una tarea insuperable.

Debería poder recoger lo suficiente para hacer el cambio en un par de semanas, y si configura una base de datos de desarrollo, probablemente pueda estar bien versado en las tareas de rutina dentro de un mes y tener la confianza de saber dónde buscar en el manual para los no tan rutinarios.

Hablando de algunas cosas muy importantes. Aquí hay una lista de cosas que admite PostGIS que están totalmente ausentes en MySQL y MariaDB.

• SRID en los cálculos, otorgue a sus puntos un SRID diferente y obtendrá diferentes valores. Esto es prop. Funciones de agregado: que yo sepa, MySQL no ofrece funciones de agregados espaciales

K vecino más cercano: solo PostGIS es compatible con KNN. Encuentre el punto más cercano a cualquier punto utilizando solo un índice: ¡no es necesario calcular la distancia desde todos los puntos! MySQL rompe las especificaciones y solo verifica que dos valores tengan el mismo SRID. PostGIS viene con una base de datos de definiciones pro4j para permitir una conciencia SRID sin interrupciones. Establecer un SRID y llamar ST_Transform( una función que carece de MySQL ) volverá a proyectar sus coordenadas.

En MySQL, todos los cálculos se realizan suponiendo SRID 0, independientemente del valor real de SRID. SRID 0 representa un plano cartesiano plano infinito sin unidades asignadas a sus ejes. En el futuro, los cálculos pueden usar los valores SRID especificados. Para garantizar el comportamiento de SRID 0, cree valores de geometría utilizando SRID 0. SRID 0 es el valor predeterminado para los nuevos valores de geometría si no se especifica SRID.

• Rásters : hay un montón de características aquí, desde la generación de ráster hasta la extracción. Puede generar mapas de calor y similares.

• Geografía , PostGIS admite un tipo de geografía no proyectada que no utiliza matemáticas cartesianas en absoluto. Tiene toda una lentitud de funciones asociadas que operan en esferoides achatados. Por el contrario, MySQL ni siquiera puede crear un cuadro delimitador en un SRS geográfico desde dos puntos.

• La topología , distinta de las geometrías vectoriales, las topografías topográficas almacenan nodos y relaciones. Mueve un nodo, el borde también se mueve y obtienes una nueva cara. Esto también obliga a dirigir los bordes, lo que los hace ideales para el enrutamiento. Como subpunto, el 100% de lo que hace PgRouting no está disponible para MySQL, por lo que simplemente no puede crear un Google Maps o similar encima.

• Geocodificación: hay una extensión de geocodificador en el directorio contrib que funciona con datos del censo y un cargador para instalar esos datos.

• Estandarización de direcciones: hay una extensión que maneja direcciones de normalización para facilitar el análisis, el almacenamiento y la comparación.

• Características de SQL-MM , simplemente no encontrará CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVEni MULTISURFACEen MySQL.

• cables nd: PostGIS puede soportar formas y puntos 3dm, 3dz y 4d que MySQL simplemente no puede

• MySQL solo admite índices r-tree. PostGIS admite r-tree (gist / gin) y BRIN (para tablas de geometría grandes)

• Funciones agregadas: que yo sepa, MySQL no ofrece funciones agregadas espaciales

• K vecino más cercano: solo PostGIS es compatible con KNN . Encuentre el punto más cercano a cualquier punto utilizando solo un índice: ¡no es necesario calcular la distancia desde todos los puntos!

• Indexación. PostgreSQL le permite almacenar cualquier dato en su índice espacial (que es un índice gist / gin). Por ejemplo, puede almacenar el year(u otros datos no espaciales) y el geomen el mismo índice. Consulte btree_giny btree_gistpara obtener más información sobre cómo hacer esto.

Además, probablemente haya más de 200 funciones compatibles con PostGIS.

En resumen, MySQL no se mantiene firme en PostGIS y lo sabe. PostGIS es una bestia. Solo quería explicar algunas de estas cosas.

Estoy totalmente de acuerdo con todas las declaraciones de la primera respuesta, pero comparto mi propia experiencia. Lo hice en la Administración Nacional de Caminos de mi país: crítico de producción, sitio de alto tráfico. Sugiero que una aplicación web sea alimentada por MySQL y PostgreSQL / PostGIS.

Para todas las cosas "típicas", la aplicación web funciona perfectamente con un CMS basado en MySQL. Para todas las tareas espaciales, la misma aplicación web funciona -también perfectamente;) con el desarrollo personalizado basado en PostgreSQL / PostGIS. El primer componente fue desarrollado y se mantiene sin esfuerzo con las habilidades normales de MySQL. El segundo componente implicó un poco más de esfuerzo de investigación al principio.

No tiene que forzar una implementación completa costosa de cosas típicas en PostgreSQL / PostGIS no tan familiar y tampoco tiene que forzar una implementación subóptima de cosas geoespaciales en MySQL. Deje que cada jugador juegue donde pueda golpear.