Mengapa fungsi routing pgr_ * mengambil selamanya berdasarkan data OSM dalam DB diaktifkan pgrouting

Saya memuat dataset OSM Jerman ke dalam DB pgrouting dengan menggunakan osm2po 4.7.7. Semuanya berfungsi dengan baik saya sudah mengatur osm2po melalui konfigurasi itu dan itu berfungsi seperti pesona melalui bagian Jawa itu.

Saya memiliki tabel * _2po_4pgr yang diimpor tanpa masalah. Bahkan tabel * 2po_v diimpor, meskipun saya tidak sepenuhnya memahami hubungan tabel ini.

Saya menjalankan fungsi pgr_createTopology yang berjalan cukup lama (12000secs) sambil menghitung semua tepi 6m. Saya pikir ini akan melakukan kesepakatan, tetapi masih lambat tak tertahankan.

Saya ingin tahu apakah saya lupa sesuatu. Saya sedang berpikir untuk menggunakan pgRouting bukan perpustakaan java tetapi saat ini kinerjanya hanya di luar perbandingan.

Masalah dengan kinerja pgRouting tampaknya adalah bahwa pgr_astar dan pgr_dijkstra baru menggunakan seluruh grafik (yang menjamin solusi jika ada satu). Solusi sederhana untuk mendapatkan kinerja yang lebih baik adalah membatasi grafik yang digunakan untuk area yang lebih kecil. Ini memiliki masalah sendiri seperti kadang-kadang dapat membuat grafik yang tidak dapat diselesaikan

 (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) 

Membuat BBOX dari koleksi sumber dan target dan memperluasnya 0,1 derajat, lalu kueri yang sama digunakan untuk membatasi ukuran grafik dalam kueri pgr_

Dijkstra mulai 1.2s hingga ~ 65ms

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 * dari 2s hingga ~ 50ms

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 digunakan untuk mengimpor data (finland-latest) ke dalam tabel postgis. indeks inti ditambahkan ke kolom geom_way dan menjalankan analisis vakum penuh untuk database. memori bersama 1G. 512M workmem

Saya akhirnya sampai pada kesimpulan bahwa yang terbaik adalah menempatkan seluruh grafik (termasuk indeks) pada tablespace terpisah yang secara permanen berada di memori menggunakan ramdisk.

Untuk mengatur ramdisk di Ubuntu 13.04 saya menggunakan instruksi berikut dan harus mengatakan itu berfungsi dengan baik (ini termasuk instruksi untuk memuat ulang data ke dalam memori setelah restart / reboot).

Minggu depan saya akan mempelajari SSD baru (baca 1GB / dtk) dan mencoba membandingkan kinerjanya.

Sejauh yang saya lihat itu satu-satunya solusi untuk menjaga grafik 1M + baris dapat diakses secara permanen, karena ada pembacaan acak terus menerus yang terjadi.

Gunakan panduan ini untuk mengatur indeks untuk basis data spasial. Inilah intinya:

 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

untuk tabel _4pgr dan _vertex saya, hanya kolom sumber dan target yang memiliki indeks setelah impor (osm2po-core-5.1.0).