Was ist der beste Hack, um große Datenmengen in PostGIS zu importieren?

Ich muss große Shapefiles (> 1 Million Datensätze) in PostGIS importieren und habe mich gefragt, wie ich das am besten machen kann.

Bildbeschreibung hier eingeben

In meiner Frage habe ich absichtlich das Wort "Hack" anstelle von "Tool" verwendet, da es meiner Meinung nach nicht so sehr darum geht, welches Tool, sondern welche Schritte oder Konfigurationseinstellungen verwendet werden sollen. Bisher habe ich das versucht SPIT Plugin (QGIS), das shp2pgsql Postgis - Tool und das GDAL ogr2ogr Werkzeug. Sie können meine vollständige Rezension zu diesem Beitrag anzeigen . Bisher habe ich festgestellt, dass sie alle bei einem großen Datensatz wirklich nicht reagieren. Ich habe mich gefragt, ob jemand ein ähnliches Problem hat und ob Sie etwas über den Ansatz mitteilen können.

postgis database big-data

— Doppelbyte
quelle

Antworten:

Ich habe einen Test für dich gemacht:

PostgreSQL 9.3
PostGIS 2.1
Windows 7
i7 3770 @ 3,4-GHz-Prozessor
GDAL 2.0-dev 64-bit
Shapefile mit 1,14 Millionen Polygonen, Dateigröße 748 MB

Ogr2ogr Befehl:

ogr2ogr -f PostgreSQL-PG: "Datenbankname = 'Datenbankname' Host = 'Adr.' Port = '5432' Benutzer = 'x' Kennwort = 'y'" test.shp --config PG_USE_COPY YES -nlt MULTIPOLYGON

Gesamtzeit: 1 Minute 30 Sek

— user30184
quelle

Danke für deine Antwort! Es scheint sehr schnell zu sein; Ich glaube, es hat bei mir möglicherweise nicht funktioniert, da ich das --config-Flag PG_USE_COPY YES nicht verwendet habe. Ich habe es gerade geschafft, es schnell zu importieren mit: psql target-db -U <Administrator> -p <Port> -h <Name der DB-Instanz> -c "\ Kopiere die Quelltabelle von 'source-table.csv' mit DELIMITER ' , '"(und dann die Geometrie rekonstruieren), was meiner Meinung nach ein ähnlicher Ansatz ist.

— Doppelbyte

COPY ist schneller und wird in GDAL 2.0 standardmäßig verwendet, wenn Daten in neue Tabellen geschrieben werden. Bei Verwendung von Einfügungen betrug die Standardgröße von Transaktionen (gesteuert mit dem Parameter -gt) vor GDAL Version 1.11 nur 200 Features, als sie auf 20000 Features erhöht wurde. Größere Transaktionen bedeuten weniger Transaktionen und das kann zu einer enormen Beschleunigung führen.

— user30184

Die Verwendung von COPY ist der Schlüssel, und mit shp2pgsql und dem Flag -D erhalten Sie wahrscheinlich eine noch schnellere Übersetzung. shp2pgsql -D test.shp | psql testdb

— Paul Ramsey

Paul, ist shp2pgsql -D dasselbe wie COPY? Nicht klar aus den Dokumenten, die besagen, dass dies das "Dump" -Format verwendet, aber ich bin nicht sicher, was das überhaupt für einen Upload-Vorgang (im Gegensatz zu einem Backup / Restore-Vorgang) bedeutet. Ich stelle fest, dass shp2pgsql-gui die Option "Daten mit COPY anstatt INSERT laden" hat, aber keine "Dump-Format" -Option. Stimmt die Annahme, dass diese identisch sind?

— Lee Hachadoorian

Ja, -D ist dasselbe wie COPY.

— Darrell Fuhriman

Nach den Vorschlägen von User30184 , Paul Ramsey und meinen eigenen Experimenten. Ich habe beschlossen, diese Frage zu beantworten.

Ich habe in dieser Frage nicht erwähnt, dass ich Daten auf einen Remote-Server importiere. (obwohl es in dem Blog-Beitrag beschrieben ist, auf den ich mich beziehe). Vorgänge wie Einfügungen über das Internet unterliegen einer Netzwerklatenz. Vielleicht ist es nicht unerheblich zu erwähnen, dass sich dieser Server auf Amazon RDS befindet , was mich daran hindert, ssh auf den Computer zu laden und Vorgänge lokal auszuführen.

Vor diesem Hintergrund habe ich meinen Ansatz überarbeitet und die Direktive "\ copy" verwendet, um ein Abbild der Daten in einer neuen Tabelle zu erstellen. Ich denke, diese Strategie ist ein wesentlicher Schlüssel, auf den auch in den Kommentaren / Antworten zu dieser Frage verwiesen wurde.

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

