PostgreSQL vs. MySQL: confronto di caratteristiche spaziali

Siamo in procinto di costruire un'applicazione web che ha un componente di dati spaziali. All'inizio i nostri confronti di dati spaziali prenderanno un determinato punto e restituiranno poligoni spaziali sovrapposti corrispondenti.

Detto questo, il nostro database ha molti altri componenti che includono tutte le cose tipiche che potresti trovare nel tuo database relazionale generale.

Siamo nel punto del nostro progetto in cui dobbiamo scegliere quale soluzione di database utilizzare.

Tutti i membri del progetto hanno più familiarità con l'implementazione e l'amministrazione di MySQL, tuttavia tutte le ricerche suggeriscono che PostgreSQL è la soluzione migliore, soprattutto per quanto riguarda i dati spaziali che utilizzano PostGIS.

Ci aspettiamo (speriamo) che la nostra applicazione sperimenterà molta azione con molti utenti simultanei.

Qualcuno con esperienza nell'uso di MySQL come RDBMS con un componente di dati spaziali ha consigli / esperienze a lungo termine?

Ci sono degli svantaggi nell'utilizzo di PostGIS ad eccezione della familiarità?

Non posso parlare di vantaggi / svantaggi nei confronti di MySQL, ma il codice PostGIS è abbastanza ampiamente considerato come uno dei migliori (in termini di velocità / funzionalità) e più maturo (in termini di test / esposizione nel mondo reale ) a disposizione.

A titolo di esempio, alcune persone della FAA hanno tenuto un discorso a PGEast 2010 sulla conversione del loro database aeroportuale (utilizzato da AeroNav e altri per compilare grafici) in Postgres / PostGIS di Oracle.
Il sito avationDB è anche costruito su Postgres (8.0).

Se le domande relative al GIS sono al centro di ciò che stai facendo, il mio suggerimento sarebbe di seguire Postgres. Può certamente gestire tutto ciò che normalmente faresti anche in un database relazionale.

In termini di passaggio da MySQL, la documentazione dietro Postgres è di prim'ordine, e c'è anche una sezione del Wiki di Oostgres sul passaggio da MySQL a Postgres .
La curva di apprendimento iniziale potrebbe essere un po 'ripida e potrebbe essere necessario modificare il database e le procedure memorizzate (se le hai già scritte per MySQL), ma non è un'attività insormontabile.

Dovresti essere in grado di raccogliere abbastanza per effettuare il passaggio in un paio di settimane e, se imposti un database di sviluppo, puoi probabilmente essere esperto in attività di routine entro un mese e sicuro di sapere dove cercare nel manuale per quelli non così ordinari.

Parlando di alcune cose molto importanti. Ecco un elenco di cose che PostGIS supporta totalmente assenti in MySQL e MariaDB.

• SRID nei calcoli, assegna ai tuoi punti un SRID diverso e otterrai valori diversi indietro. Questo è prop Funzioni aggregate: per quanto ne so, MySQL non offre funzioni di aggregati spaziali

K vicino di casa: solo PostGIS supporta KNN. Trova il punto più vicino a qualsiasi punto usando solo un indice: non è necessario calcolare la distanza da tutti i punti! Er. MySQL rompe le specifiche e verifica solo che due valori abbiano lo stesso SRID. PostGIS viene fornito con un database di definizioni pro4j per consentire una perfetta conoscenza di SRID. L'impostazione di un SRID e la chiamata ST_Transform( manca una funzione di MySQL ) riproietteranno le tue coordinate.

In MySQL, tutti i calcoli vengono eseguiti assumendo SRID 0, indipendentemente dal valore SRID effettivo. SRID 0 rappresenta un piano cartesiano piatto infinito senza unità assegnate ai suoi assi. In futuro, i calcoli potrebbero utilizzare i valori SRID specificati. Per garantire il comportamento di SRID 0, creare valori di geometria utilizzando SRID 0. SRID 0 è l'impostazione predefinita per i nuovi valori di geometria se non viene specificato alcun SRID.

• Raster : ci sono un sacco di funzioni qui dalla generazione raster all'estrazione. È possibile generare mappe di calore e simili.

• Geografia , PostGIS supporta un tipo di geografia non proiettato che non utilizza affatto la matematica cartesiana. Ha un intero lento di funzioni associate che operano su sphereoids oblati. MySQL viceversa non può nemmeno creare un riquadro di delimitazione in un SRS geografico da due punti.

• Topologia , distinta dalle geometrie vettoriali, i topo geom memorizzano nodi e relazioni. Sposta un nodo, anche il bordo si sposta e ottieni una nuova faccia. Ciò forza anche la direzione dei bordi che li rende ideali per l'instradamento. Come punto di riferimento il 100% di ciò che fa PgRouting non è disponibile per MySQL, quindi non è possibile creare un Google Maps o simili su di esso.

• Geocodifica: esiste un'estensione del geocoder nella directory contrib che funziona con i dati del censimento e un caricatore per installarli.

• Standardizzazione degli indirizzi: esiste un'estensione che gestisce la normalizzazione degli indirizzi per analisi, archiviazione e confronto facili.

• Funzionalità SQL-MM , semplicemente non le troverai CIRCULARSTRING COMPOUNDCURVE CURVEPOLYGON MULTICURVEo MULTISURFACEin MySQL.

• nd cavi: PostGIS può supportare forme e punti 3dm, 3dz e 4d che MySQL semplicemente non può

• MySQL supporta solo indici r-tree. PostGIS supporta r-tree (gist / gin) e BRIN (per tabelle di grandi geometrie)

• Funzioni aggregate: per quanto ne so, MySQL non offre funzioni di aggregati spaziali

• K vicino di casa: solo PostGIS supporta KNN . Trova il punto più vicino a qualsiasi punto usando solo un indice: non è necessario calcolare la distanza da tutti i punti!

• Indicizzazione. PostgreSQL ti consente di memorizzare qualsiasi dato sul tuo indice spaziale (che è un indice gist / gin). Ad esempio, è possibile archiviare year(o altri dati non spaziali) e geomsullo stesso indice. Vedere btree_gine btree_gistper ulteriori informazioni su come eseguire questa operazione.

Inoltre, ci sono probabilmente circa 200 più funzioni supportate da PostGIS.

In breve, MySQL non è proprio PostGIS e lo sa. PostGIS è una bestia. Volevo solo spiegare alcune di queste cose.

Sono totalmente d'accordo con tutte le dichiarazioni della prima risposta, ma condividendo la mia esperienza personale - l'ho fatto sulla National Roads Administration del mio paese: critico di produzione, sito ad alto traffico. Suggerisco che un'app Web sia alimentata da MySQL e PostgreSQL / PostGIS.

Per tutte le cose "tipiche", l'app Web funziona perfettamente con un CMS basato su MySQL. Per tutte le attività spaziali, la stessa app Web funziona anche in modo impeccabile;) con PostgreSQL / PostGIS basato sullo sviluppo personalizzato. Il primo componente è stato sviluppato e mantenuto senza sforzo con le normali abilità di MySQL. Il secondo componente ha comportato un po 'più di ricerca all'inizio.

Non è necessario forzare un'intera costosa implementazione di elementi tipici in PostgreSQL / PostGIS non così familiare e non è necessario forzare un'implementazione non ottimale degli elementi geospaziali in MySQL. Lascia che ogni giocatore giochi dove può colpire.