PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

GIS:PostGIS/PostgreSQL vs MySql vs SQL Server?

Ho lavorato con tutti e tre i database e fatto migrazioni tra di loro, quindi spero di poter ancora aggiungere qualcosa a un vecchio post. Dieci anni fa mi è stato assegnato il compito di inserire un set di dati di grandi dimensioni -- 450 milioni di oggetti spaziali -- da GML a un database spaziale. Ho deciso di provare MySQL e Postgis, all'epoca non c'era spazio in SQL Server e avevamo una piccola atmosfera di avvio, quindi MySQL sembrava adatto. Successivamente sono stato coinvolto in MySQL, ho partecipato/parlato a un paio di conferenze e sono stato fortemente coinvolto nel beta testing delle funzioni più compatibili con GIS in MySQL che è stato finalmente rilasciato con la versione 5.5. Successivamente sono stato coinvolto nella migrazione dei nostri dati spaziali su Postgis e dei nostri dati aziendali (con elementi spaziali) su SQL Server. Queste sono le mie scoperte.

MySQL

1). Problemi di stabilità. Nel corso di 5 anni, abbiamo riscontrato diversi problemi di danneggiamento del database, che potevano essere risolti solo eseguendo myismachk sul file di indice, un processo che può richiedere ben più di 24 ore su una tabella di 450 milioni di righe.

2). Fino a poco tempo solo le tabelle MyISAM supportavano il tipo di dati spaziali. Ciò significa che se desideri il supporto per le transazioni sei sfortunato. Il tipo di tabella InnoDB ora supporta i tipi spaziali, ma non gli indici su di essi, il che, date le dimensioni tipiche dei set di dati spaziali, non è molto utile. Vedere http://dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html La mia esperienza dall'andare alle conferenze è stata che lo spazio era un ripensamento:abbiamo implementato la replica, il partizionamento, ecc. ma non funziona con spazial.EDIT:Nella prossima versione 5.7.5 InnoDB supporterà finalmente gli indici sulle colonne spaziali, il che significa che ACID, chiavi esterne e indici spaziali saranno finalmente disponibili nello stesso motore.

3). La funzionalità spaziale è estremamente limitata rispetto a Postgis e SQL Server spaziali. Non esiste ancora una funzione ST_Union che agisca su un intero campo geometrico, una delle query che eseguo più spesso, ovvero non puoi scrivere:

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

che è molto utile in un contesto GIS. Select ST_Union(geom1, const_geom) from some_table , ovvero una delle geometrie è una geometria costante codificata che è un po' limitante in confronto.

4). Nessun supporto per i raster. Essere in grado di eseguire analisi raster vettoriali combinate all'interno di un db è una funzionalità GIS molto utile.

5). Nessun supporto per la conversione da un sistema di riferimento spaziale a un altro.

6). Dall'acquisizione da parte di Oracle, lo spazio spaziale è stato davvero messo in attesa.

Nel complesso, per essere onesti con MySQL, ha supportato il nostro sito Web, il WMS e l'elaborazione spaziale generale per diversi anni ed è stato facile da configurare. L'aspetto negativo era che la corruzione dei dati era un problema e, essendo costretto a utilizzare le tabelle MyISAM, stai rinunciando a molti dei vantaggi di un RDBMS.

Postgis

Dati i problemi che abbiamo avuto con MySQL, alla fine ci siamo convertiti a Postgis. I punti chiave di questa esperienza sono stati.

1). Estrema stabilità. Nessun danneggiamento dei dati in 5 anni e ora abbiamo circa 25 box Postgres/GIS su centos macchine virtuali, con vari gradi di carico.

2). Rapido ritmo di sviluppo:raster, topologia, supporto 3D ne sono esempi recenti.

3). Comunità molto attiva. Il canale irc di Postgis e la mailing list sono risorse eccellenti. Anche il manuale di riferimento di Postgis è eccellente. http://postgis.net/docs/manual-2.0/

4). Funziona molto bene con altre applicazioni, sotto l'ombrello di OSGeo, come GeoServer e GDAL.

5). Le stored procedure possono essere scritte in molti linguaggi, a parte il plpgsql predefinito, come Python o R.

5). Postgres è un RDBMS molto conforme agli standard, completo di funzionalità, che mira a rimanere vicino agli standard ANSI.

6). Supporto per funzioni finestra e query ricorsive, non in MySQL, ma in SQL Server. Ciò ha reso la scrittura di query spaziali più complesse più pulita.

SQL Server.

Ho utilizzato solo la funzionalità spaziale di SQL Server 2008 e molti dei fastidi di quella versione (mancanza di supporto per le conversioni da un CRS a un altro, la necessità di aggiungere i propri parametri agli indici spaziali) sono stati risolti.

1). Poiché gli oggetti spaziali in SQL Server sono fondamentalmente oggetti CLR, la sintassi sembra all'indietro. Invece di ST_Area(geom) scrivi geom.STArea() e questo diventa ancora più ovvio quando concateni le funzioni insieme. L'eliminazione del carattere di sottolineatura nei nomi delle funzioni è solo un piccolo fastidio.

2). Ho avuto un certo numero di poligoni non validi che sono stati accettati da SQL Server e la mancanza di una funzione ST_MakeValid può renderlo un po' doloroso.

3). Solo Windows. In generale, i prodotti Microsoft (come quelli ESRI) sono progettati per funzionare molto bene tra loro, ma non sempre hanno la conformità agli standard e l'interoperabilità come obiettivi primari. Se gestisci un negozio di sole vetrine, questo non è un problema.

AGGIORNAMENTO :avendo giocato un po' con SQL Server 2012, posso dire che è stato notevolmente migliorato. Ora c'è una buona funzione di validazione della geometria, c'è un buon supporto per il tipo di dati Geography, incluso un oggetto FULL GLOBE, che permette di rappresentare oggetti che occupano più di un emisfero e il supporto per le curve composte e le stringhe circolari che è utile per accurati e compatti rappresentazioni di archi (e cerchi) tra le altre cose. La trasformazione delle coordinate da un CRS a un altro deve ancora essere eseguita in librerie di terze parti, sebbene questo non sia un ostacolo alla maggior parte delle applicazioni.

Non ho usato SQL Server con set di dati sufficientemente grandi per confrontare uno a uno con Postgis/MySQL, ma da quello che ho visto le funzioni si comportano correttamente e, sebbene non siano così complete come Postgis, è un enorme miglioramento delle offerte di MySQL .

Scusa per la risposta così lunga, spero che parte del dolore e della gioia che ho sofferto nel corso degli anni possano essere di aiuto a qualcuno.