Який найкращий хак для імпорту великих наборів даних у PostGIS?

Мені потрібно імпортувати великі Shapefiles (> 1 мільйон записів) у PostGIS, і мені було цікаво, як найкраще це зробити.

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

У своєму питанні я спеціально використовував слово "хак", а не інструмент, тому що я думаю, це не стільки питання того, який інструмент, а який набір кроків чи налаштування конфігурації. Поки я спробував плагін SPIT (QGIS), інструмент Postgis для shp2pgsql та інструмент GDAL ogr2ogr . Ви можете переглянути мій повний відгук у цій публікації. Поки що я вважаю, що всі вони дійсно не реагують на роботу з великим набором даних. Мені було цікаво, чи відчував хтось подібне питання, і чи можете ви поділитися чимось щодо підходу.

postgis database big-data

— двобайтний
джерело

Відповіді:

Я зробив для вас тест:

PostgreSQL 9.3
PostGIS 2.1
Windows 7
Процесор i7 3770@3,4 ГГц
64-розрядний GDAL 2.0-dev
Формат файлу 1,14 млн. полігонів, розмір файлу 748 Мб

Команда Ogr2ogr:

ogr2ogr -f PostgreSQL PG: "dbname = 'ім'я бази даних" host =' addr 'port =' 5432 'user =' x 'password =' y '"test.shp --config PG_USE_COPY ТАК -не MULTIPOLYGON

Загальний час: 1 хвилина 30 сек

— user30184
джерело

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

— двобайт

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

— користувач30184

Використання COPY є ключовим, і ви, ймовірно, отримаєте ще швидший переклад з shp2pgsql та прапором -D. shp2pgsql -D test.shp | psql testdb

— Пол Рамзі

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

— Лі Хачадоріан

Так, -D те саме, що використовувати COPY.

— Даррелл Фуріман

Після пропозицій користувача 30184 , Пол Рамзі та мої власні експерименти. Я вирішив відповісти на це питання.

У цьому питанні я не зазначив, що я імпортую дані на віддалений сервер. (хоча це описано в публікації блогу, на яку я посилаюсь). Такі операції, як вставки через Інтернет, залежать від затримки в мережі. Можливо, неважливо згадати, що цей сервер працює на 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, у мене тоді була робота над заповненням геометрії, додаванням просторового індексу і т. Д. Це все ще було надзвичайно швидко, оскільки я виконував запити на сервері .

Я вирішив порівняти також пропозиції користувача 30184 , Пол Рамзі . Мій файл даних був точковим файлом форми з 3035369 записами та 82 Мб.

Підхід ogr2ogr (з використанням директиви PG_USE_COPY) закінчився за 1:03:00 м, що все ще * набагато краще, ніж раніше.

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

Варто сказати, що ogr2ogr створив просторовий індекс під час операції, тоді як shp2pgsql цього не зробив. Я знаходжу, що набагато ефективніше створювати індекс після імпорту, а не здувати операцію імпорту таким запитом.

Висновок такий: shp2pgsql, при правильній параметризації, надзвичайно добре підходить для великого імпорту, а саме для розміщення в веб-сервісах Amazon.

Просторова таблиця з більш ніж 3 мільйонами записів, імпортованих за допомогою shp2pgsql

Більш детальний опис цих висновків ви можете прочитати в оновлення цього допису.

— двобайтний
джерело

Перш ніж занадто багато звинуватити GDAL, ознайомтеся з документацією. Ogr2ogr не бере участь, він швидше є драйвером PostGIS GDAL, і у нього є можливість відключення просторового індексу gdal.org/drv_pg.html . Використання з ogr2ogr полягає в тому, щоб додати -lco SPATIAL_INDEX = НІ. 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, який із сторінки сторінки виглядає багатообіцяючим. Моя версія GDAL становить 1,7. Я повинен орієнтувати все на рівності умов (з індексом чи без), але з того, що Даніель мені каже, це не проблема, оскільки я створюю індекс досить швидко в базі даних ...

— doublebyte

Так, тематичні дослідження добре, якщо вони написані, щоб читачі не відчували, що результати можуть бути узагальнені над тим, що вони насправді представляють. Наприклад, було б добре згадати, що ви зробили тест із 5-річною версією GDAL і що з цього моменту може статися чи не відбуватися розробка. Ваша версія напевно потребує більших значень -gt для успішної роботи, але все одно не має сенсу тестувати будь-яку старішу версію GDAL, ніж 1.10.

— user30184