Herhangi bir pgr_ * yönlendirme işlevi, pgrouting özellikli bir DB'de OSM verilerine dayanarak neden sonsuza kadar sürüyor?

Alman OSM veri kümesini osm2po 4.7.7 kullanarak pgrouting DB'ye yükledim. Her şey yolunda çalışıyor, ben onun config aracılığıyla kurulmuş osm2po var ve bu Java kısmı aracılığıyla bir cazibe gibi çalışıyor.

* _2po_4pgr tablosunu sorunsuz bir şekilde içe aktardım. * 2po_v tablosu bile içe aktarılır, ancak bu tablonun ilişkisini tam olarak anlamıyorum.

Tüm 6m kenarlarını hesaplarken uzunca bir süre (12000 saniye) çalışan pgr_createTopology işlevini yürüttüm. Bunun anlaşmayı yapacağını düşündüm, ama yine de dayanılmaz derecede yavaş.

Bir şey unuttuğumu bilmek istiyorum. Java kütüphanesi yerine pgRouting kullanmayı düşünüyordum ama şu anda performans açısından karşılaştırmalı olarak değil.

PgRouting performansıyla ilgili sorun, yeni pgr_astar ve pgr_dijkstra'nın tüm grafiği kullanmasıdır (eğer varsa çözümü garanti eder). Daha iyi performans elde etmek için kullanılan basit çözüm, kullanılan grafiği daha küçük alanlarla sınırlamaktır. Bazen çözülemeyen grafikler yaratabileceği gibi kendi sorunları var

 (SELECT ST_Expand(ST_Extent(geom_way),0.1) as box  FROM hh_2po_4pgr as l1 WHERE l1.source =7 OR l1.target = 12) 

Kaynak ve hedef toplama üzerinde BBOX oluşturur ve 0.1 derece genişletir, ardından pgr_ sorgusundaki grafik boyutunu sınırlamak için aynı sorgu kullanılır

Dijkstra 1.2s ~ ~ 65ms arası

SELECT  seq, id1 AS node, id2 AS edge, g.geom_way as the_geom
    FROM pgr_dijkstra(
            'SELECT id, source, target, cost FROM hh_2po_4pgr as r, 
            (SELECT ST_Expand(ST_Extent(geom_way),0.1) as box  FROM hh_2po_4pgr as l1    WHERE l1.source =7 OR l1.target = 12) as box
            WHERE r.geom_way && box.box',
            7, 12, false, false
    ) as r INNER JOIN hh_2po_4pgr as g ON r.id2 = g.id ;

A * 2s - ~ 50ms arası

SELECT seq, id1 AS node, id2 AS edge, cost
    FROM pgr_astar(
           'SELECT id, source, target, cost, x1,y1,x2,y2 FROM hh_2po_4pgr as r, 
             (SELECT ST_Expand(ST_Extent(geom_way),0.1) as box  FROM hh_2po_4pgr as l1    WHERE l1.source =7 OR l1.target = 12) as box
            WHERE r.geom_way && box.box',
            7, 12, false, false
    );

osm2po postgis tablosuna veri (finland-latest) aktarmak için kullanıldı. geom_way sütununa gist endeksi eklendi ve veritabanı için tam vakum analizi çalıştırıldı. paylaşılan hafıza 1G. workmem 512M

Sonunda, tüm grafiği (indeksler dahil) bir ramdisk kullanarak kalıcı olarak bellekte bulunan ayrı bir tablo alanına yerleştirmenin en iyisi olduğu sonucuna vardım.

Ubuntu 13.04 üzerinde ramdisk'i kurmak için aşağıdaki talimatları kullandım ve oldukça iyi çalıştığını söylemeliyim (bir yeniden başlatma / yeniden başlatmadan sonra verileri belleğe yeniden yüklemek için talimatlar içerir).

Gelecek hafta yeni SSD'leri ele alacağım (1GB / sn okuma) ve performansı karşılaştırmaya çalışacağım.

Gördüğüm kadarıyla 1M + satır grafiğini kalıcı olarak erişilebilir tutmak için tek çözüm, çünkü sürekli rastgele okumalar oluyor.

Uzamsal bir veritabanı için dizin ayarlamak için bu kılavuzu kullanın . İşte özü:

 1. create indexes on ID, source and target columns.
 2. create index using GIST on geom column.
 3. vacuum
 4. cluster on geom column
 5. analyze

_4pgr ve _vertex tablolarım için içe aktarmadan sonra yalnızca kaynak ve hedef sütunlarda dizinler vardı (osm2po-core-5.1.0).