PostgreSQL vs. MySQL: comparação de recursos espaciais

Estamos no processo de construção de um aplicativo da web que possui um componente de dados espaciais. No início, nossas comparações de dados espaciais terão um determinado ponto e retornarão polígonos espaciais sobrepostos correspondentes.

Dito isto, nosso banco de dados tem muitos outros componentes que incluem todas as coisas típicas que você encontraria em seu banco de dados relacional geral.

Estamos no ponto do nosso projeto em que devemos escolher qual solução de banco de dados usar.

Todos os membros do projeto estão mais familiarizados com a implementação e administração do MySQL, mas todas as pesquisas sugerem que o PostgreSQL é a melhor solução - especialmente em relação aos dados espaciais usando o postGIS.

Esperamos (espero) que nosso aplicativo experimente muita ação com muitos usuários simultâneos.

Alguém com experiência em usar o MySQL como RDBMS com um componente de dados espaciais tem algum conselho / experiência a longo prazo?

Existem desvantagens no uso do PostGIS, com exceção da familiaridade?

Não posso falar de vantagens / desvantagens em relação ao MySQL, mas o código PostGIS é amplamente considerado como um dos melhores (em termos de velocidade / funcionalidade) e mais maduro (em termos de testes / exposição no mundo real) ) acessível.

A título de exemplo, houve uma conversa no PGEast 2010 por algumas pessoas da FAA sobre a conversão do banco de dados do aeroporto (usado pelo AeroNav e outros para compilar gráficos) para o Postgres / PostGIS da Oracle.
O site avationDB também é construído sobre o Postgres (8.0).

Se as consultas relacionadas ao GIS estiverem no centro do que você está fazendo, minha sugestão é seguir o Postgres. Certamente, ele pode lidar com tudo o que você normalmente faria em um banco de dados relacional.

Em termos de mudança do MySQL, a documentação por trás do Postgres é de primeira linha, e há também uma seção do Wiki do Oostgres sobre a mudança do MySQL para o Postgres .
A curva de aprendizado inicial pode ser um pouco íngreme e você pode precisar ajustar seu banco de dados e quaisquer procedimentos armazenados (se você já os escreveu para o MySQL), mas não é uma tarefa intransponível.

Você deve conseguir o suficiente para fazer a troca em algumas semanas e, se configurar um banco de dados de desenvolvimento, provavelmente poderá ser versado em tarefas rotineiras em um mês e confiante em saber onde procurar no manual para os não tão rotineiros.

Falando de coisas muito importantes. Aqui está uma lista de coisas que o PostGIS suporta totalmente ausentes no MySQL e MariaDB.

• SRID nos cálculos, dê a seus pontos um SRID diferente e você obterá valores diferentes de volta. Este é o prop Funções agregadas: de acordo com o meu conhecimento, o MySQL não oferece funções agregadas espaciais

K vizinho mais próximo: Somente o PostGIS suporta KNN. Encontre o ponto mais próximo de qualquer ponto usando apenas um índice: não é necessário calcular a distância de todos os pontos! O MySQL quebra a especificação e apenas verifica se dois valores têm o mesmo SRID. O PostGIS vem com um banco de dados de definições de pro4j para permitir o reconhecimento contínuo do SRID. Definir um SRID e chamar ST_Transform( uma função que o MySQL não possui ) reprojeta suas coordenadas.

No MySQL, todos os cálculos são feitos assumindo SRID 0, independentemente do valor real do SRID. SRID 0 representa um plano cartesiano infinito e plano sem unidades atribuídas aos seus eixos. No futuro, os cálculos podem usar os valores SRID especificados. Para garantir o comportamento do SRID 0, crie valores de geometria usando SRID 0. SRID 0 é o padrão para novos valores de geometria se nenhum SRID for especificado.

• Rasters : existem vários recursos aqui, desde a geração de varredura até a extração. Você pode gerar mapas de calor e similares.

• Geografia , o PostGIS suporta um tipo de geografia não projetado que não usa matemática cartesiana. Ele tem uma série de funções associadas que operam em esferaides oclares. Por outro lado, o MySQL não pode nem criar uma caixa delimitadora em um SRS geográfico a partir de dois pontos.

• Topologia , distinta das geometrias vetoriais, top geoms armazena nós e relações. Mova um nó, a borda também se move e você obtém uma nova face. Isso também força as bordas a serem direcionadas, o que as torna ideais para o roteamento. Como um sub-ponto, 100% do que o PgRouting faz não está disponível para o MySQL - então você não pode criar um Google Maps ou algo semelhante sobre ele.

• Geocodificação: existe uma extensão do geocoder no diretório contrib que funciona com os dados do censo e um carregador para instalar esses dados.

• Padronização de endereços: existe uma extensão que lida com endereços normalizados para facilitar a análise, armazenamento e comparação.

• Recursos do SQL-MM , você simplesmente não encontrará CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVEou MULTISURFACEno MySQL.

• nd cords: O PostGIS pode suportar formas e pontos 3dm, 3dz e 4d e o MySQL simplesmente não pode

• O MySQL suporta apenas índices r-tree. O PostGIS suporta r-tree (gist / gin) e BRIN (para grandes tabelas de geometria)

• Funções agregadas: o melhor que eu sei é que o MySQL não oferece funções agregadas espaciais

• K vizinho mais próximo: Somente o PostGIS suporta KNN . Encontre o ponto mais próximo de qualquer ponto usando apenas um índice: não é necessário calcular a distância de todos os pontos!

• Indexação. O PostgreSQL permite que você armazene quaisquer dados em seu índice espacial (que é um índice essencial / gin). Por exemplo, você pode armazenar os year(ou outros dados não espaciais) e os geomno mesmo índice. Veja btree_gine btree_gistpara mais informações sobre como fazer isso.

Além disso, provavelmente existem mais de 200 funções suportadas pelo PostGIS.

Em resumo, o MySQL não se aplica ao PostGIS e ele sabe disso. O PostGIS é um animal. Só queria explicar algumas dessas coisas.

Concordo totalmente com todas as declarações da primeira resposta, mas compartilhando minha própria experiência - fiz isso na Administração Nacional de Estradas do meu país: crítico de produção, site de alto tráfego. Sugiro que um aplicativo da Web seja alimentado pelo MySQL e PostgreSQL / PostGIS.

Para todas as coisas "típicas", o aplicativo da Web funciona perfeitamente com um CMS baseado em MySQL. Para todas as tarefas espaciais, o mesmo aplicativo da Web também funciona perfeitamente;) com o desenvolvimento personalizado baseado no PostgreSQL / PostGIS. O primeiro componente foi desenvolvido e é mantido sem esforço com as habilidades normais do MySQL. O segundo componente envolveu um pouco mais de pesquisa no começo.

Você não precisa forçar uma implementação inteira dispendiosa de coisas típicas no PostgreSQL / PostGIS não tão familiar e também não precisa forçar uma implementação subótima das coisas geoespaciais no MySQL. Deixe cada jogador jogar onde ele pode acertar.