Qual è l'hacking migliore per l'importazione di grandi set di dati in PostGIS?

Devo importare Shapefile di grandi dimensioni (> 1 milione di record) in PostGIS e mi sono chiesto quale sia il modo migliore per farlo.

inserisci qui la descrizione dell'immagine

Nella mia domanda ho usato la parola "hack", invece di strumento, apposta perché penso che questo non sia tanto una questione di quale strumento, ma quale serie di passaggi o impostazioni di configurazione da usare. Finora ho provato il plug-in SPIT (QGIS), lo strumento Postgis shp2pgsql e lo strumento ogr2ogr GDAL . Puoi vedere la mia recensione completa su questo post. Finora, li trovo tutti davvero non rispondenti, quando si tratta di un set di dati di grandi dimensioni. Mi chiedevo se qualcuno avesse riscontrato un problema simile e se tu potessi condividere qualcosa sull'approccio.

postgis database big-data

— doublebyte
fonte

Risposte:

Ho fatto un test per te:

PostgreSQL 9.3
PostGIS 2.1
Windows 7
Processore i7 3770@3,4 GHz
GDAL 2.0-dev 64-bit
file di forma di 1,14 milioni di poligoni, dimensione del file 748 MB

Comando Ogr2ogr:

ogr2ogr -f PostgreSQL PG: "dbname = 'databasename' host = 'addr' port = '5432' user = 'x' password = 'y'" test.shp --config PG_USE_COPY YES -nlt MULTIPOLYGON

Tempo totale: 1 minuto 30 sec

— user30184
fonte

Grazie per la tua risposta! Sembra davvero veloce; Penso che potrebbe non aver funzionato per me perché non ho usato il flag --config PG_USE_COPY YES; Sono appena riuscito a importarlo rapidamente usando: psql target-db -U <utente amministratore> -p <porta> -h <nome istanza DB> -c "\ copia la tabella di origine da 'source-table.csv' con DELIMITER ' , "" (e quindi ricostruire la geometria), che immagino sia un approccio simile.

— doublebyte,

COPY è più veloce e sarà l'impostazione predefinita in GDAL 2.0 quando i dati vengono scritti in nuove tabelle. Quando si utilizzano inserti, la dimensione predefinita delle transazioni (controllata con il parametro -gt) era solo 200 funzioni prima della versione 1.11 di GDAL quando è stata aumentata a 20000 funzioni. Transazioni più grandi significano meno transazioni e ciò può produrre un enorme aumento di velocità.

— user30184

L'uso di COPY è la chiave e probabilmente otterrai una traduzione ancora più veloce con shp2pgsql e il flag -D. shp2pgsql -D test.shp | psql testdb

— Paul Ramsey,

Paul, shp2pgsql -D è uguale a COPY? Non è chiaro dai documenti che affermano che questo utilizza il formato "dump", ma non sono sicuro di cosa significhi anche per un'operazione di upload (invece di un'operazione di backup / ripristino). Ho notato che shp2pgsql-gui ha un'opzione "Carica dati usando COPIA anziché INSERISCI", ma nessuna opzione "formato di dump", quindi ho ragione nel presumere che siano uguali?

— Lee Hachadoorian,

Sì, -D è uguale all'utilizzo di COPIA.

— Darrell Fuhriman,

Dopo i suggerimenti di user30184 , Paul Ramsey e i miei esperimenti. Ho deciso di rispondere a questa domanda.

In questa domanda non ho menzionato che sto importando dati su un server remoto. (anche se è descritto nel post sul blog a cui mi riferisco). Operazioni come inserti su Internet sono soggette a latenza di rete. Forse non è irrilevante menzionare che questo server si trova su Amazon RDS , il che mi impedisce di eseguire SSH sulla macchina ed eseguire operazioni localmente.

Tenendo presente questo, ho riprogettato il mio approccio, usando la direttiva "\ copy" per promuovere un dump dei dati in una nuova tabella. Penso che questa strategia sia una chiave essenziale, a cui è stato fatto riferimento anche nei commenti / risposte a questa domanda.

