Как лучше всего импортировать большие наборы данных в PostGIS?

Мне нужно импортировать большие файлы шейп-файлов (> 1 миллион записей) в PostGIS, и я задумался о том, как лучше всего это сделать.

введите описание изображения здесь

В своем вопросе я специально использовал слово «хак» вместо инструмента, потому что я думаю, что дело не в том, какой инструмент, а в том, какой набор шагов или настроек конфигурации использовать. До сих пор я пробовал плагин SPIT (QGIS), инструмент Postgis shp2pgsql и инструмент ogr2ogr GDAL . Вы можете просмотреть мой полный обзор этого поста. Пока что я считаю, что все они действительно не отвечают, когда имеют дело с большим набором данных. Мне было интересно, если кто-то сталкивался с подобной проблемой, и вы могли бы поделиться чем-то о подходе.

postgis database big-data doublebyte
источник

Ответы:

Я сделал тест для вас:

PostgreSQL 9.3
PostGIS 2.1
Windows 7
процессор i7 3770 @ 3,4 ГГц
GDAL 2.0-dev 64-bit
шейп-файл из 1,14 миллиона полигонов, размер файла 748 МБ

Команда 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 секунд

user30184
источник

Спасибо за Ваш ответ! Это кажется действительно быстрым; Я думаю, что это, возможно, не сработало для меня, потому что я не использовал флаг --config PG_USE_COPY YES; Мне просто удалось быстро импортировать его с помощью: psql target-db -U <пользователь-администратора> -p <порт> -h <имя экземпляра БД> -c "\ скопировать таблицу-источник из 'source-table.csv' с помощью DELIMITER ' , '"(а затем реконструировать геометрию), что, я думаю, похожий подход.

двухбайтовый

COPY быстрее и будет по умолчанию в GDAL 2.0, когда данные записываются в новые таблицы. При использовании вставок размер транзакций по умолчанию (управляемый параметром -gt) составлял только 200 объектов до GDAL версии 1.11, когда он был увеличен до 20000 объектов. Большие транзакции означают меньше транзакций, и это может привести к огромному ускорению.

user30184

Использование COPY является ключевым, и вы, вероятно, получите еще более быстрый перевод с shp2pgsql и флагом -D. shp2pgsql -D test.shp | psql testdb

Пол Рэмси

Пол, shp2pgsql -D такой же, как COPY? Непонятно из документов, в которых говорится, что используется формат «dump», но я не уверен, что это вообще означает для операции загрузки (в отличие от резервного копирования / восстановления). Я заметил, что в shp2pgsql-gui есть опция «Загружать данные с помощью COPY, а не INSERT», но нет опции «dump format», так что я прав, предполагая, что они одинаковые?

Ли Хачадурян,

Да, -D это то же самое, что и использование COPY.

Даррелл Фухриман

После предложения пользователя user30184 , Пола Рэмси и моих собственных экспериментов. Я решил ответить на этот вопрос.

В этом вопросе я не упомянул, что импортирую данные на удаленный сервер. (хотя это описано в блоге, на который я ссылаюсь). Операции, такие как вставки, через Интернет подвержены задержке в сети. Возможно, не имеет значения упоминать, что этот сервер находится на 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 , Пола Рэмси . Мой файл данных представлял собой точечный шейп-файл с 3035369 записями и 82 МБ.

Подход ogr2ogr (с использованием директивы PG_USE_COPY) завершился через 1:03:00 м, что все еще * намного лучше, чем раньше.

Подход shp2pgsql (с использованием директивы -D) завершился всего за 00:01:04 м.

Стоит сказать, что во время операции ogr2ogr создал пространственный индекс, а shp2pgsql - нет. Я обнаружил, что гораздо эффективнее создать индекс после выполнения импорта, чем раздувать операцию импорта с этим типом запроса.

Вывод таков: shp2pgsql, при правильной параметризации, очень хорошо подходит для выполнения больших импортов, а именно тех, которые должны быть размещены в Amazon Web Services.

Пространственная таблица с более чем 3 миллионами записей, импортированных с использованием shp2pgsql

Более подробное описание этих выводов вы можете прочитать в обновлении этого поста.

doublebyte
источник

Прежде чем обвинять GDAL слишком много, взгляните на документацию. Ogr2ogr не задействован, это скорее драйвер GDAL PostGIS, и у него есть возможность отключить пространственный индекс gdal.org/drv_pg.html . Использование с ogr2ogr для добавления -lco SPATIAL_INDEX = NO. В GDAL также есть другой драйвер для PGDump, который лучше подходит для вашего случая использования gdal.org/drv_pgdump.html . Возможно, вы упомянете и эти вещи в своем блоге.

user30184

Разница в скорости 1:03:00 и 00:01:04 между ogr2ogr и shp2pgsql огромна. Я уверен, что это реально, но результат не может быть обобщен. Если вы тестируете локальную базу данных PostGIS, разница будет намного меньше. Ваш результат означает, что что-то идет очень плохо для ogr2ogr. Какую версию GDAL вы использовали? Если он старше, чем v. 1.11, вы пытались увеличить размер транзакции, добавив что-то вроде -gt 60000?

user30184

В индексе при импорте нет дополнительных данных, которые нужно создавать, а потом делать это. Выданная команда точно такая же, а время занимает точно такое же. Также, если вы хотите, чтобы shp2pgsql добавил индекс, вам просто нужно добавить опцию '-I'.

Даррелл Фухриман

Спасибо за ваши комментарии. Моим примером был импорт в Postgres, работающий на AWS, поэтому для меня было важно, чтобы транзакция работала хорошо по сети. Я использовал флаг PG_USE_COPY на ogr2ogr, но я не пробовал драйвер PGDump, который с man-страницы выглядит многообещающе. Моя версия GDAL - 1.7. Я должен сравнить все по равенству условий (с индексом или без него), но из того, что Дэниел говорит мне, это не проблема, поскольку я довольно быстро создаю индекс в базе данных ...

doublebyte

Да, тематические исследования в порядке, если они были написаны так, чтобы у читателей не возникало ощущения, что результаты могут быть обобщены до того, что они действительно представляют. Например, было бы хорошо упомянуть, что вы провели тест с 5-летней версией GDAL и что с этого момента может произойти или не произойти какое-либо развитие. Ваша версия наверняка нуждается в большем значении -gt для хорошей работы, но в любом случае не имеет смысла тестировать с любой более старой версией GDAL, чем 1.10.

user30184