Qual é o melhor truque para importar grandes conjuntos de dados no PostGIS?

Tenho que importar grandes arquivos de forma (mais de 1 milhão de registros) para o PostGIS, e fiquei pensando sobre a melhor maneira de fazer isso.

insira a descrição da imagem aqui

Na minha pergunta, usei a palavra "hack", em vez de ferramenta, de propósito, porque acho que não se trata tanto de qual ferramenta, mas de qual conjunto de etapas ou definições de configuração usar. Até agora, tentei o plug-in SPIT (QGIS), a ferramenta shp2pgsql Postgis e a ferramenta GDAL ogr2ogr . Você pode ver minha resenha completa sobre este post. Até agora, acho que todos eles não respondem, ao lidar com um grande conjunto de dados. Eu queria saber se alguém experimentou um problema semelhante e se você poderia compartilhar algo sobre a abordagem.

postgis database big-data

— doublebyte
fonte

Respostas:

Eu fiz um teste para você:

PostgreSQL 9.3
PostGIS 2.1
Windows 7
Processador i7 3770@3,4 GHz
GDAL 2.0-dev 64 bits
shapefile de 1,14 milhão de polígonos, tamanho do arquivo 748 MB

Comando Ogr2ogr:

ogr2ogr -f PostgreSQL PG: "dbname = 'nome do banco de dados' host = 'addr' port = '5432' usuário = 'x' senha = 'y'" test.shp --config PG_USE_COPY YES -nlt MULTIPOLYGON

Tempo total: 1 minuto 30 seg

— user30184
fonte

Obrigado pela sua resposta! Parece muito rápido; Acho que pode não ter funcionado para mim porque não usei o sinalizador --config PG_USE_COPY YES; Eu apenas consegui importá-lo rapidamente usando: psql target-db -U <admin user> -p <port> -h <nome da instância do banco de dados> -c "\ copy source-table de 'source-table.csv' com DELIMITER ' , '"(e depois reconstruindo a geometria), que eu acho que é uma abordagem semelhante.

— Doublebyte 6/08/14

COPY é mais rápido e será o padrão no GDAL 2.0 quando os dados forem gravados em novas tabelas. Quando inserções são usadas, o tamanho padrão das transações (controlado com o parâmetro -gt) era de apenas 200 recursos antes da versão 1.11 do GDAL, quando foi aumentado para 20.000 recursos. Transações maiores significam menos transações e isso pode gerar uma enorme aceleração.

— user30184

O uso de COPY é essencial e você provavelmente obterá uma tradução ainda mais rápida com shp2pgsql e o sinalizador -D. shp2pgsql -D test.shp | psql testdb

— Paul Ramsey

Paul, shp2pgsql -D é o mesmo que COPY? Não está claro nos documentos que dizem que isso usa o formato "despejo", mas não tenho certeza do que isso significa para uma operação de upload (em oposição a uma operação de backup / restauração). Percebo que o shp2pgsql-gui tem a opção "Carregar dados usando COPY em vez de INSERT", mas não a opção "dump format", então estou certo ao assumir que são os mesmos?

— Lee Hachadoorian

Sim, -D é o mesmo que usar COPY.

— Darrell Fuhriman

Após as sugestões do user30184 , Paul Ramsey e minhas próprias experiências. Eu decidi responder a esta pergunta.

Não mencionei nesta pergunta que estou importando dados para um servidor remoto. (embora esteja descrito na postagem do blog a que me refiro). Operações como inserções na Internet estão sujeitas a uma latência de rede. Talvez não seja irrelevante mencionar que este servidor está no Amazon RDS , o que me impede de ssh na máquina e executar operações localmente.

Tendo isso em mente, refiz a engenharia da minha abordagem, usando a diretiva "\ copy" para promover um despejo de dados em uma nova tabela. Penso que esta estratégia é uma chave essencial, que também foi referida nos comentários / respostas a esta pergunta.

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

Esta operação foi incrivelmente rápida. Desde que importei um CSV, tive todo o trabalho de preencher a geometria, adicionar um índice espacial, etc. Ainda era notavelmente rápido, pois estava executando consultas no servidor .

Decidi comparar também as sugestões do usuário30184 , Paul Ramsey . Meu arquivo de dados era um shapefile de ponto com 3035369 registros e 82 MB.

A abordagem ogr2ogr (usando a diretiva PG_USE_COPY) terminou em 1:03:00 m, que ainda é * muito melhor do que antes.

A abordagem shp2pgsql (usando a diretiva -D) terminou em apenas 00:01:04 m.

Vale dizer que o ogr2ogr criou um índice espacial durante a operação, enquanto o shp2pgsql não. Descobri que é muito mais eficiente criar o índice após a importação, em vez de inchar a operação de importação com esse tipo de solicitação.

A conclusão é: o shp2pgsql, quando adequadamente parametrizado, é extremamente adequado para realizar grandes importações, principalmente aquelas a serem acomodadas no Amazon Web Services.

Tabela espacial com mais de 3 milhões de registros, importados usando shp2pgsql

Você pode ler uma descrição mais detalhada dessas conclusões, na atualização deste post.

— doublebyte
fonte

Antes de acusar demais a GDAL, consulte a documentação. Ogr2ogr não está envolvido, é o driver GDAL PostGIS e tem uma opção para desativar o índice espacial gdal.org/drv_pg.html . O uso com ogr2ogr é adicionar -lco SPATIAL_INDEX = NO. O GDAL também possui outro driver para o PGDump, que pode se adequar melhor ao seu caso de uso gdal.org/drv_pgdump.html . Talvez você mencione também essas coisas no seu blog.

— user30184

A diferença de velocidade 1:03:00 e 00:01:04 entre ogr2ogr e shp2pgsql é enorme. Estou certo de que é real, mas o resultado não pode ser generalizado. Se você testar com um banco de dados PostGIS local, a diferença será muito menor. Seu resultado significa que algo corre muito mal para ogr2ogr. Qual versão do GDAL você usou? Se for anterior à versão 1.11, você tentou aumentar o tamanho das transações adicionando algo como -gt 60000?

— user30184

Não é um inchaço adicional criar no índice na importação do que fazê-lo depois. O comando emitido é exatamente o mesmo e o tempo que leva exatamente o mesmo. Além disso, se você quiser que o shp2pgsql adicione o índice, basta adicionar a opção '-I'.

— Darrell Fuhriman

Obrigado por seus comentários. Meu estudo de caso foi uma importação para um Postgres em execução na AWS, por isso era importante para mim que a transação tivesse um bom desempenho na rede. Usei o sinalizador PG_USE_COPY no ogr2ogr, mas não tentei o driver PGDump, que na página de manual parece promissor. Minha versão do GDAL é 1.7. I deve tudo referência em igualdade de condições (com ou sem o índice), mas pelo que Daniel me diz que isso não é o problema, desde que eu criar o índice muito rapidamente no banco de dados ...

— doublebyte

Sim, os estudos de caso são válidos se tiverem sido escritos para que os leitores não sintam que os resultados podem ser generalizados para o que eles realmente representam. Por exemplo, seria bom mencionar que você fez o teste com a versão GDAL de 5 anos e que algum desenvolvimento pode ou não acontecer desde então. Sua versão precisa, com certeza, de um valor -gt maior para ter um bom desempenho, mas, de qualquer forma, não faz muito sentido testar com qualquer versão GDAL anterior à 1.10.

— user30184