大きなデータセットをPostGISにインポートするための最良のハックは何ですか?


21

私はPostGISに大きなシェープファイル(100万件以上のレコード)をインポートする必要があり、それを行う最善の方法について疑問に思っていました。

ここに画像の説明を入力してください

私の質問では、ツールの代わりに「ハック」という言葉を意図的に使用しました。これは、どのツールではなく、使用するステップまたは構成設定の問題であると思うからです。これまで、SPITプラグイン(QGIS)、shp2pgsql Postgisツール、GDAL ogr2ogrツールを試しましたこの投稿で私の完全なレビューを見ることができます。これまでのところ、大規模なデータセットを処理する場合、それらのすべてが本当に応答していません。誰かが同様の問題を経験したかどうか、そしてアプローチについて何かを共有できるかどうか疑問に思っていました。

回答:


18

私はあなたのためにテストを行いました:

  • PostgreSQL 9.3
  • PostGIS 2.1
  • Windows 7
  • i7 3770@3.4 GHzプロセッサー
  • GDAL 2.0-dev 64-ビット
  • 114万ポリゴンのシェープファイル、ファイルサイズ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 <admin user> -p <port> -h <DB instance name> -c "\ copy source-table from 'source-table.csv' from DELIMITER 'を使用して、すぐにインポートできました。 、 '"(およびジオメトリの再構築)、これは同様のアプローチだと思います。
ダブルバイト14

COPYはより高速で、データが新しいテーブルに書き込まれるときのGDAL 2.0のデフォルトになります。挿入を使用する場合、トランザクションのデフォルトサイズ(-gtパラメーターで制御)は、GDALバージョン1.11よりも前に2000フィーチャーに増やされたとき、200フィーチャーのみでした。より大きなトランザクションはより少ないトランザクションを意味し、それは大幅な高速化をもたらす可能性があります。
user30184 14

4
COPYを使用することが重要です。shp2pgsqlと-Dフラグを使用すると、おそらくさらに高速の翻訳が得られます。shp2pgsql -D test.shp | psql testdb
ポールラムジー

ポール、shp2pgsql -DはCOPYと同じですか?これは「ダンプ」形式を使用すると言っているドキュメントからは明らかではありませんが、それがアップロード(バックアップ/復元ではなく)操作にとって何を意味するのかわかりません。shp2pgsql-guiには「INSERTではなくCOPYを使用してデータを読み込む」オプションがありますが、「ダンプ形式」オプションはないので、これらが同じであると仮定して修正できますか?
リーハチャドリアン

はい、-DはCOPYを使用するのと同じです。
ダレルフフリマン14

9

user30184の提案の後、Paul Ramseyと私自身の実験。この質問に答えることにしました。

この質問では、データをリモートサーバーにインポートしているとは言いませんでした。(それは私が参照するブログ投稿で説明されていますが)。インターネットを介した挿入などの操作は、ネットワーク遅延の影響を受けます。おそらく、このサーバーがAmazon RDS上にあることを言及することは重要ではありません。

これを念頭に置いて、「\ copy」ディレクティブを使用してデータのダンプを新しいテーブルに昇格させて、アプローチを再設計しました。この戦略は重要なキーであり、この質問へのコメント/回答でも言及されていると思います。

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

この操作は非常に高速でした。csvをインポートしてから、ジオメトリの入力、空間インデックスの追加などのすべての作業を行いましたサーバーでクエリを実行していたため、それでも非常に高速でした。

私はまた、ベンチマークからの提案に決めたuser30184ポール・ラムジー。データファイルは、3035369レコードと82 MBのポイントシェープファイルでした。

ogr2ogrアプローチ(PG_USE_COPYディレクティブを使用)は1:03:00 mで終了しましたが、これは以前よりもはるかに優れています。

shp2pgsqlアプローチ(-Dディレクティブを使用)は、わずか00:01:04 mで終了しました。

shp2pgsqlは作成しませんでしたが、ogr2ogrは操作中に空間インデックスを作成したと言う価値があります。このタイプのリクエストでインポート操作を肥大化させるよりも、インポートを行ったにインデックスを作成する方がはるかに効率的であることがわかります。

結論は次のとおりです。shp2pgsqlは、適切にパラメーター化されている場合、大規模なインポート、つまりAmazon Web Servicesに収容されるものを実行するのに非常に適しています。

shp2pgsqlを使用してインポートされた、300万件を超えるレコードを含む空間テーブル

この投稿の更新で、これらの結論のより詳細な説明を読むことができます。


GDALを非難する前に、ドキュメントを参照してください。Ogr2ogrは関与せず、むしろGDAL PostGISドライバーであり、空間インデックスgdal.org/drv_pg.htmlを無効にするオプションがあります。ogr2ogrを使用するには、-lco SPATIAL_INDEX = NOを追加します。GDALはまたあなたのユースケースよりよく合うかもしれませんPGD​​umpのための別のドライバがあるgdal.org/drv_pgdump.htmlを。おそらくあなたはあなたのブログでもこれらのことを言及するでしょう。
user30184 14

1
ogr2ogrとshp2pgsqlの速度差1:03:00と00:01:04は非常に大きくなります。それは本物だと確信していますが、結果を一般化することはできません。ローカルPostGISデータベースでテストする場合、違いははるかに小さくなります。結果は、ogr2ogrにとって何かが非常に悪いことを意味します。どのGDALバージョンを使用しましたか?v。1.11より古い場合、-gt 60000のようなものを追加してトランザクションのサイズを増やしてみましたか?
user30184 14

1
インポートでインデックスを作成するのは、後で行うよりも肥大化することはありません。発行されたコマンドはまったく同じで、所要時間もまったく同じです。また、shp2pgsqlにインデックスを追加する場合は、「-I」オプションを追加するだけです。
ダレルフフリマン14

コメントしてくれてありがとう。私のケーススタディは、AWSで実行されているPostgresへのインポートであったため、トランザクションがネットワーク上で適切に機能することが重要でした。ogr2ogrでPG_USE_COPYフラグを使用しましたが、PGDumpドライバーは試しませんでした。マンページからは有望に見えます。GDALの私のバージョンは1.7です。I私は、データベースにかなり迅速にインデックスを作成するので...、(インデックスの有無にかかわらず)の条件の平等におけるベンチマークのすべての必要がありますが、ダニエルは、これは問題ではありません私に語ったものとは
ダブルバイト

1
はい、ケーススタディは、それらが実際に表現されているものに結果を一般化できると読者が感じないように書かれていればOKです。たとえば、5年前のGDALバージョンを使用してテストを実行し、それ以降に何らかの開発が行われる場合と行われない場合があることに言及しておくとよいでしょう。あなたのバージョンは確かにパフォーマンスを上げるためにより大きな-gt値を必要としますが、とにかく1.10より古いGDALバージョンでテストすることはあまり意味がありません。
user30184 14
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.