我必须将大型Shapefile文件(> 100万个记录)导入PostGIS,我一直在想最好的方法。



“ hack”一词,而不是工具,是有目的的,因为我认为这与使用哪种工具无关,而是要使用的一组步骤或配置设置。
到目前为止,我已经尝试了SPIT插件(QGIS),shp2pgsql Postgis工具和GDAL ogr2ogr工具。您可以在这篇文章中查看我的完整评论。
到目前为止,当处理大型数据集时,我发现它们都反应迟钝。我想知道是否有人遇到过类似的问题,以及您是否可以分享有关此方法的一些信息。

#1 楼

我为您做了一个测试:


PostgreSQL 9.3
PostGIS 2.1
Windows 7
i7 3770@3.4 GHz处理器
GDAL 2.0- dev的1百1百万个多边形的64位
shapefile,文件大小748 MB

Ogr2ogr命令:


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


总时间:1分钟30秒

评论


感谢您的回答!看起来真的很快;我认为这可能对我不起作用,因为我没有使用--config PG_USE_COPY YES标志;我只是设法使用以下命令快速导入它:psql target-db -U <管理员用户> -p <端口> -h <数据库实例名称> -c“ \”使用'DELIMITER'从'source-table.csv'复制源表,”(然后重建几何图形),我想这是一种类似的方法。

– doublebyte
2014年8月6日12:51

COPY更快,并且在将数据写入新表时将成为GDAL 2.0中的默认值。使用插入时,默认事务大小(由-gt参数控制)在GDAL 1.11版增加到20000个功能之前只有200个功能。更大的交易意味着更少的交易,并且可以产生巨大的加速。

–user30184
2014年8月6日12:59

使用COPY是关键,使用shp2pgsql和-D标志可能会获得更快的翻译。 shp2pgsql -D test.shp | psql测试数据库

– Paul Ramsey
2014年8月6日14:43

保罗,shp2pgsql -D与COPY一样吗?从文档中尚不清楚这是使用“转储”格式的文档,但我不确定这对上传(而不是备份/还原)操作意味着什么。我注意到shp2pgsql-gui有一个选项“使用COPY而不是INSERT加载数据”,但是没有“转储格式”选项,因此我假设这些相同是正确的吗?

– Lee Hachadoorian
2014年8月12日19:14

是的,-D与使用COPY相同。

–达雷尔·富里曼(Darrell Fuhriman)
14年8月19日在22:33

#2 楼

经过user30184的建议,Paul Ramsey和我自己进行了实验。我决定回答这个问题。

我没有在这个问题中提到将数据导入到远程服务器。 (尽管在我引用的博客文章中对此进行了描述)。互联网上的插入等操作会受到网络延迟的影响。也许不必提一下该服务器位于Amazon RDS上,这可以防止我通过SSH进入计算机并在本地运行操作。

牢记这一点,我使用“ \ copy”指令可将数据转储到新表中。我认为此策略是必不可少的关键,对此问题的评论/答案也提到了这一策略。

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


此操作非常快。自从导入csv之后,我便完成了填充几何体,添加空间索引等所有工作。由于当时我正在服务器上运行查询,因此它仍然非常快。

我决定还可以对user30184 Paul Ramsey的建议进行基准测试。我的数据文件是具有3035369条记录和82 MB的点shapefile。

ogr2ogr方法(使用PG_USE_COPY指令)在1:03:00 m处完成,仍然比以前好很多。

shp2pgsql方法(使用-D指令)仅在00:01:04 m结束。

值得一提的是,ogr2ogr在操作期间创建了空间索引,而shp2pgsql没有。我发现执行导入后创建索引比使用这种类型的请求膨胀导入操作要高效得多。

结论是:如果正确地设置了参数,shp2pgsql极其有用非常适合执行大型导入,即适合在Amazon Web Services中使用的导入。



有关此结论的更新,您可以阅读这些结论的更详细说明。发布。

评论


在您过多地指责GDAL之前,请先阅读一下文档。不涉及Ogr2ogr,它是GDAL PostGIS驱动程序,并且确实具有禁用空间索引gdal.org/drv_pg.html的选项。 ogr2ogr的用法是添加-lco SPATIAL_INDEX = NO。 GDAL还有另一个PGDump驱动程序,可能更适合您的用例gdal.org/drv_pgdump.html。也许您还会在博客中提及这些内容。

–user30184
2014年8月13日在6:54



ogr2ogr和shp2pgsql之间的速度差异1:03:00和00:01:04很大。我确信这是真实的,但结果无法一概而论。如果使用本地PostGIS数据库进行测试,则差异将小得多。您的结果意味着对ogr2ogr来说,事情变得非常糟糕。您使用了哪个GDAL版本?如果版本早于1.11版,您是否尝试通过添加-gt 60000之类的方法来增加事务的大小?

–user30184
14年8月13日在7:05

在导入中的索引中创建没有多余的膨胀,而之后要做。发出的命令完全相同,所需的时间也完全相同。另外,如果您希望shp2pgsql添加索引,则只需添加'-I'选项。

–达雷尔·富里曼(Darrell Fuhriman)
2014年8月19日在22:31



感谢您的意见。我的案例研究是对在AWS上运行的Postgres的导入,因此对我而言,交易在网络上的良好表现非常重要。我的确在ogr2ogr上使用了PG_USE_COPY标志,但是我没有尝试过PGDump驱动程序,从手册页上看它很有希望。我的GDAL版本是1.7。我应该在条件相等的情况下对所有内容进行基准测试(有或没有索引),但丹尼尔告诉我,这不是问题,因为我在数据库中很快创建了索引...

– doublebyte
2014年8月20日在6:43



是的,如果案例研究已经写好,那么读者就不会觉得结果可以推广到他们真正代表的意思。例如,最好提到您使用5年以前的GDAL版本进行了测试,此后可能会或可能不会发生某些开发。您的版本肯定需要更大的-gt值才能正常运行,但是无论如何,使用任何低于1.10的GDAL旧版本进行测试都没有太大意义。

–user30184
2014年8月25日在7:38