Büyük veri setlerini PostGIS'e aktarmak için en iyi saldırı nedir?

PostGIS'e büyük Shapefiles (> 1 milyon kayıt) almam gerekiyor ve bunu yapmanın en iyi yolunu merak ediyorum.

resim açıklamasını buraya girin

Benim sorum, aracı yerine "hack" kelimesini kullandım, çünkü bunun hangi aracın o kadar önemli olmadığını, hangi adımların veya yapılandırma ayarlarının kullanılacağını düşünüyorum. Şimdiye kadar, SPIT eklentisini (QGIS), shp2pgsql Postgis aracını ve GDAL ogr2ogr aracını denedim . İncelememin tamamını bu yayında görebilirsiniz. Şimdiye kadar, büyük bir veri kümesiyle uğraşırken hepsini gerçekten tepkisiz buluyorum. Birisinin benzer bir sorun yaşayıp yaşamadığını ve yaklaşım hakkında bir şeyler paylaşıp paylaşamayacağınızı merak ediyordum.

postgis database big-data

— doublebyte
kaynak

Yanıtlar:

Sizin için bir test yaptım:

PostgreSQL 9.3
PostGIS 2.1
Windows 7
i7 3770@3.4 GHz işlemci
GDAL 2.0-dev 64 bit
1,14 milyon çokgen biçim dosyası, dosya boyutu 748 MB

Ogr2ogr komutu:

ogr2ogr -f PostgreSQL PG: "dbname = 'veritabanı_adı' host = 'addr' port = '5432' kullanıcı = 'x' şifre = 'y'" test.shp --config PG_USE_COPY EVET -nlt MULTIPOLYGON

Toplam süre: 1 dakika 30 saniye

— user30184
kaynak

Cevabınız için teşekkürler! Gerçekten hızlı görünüyor; --Config PG_USE_COPY YES bayrağını kullanmadığım için benim için işe yaramayabileceğini düşünüyorum; Ben sadece kullanarak hızlı bir şekilde içe aktarmayı başardı: psql target-db -U <admin kullanıcı> -p <port> -h <DB örnek adı> -c "\ kaynak-tablosunu 'source-table.csv' den DELIMITER ile kopyala , "" (ve sonra geometrinin yeniden yapılandırılması), ki bu da benzer bir yaklaşım.

— doublebyte

COPY daha hızlıdır ve veriler yeni tablolara yazıldığında GDAL 2.0'da varsayılan değer olacaktır. Ekler kullanıldığında, varsayılan işlem boyutu (-gt parametresi ile kontrol edilir) GDAL sürüm 1.11'den önce 20000 özelliğe yükseltildiğinde yalnızca 200 özellikti. Daha büyük işlemler daha az işlem anlamına gelir ve bu da büyük bir hızlanma sağlayabilir.

— user30184

COPY kullanmak anahtardır ve muhtemelen shp2pgsql ve -D bayrağıyla daha da hızlı bir çeviri elde edersiniz. shp2pgsql -D test.shp | psql testdb

— Paul Ramsey

Paul, shp2pgsql -D, COPY ile aynı mı? Bunun "döküm" biçimini kullandığını söyleyen dokümanlar net değil, ancak bir yükleme (yedekleme / geri yükleme yerine) işlemi için bile ne anlama geldiğinden emin değilim. Ben shp2pgsql-gui "INSERT yerine COPY kullanarak veri yükle", ancak "döküm biçimi" seçeneği yok bir seçenek olduğunu fark, bu yüzden bunların aynı olduğunu varsayarak doğru muyum?

— Lee Hachadoorian

Evet, -D COPY kullanmakla aynıdır.

— Darrell Fuhriman

Önerileri sonra user30184 , Paul Ramsey ve kendi deneyleri. Bu soruya cevap vermeye karar verdim.

Bu soruda, uzak bir sunucuya veri aktardığımı söyleyemedim. (bahsettiğim blog yayınında açıklanmış olmasına rağmen). İnternet üzerinden kesici uçlar gibi işlemler ağ gecikmesine tabidir. Belki de bu sunucunun Amazon RDS'de olduğunu ve makineye ssh almamı ve yerel olarak işlemleri çalıştırmamı önlemek önemli değildir.

Bunu göz önünde bulundurarak, yeni bir tabloya veri dökümü teşvik etmek için "\ copy" yönergesini kullanarak yaklaşımımı yeniden tasarladım. Bu stratejinin, bu sorunun yorumlarına / cevaplarına da atıfta bulunan önemli bir anahtar olduğunu düşünüyorum.

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