Diese Operation war unglaublich schnell. Da ich eine CSV importiert habe, musste ich die gesamte Geometrie ausfüllen, einen räumlichen Index hinzufügen usw. Es war immer noch bemerkenswert schnell, da ich damals Abfragen auf dem Server ausführte .

Ich habe mich entschlossen, auch die Vorschläge von user30184 , Paul Ramsey, zu vergleichen . Meine Datendatei war ein Punkt-Shapefile mit 3035369 Datensätzen und 82 MB.

Der ogr2ogr-Ansatz (mit der PG_USE_COPY-Direktive) endete in 1:03:00 m, was immer noch viel besser ist als zuvor.

Der shp2pgsql-Ansatz (unter Verwendung der -D-Direktive) endete in nur 00:01:04 m.

Es ist anzumerken, dass ogr2ogr während der Operation einen räumlichen Index erstellt hat, shp2pgsql jedoch nicht. Ich finde heraus , dass es effizienter ist , den Index zu erstellen , nachdem tat die Einfuhr, anstatt Blähungen den Importvorgang mit dieser Art der Anfrage.

Die Schlussfolgerung lautet: shp2pgsql ist bei richtiger Parametrisierung hervorragend für große Importe geeignet, insbesondere für solche, die in Amazon Web Services untergebracht werden sollen.

Raumtabelle mit mehr als 3 Millionen Datensätzen, die mit shp2pgsql importiert wurden

Eine ausführlichere Beschreibung dieser Schlussfolgerungen finden Sie in der Aktualisierung dieses Beitrags.

— Doppelbyte
quelle

Bevor Sie GDAL zu sehr beschuldigen, schauen Sie sich die Dokumentation an. Ogr2ogr ist nicht involviert, es ist eher der GDAL PostGIS-Treiber und es gibt eine Option zum Deaktivieren des räumlichen Index gdal.org/drv_pg.html . In ogr2ogr muss -lco SPATIAL_INDEX = NO hinzugefügt werden. GDAL hat auch einen anderen Treiber für PGDump, der besser zu Ihrem Anwendungsfall passt . Gdal.org/drv_pgdump.html . Vielleicht erwähnen Sie auch diese Dinge in Ihrem Blog.

— user30184

Der Geschwindigkeitsunterschied zwischen 1:03:00 und 00:01:04 zwischen ogr2ogr und shp2pgsql ist riesig. Ich bin sicher, dass es real ist, aber das Ergebnis kann nicht verallgemeinert werden. Wenn Sie mit einer lokalen PostGIS-Datenbank testen, ist der Unterschied viel geringer. Ihr Ergebnis bedeutet, dass etwas für ogr2ogr sehr schlecht läuft. Welche GDAL-Version haben Sie verwendet? Wenn es älter als Version 1.11 ist, haben Sie versucht, die Größe der Transaktionen durch Hinzufügen von -gt 60000 zu erhöhen?

— user30184

Es ist keine zusätzliche Aufblähung, die im Index beim Import erstellt wird, als dies anschließend zu tun. Der ausgegebene Befehl ist genau derselbe und die Zeit, die er benötigt, ist genau die gleiche. Wenn Sie möchten, dass shp2pgsql den Index hinzufügt, müssen Sie nur die Option '-I' hinzufügen.

— Darrell Fuhriman

Danke für deine Kommentare. Meine Fallstudie war ein Import in ein Postgres, das auf AWS ausgeführt wird. Daher war es für mich wichtig, dass die Transaktion über das Netzwerk gut lief. Ich habe das PG_USE_COPY-Flag für ogr2ogr verwendet, aber ich habe den PGDump-Treiber nicht ausprobiert, der auf der Manpage vielversprechend aussieht. Meine Version von GDAL ist 1.7. Ich sollte alles unter gleichen Bedingungen vergleichen (mit oder ohne Index), aber was Daniel mir sagt, ist dies nicht das Problem, da ich den Index ziemlich schnell in der Datenbank erstelle ...

— Doppelbyte

Ja, Fallstudien sind in Ordnung, wenn sie geschrieben wurden, damit die Leser nicht das Gefühl bekommen, dass die Ergebnisse auf das übertragen werden können, was sie wirklich darstellen. Zum Beispiel wäre es gut zu erwähnen, dass Sie den Test mit einer 5 Jahre alten GDAL-Version durchgeführt haben und dass seitdem möglicherweise eine gewisse Entwicklung stattgefunden hat oder nicht. Ihre Version benötigt mit Sicherheit einen höheren -gt-Wert, um eine gute Leistung zu erzielen, aber es macht sowieso wenig Sinn, mit einer älteren GDAL-Version als 1.10 zu testen.

— User30184