Perché una funzione di routing pgr_ * impiega un'eternità in base ai dati OSM in un database abilitato pgrouting

Ho caricato il set di dati OSM tedesco nel DB pgrouting usando osm2po 4.7.7. Tutto funziona bene ho osm2po impostato tramite la sua configurazione e funziona come un fascino attraverso la sua parte Java.

Ho importato la tabella * _2po_4pgr senza problemi. Anche la tabella * 2po_v viene importata, anche se non capisco completamente la relazione di questa tabella.

Ho eseguito la funzione pgr_createTopology che ha funzionato per un bel po '(12000sec) durante il calcolo di tutti i bordi di 6m. Pensavo che questo avrebbe funzionato, ma è ancora insopportabilmente lento.

Vorrei sapere se ho dimenticato qualcosa. Stavo pensando di usare pgRouting al posto della libreria java, ma al momento le sue prestazioni sono appena fuori dal confronto.

Il problema con le prestazioni di pgRouting sembra essere che i nuovi pgr_astar e pgr_dijkstra utilizzano l'intero grafico (che garantisce la soluzione se ce n'è uno). Una soluzione semplice per ottenere prestazioni migliori è limitare il grafico utilizzato ad un'area più piccola. Ha i suoi problemi come a volte può creare grafici che non possono essere risolti

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

Crea BBOX sulla raccolta di origine e destinazione e la espande di 0,1 gradi, quindi viene utilizzata la stessa query per limitare la dimensione del grafico nella query pgr_

Dijkstra da 1,2 a ~ 65 ms

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 * da 2s a ~ 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 è stato usato per importare i dati (finland-latest) nella tabella postgis. indice gist aggiunto alla colonna geom_way e analisi del vuoto completo eseguita per il database. memoria condivisa 1G. workmem 512M

Alla fine sono giunto alla conclusione che è meglio mettere l'intero grafico (compresi gli indici) su un tablespace separato che risiede permanentemente in memoria usando un ramdisk.

Per impostare il ramdisk su Ubuntu 13.04 ho usato le seguenti istruzioni e devo dire che funziona abbastanza bene (include le istruzioni per ricaricare i dati in memoria dopo un riavvio / riavvio).

La prossima settimana avrò una mano sui nuovi SSD (1 GB / s di lettura) e proverò a confrontare le prestazioni.

A mio avviso, è l'unica soluzione per mantenere un grafico a 1 M + righe in modo permanente accessibile, poiché si verificano letture casuali continue.

Utilizzare questa guida per impostare gli indici per un database spaziale. Ecco l'essenza:

 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

per le mie tabelle _4pgr e _vertex, solo le colonne di origine e destinazione avevano indici dopo l'importazione (osm2po-core-5.1.0).