psql database -U user -h host.eu-west-1.rds.amazonaws.com -c "\copy newt_table from 'data.csv' with DELIMITER ','"

Questa operazione è stata incredibilmente veloce. Da quando ho importato un CSV, ho quindi avuto tutto il lavoro di popolare la geometria, aggiungendo un indice spaziale, ecc. Era ancora notevolmente veloce, dato che stavo eseguendo query sul server .

Ho deciso di confrontare anche i suggerimenti di user30184 , Paul Ramsey . Il mio file di dati era un file di punti con 3035369 record e 82 MB.

L'approccio ogr2ogr (usando la direttiva PG_USE_COPY) è terminato in 1:03:00 m, che è ancora * molto meglio di prima.

L'approccio shp2pgsql (usando la direttiva -D) è terminato in soli 00:01:04 m.

Vale la pena dire che ogr2ogr ha creato un indice spaziale durante l'operazione, mentre shp2pgsql no. Scopro che è molto più efficiente creare l'indice dopo aver effettuato l'importazione, piuttosto che gonfiare l'operazione di importazione con questo tipo di richiesta.

La conclusione è: shp2pgsql, se opportunamente parametrizzato, è estremamente adatto per eseguire grandi importazioni, vale a dire quelle da ospitare all'interno dei Amazon Web Services.

Tabella spaziale con oltre 3 milioni di record, importati usando shp2pgsql

Puoi leggere una descrizione più dettagliata di queste conclusioni, sull'aggiornamento di questo post.

— doublebyte
fonte

Prima di accusare troppo GDAL, dai un'occhiata alla documentazione. Ogr2ogr non è coinvolto, è piuttosto il driver GDAL PostGIS e ha un'opzione per disabilitare l'indice spaziale gdal.org/drv_pg.html . L'utilizzo con ogr2ogr è di aggiungere -lco SPATIAL_INDEX = NO. GDAL ha anche un altro driver per PGDump che potrebbe adattarsi meglio al tuo caso d'uso gdal.org/drv_pgdump.html . Forse citerai anche queste cose nel tuo blog.

— user30184,

La differenza di velocità 1:03:00 e 00:01:04 tra ogr2ogr e shp2pgsql è enorme. Sono sicuro che è reale ma il risultato non può essere generalizzato. Se esegui un test con un database PostGIS locale, la differenza sarà molto inferiore. Il tuo risultato significa che qualcosa va molto male per ogr2ogr. Quale versione GDAL hai usato? Se è più vecchio di v. 1.11 hai provato ad aumentare le dimensioni delle transazioni aggiungendo qualcosa come -gt 60000?

— user30184,

Non è necessario gonfiare ulteriormente l'indice nell'importazione di quanto non lo sia fare successivamente. Il comando emesso è esattamente lo stesso e il tempo impiegato è esattamente lo stesso. Inoltre, se si desidera che shp2pgsql aggiunga l'indice, è sufficiente aggiungere l'opzione '-I'.

— Darrell Fuhriman,

Grazie per i tuoi commenti Il mio caso di studio era un'importazione in un Postgres in esecuzione su AWS, quindi per me era importante che la transazione funzionasse bene sulla rete. Ho usato il flag PG_USE_COPY su ogr2ogr, ma non ho provato il driver PGDump, che dalla manpage sembra promettente. La mia versione di GDAL è 1.7. Dovrei confrontare tutto in uguaglianza di condizioni (con o senza l'indice), ma da ciò che Daniel mi dice che questo non è il problema, dal momento che creo l'indice abbastanza rapidamente nel database ...

— doublebyte

Sì, i casi studio vanno bene se sono stati scritti in modo che i lettori non abbiano la sensazione che i risultati possano essere generalizzati su ciò che rappresentano realmente. Ad esempio, sarebbe bene ricordare che hai fatto il test con la versione GDAL di 5 anni e che da allora potrebbe esserci o no qualche sviluppo. La tua versione ha sicuramente bisogno di un valore -gt più grande per funzionare bene ma comunque non ha molto senso testare con una versione GDAL precedente alla 1.10.

— user30184,