Bu operasyon inanılmaz derecede hızlıydı. Ben bir csv ithal beri, daha sonra geometri doldurma, uzamsal bir dizin, vb ekleyerek tüm çalışmaları vardı. O zaman hala oldukça hızlı, çünkü daha sonra sunucuda sorgular çalıştırıyordu .

Ben de kıyaslama gelen önerilerle karar user30184 , Paul Ramsey . Veri dosyam 3035369 kayıt ve 82 MB olan bir nokta şekil dosyasıydı.

Ogr2ogr yaklaşımı (PG_USE_COPY yönergesini kullanarak) 1:03:00 m'de sona erdi, ki bu hala * eskisinden çok daha iyi.

Shp2pgsql yaklaşımı (-D yönergesini kullanarak) yalnızca 00:01:04 m'de tamamlandı.

Shp2pgsql işlem yapmadığı halde ogr2ogr'un işlem sırasında uzamsal bir dizin oluşturduğunu söylemeye değer. Ben dizin oluşturmak için çok daha verimli olduğunu öğrenmek sonra ithalat yapıyor ziyade şişkinlik istek bu tür ithalat işlemini.

Sonuç şudur: shp2pgsql, düzgün bir şekilde parametrelendirildiğinde, büyük miktarda ithalat, yani Amazon Web Servisleri'nde barındırılacaklar için son derece uygundur .

3 milyondan fazla kaydı olan mekansal tablo, shp2pgsql kullanılarak içe aktarıldı

Bu yayının güncellenmesiyle, bu sonuçların daha ayrıntılı bir açıklamasını okuyabilirsiniz .

— doublebyte
kaynak

GDAL'ı çok fazla suçlamadan önce, belgelere bir göz atın. Ogr2ogr dahil değildir, daha ziyade GDAL PostGIS sürücüsüdür ve gdal.org/drv_pg.html uzamsal dizinini devre dışı bırakma seçeneği vardır . Ogr2ogr ile kullanım -lco SPATIAL_INDEX = NO eklemektir. GDAL da kullanım durumu daha iyi uygun olabilecek PGDump için başka bir sürücü vardır gdal.org/drv_pgdump.html . Belki blogunuzda bunlardan da bahsedeceksiniz.

— user30184

Ogr2ogr ve shp2pgsql arasındaki hız farkı 1:03:00 ve 00:01:04 çok büyük. Bunun gerçek olduğuna eminim ama sonuç genelleştirilemez. Yerel bir PostGIS veritabanı ile test yaparsanız, fark çok daha az olacaktır. Sonuç, ogr2ogr için bir şeyin çok kötü gittiği anlamına gelir. Hangi GDAL sürümünü kullandınız? 1.11'den eskiyse, -gt 60000 gibi bir şey ekleyerek işlemlerin boyutunu artırarak denediniz mi?

— user30184

İçe aktarma işleminde dizinde oluşturmak, daha sonra yapmaktan başka bir şişkinlik değildir. Verilen komut tamamen aynı ve tam olarak aynı zaman alıyor. Ayrıca, shp2pgsql dosyasının dizini eklemesini istiyorsanız, sadece '-I' seçeneğini eklemeniz gerekir.

— Darrell Fuhriman

Yorumlarınız için teşekkürler. Vaka çalışmam AWS'de çalışan bir Postgres'e aktarımdı, bu yüzden işlemin ağ üzerinden iyi bir şekilde yapılması benim için önemliydi. Ogr2ogr üzerinde PG_USE_COPY bayrağını kullandım, ama manpage umut verici görünüyor PGDump sürücüsünü denemedim. GDAL versiyonum 1.7. Her şeyi koşulların eşitliğinde (indeks ile veya dizin olmadan) karşılaştırmalıyım, ancak Daniel'in bana söylediği şey bu problem değil, çünkü veritabanında oldukça hızlı bir şekilde indeks oluşturuyorum ...

— doublebyte

Evet, eğer vakalar okurlarsa, okuyucular sonuçların gerçekte temsil ettikleri şey hakkında genelleştirilebileceği hissine kapılmamaları için sorun yaşamazlar. Örneğin, testi 5 yıllık GDAL sürümü ile yaptığınızı ve bundan sonra bazı gelişmelerin gerçekleşip gerçekleşmeyeceğini belirtmek iyi olur. Elbette sürümünüz iyi performans için daha büyük bir -gt değerine ihtiyaç duyar, ancak yine de 1.10'dan daha eski bir GDAL sürümü ile test etmek pek mantıklı değildir.

— user30184