Pourquoi une fonction de routage pgr_ * prend-elle une éternité en fonction des données OSM dans une base de données activée pour le pgrouting

J'ai chargé l'ensemble de données OSM allemand dans la base de données de pgrouting en utilisant osm2po 4.7.7. Tout fonctionne bien j'ai osm2po mis en place via sa configuration et ça fonctionne comme un charme à travers sa partie Java.

J'ai eu la table * _2po_4pgr importée sans aucun problème. Même la table * 2po_v est importée, bien que je ne comprenne pas complètement la relation de cette table.

J'ai exécuté la fonction pgr_createTopology qui a fonctionné pendant un certain temps (12000 secondes) tout en calculant tous les bords de 6 m. Je pensais que cela ferait l'affaire, mais c'est quand même insupportablement lent.

Je voudrais savoir si j'ai oublié quelque chose. Je pensais à utiliser pgRouting au lieu de la bibliothèque java mais pour le moment, ses performances sont tout simplement hors de comparaison.

Le problème avec les performances de pgRouting semble être que les nouveaux pgr_astar et pgr_dijkstra utilisent un graphe entier (ce qui garantit la solution s'il y en a un). Une solution simple pour obtenir de meilleures performances est de limiter le graphique utilisé à une zone plus petite. Il a ses propres problèmes comme parfois il peut créer des graphiques qui ne peuvent pas être résolus

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

Crée BBOX sur la collection source et cible et l'étend de 0,1 degré, puis la même requête est utilisée pour limiter la taille du graphique dans la requête pgr_

Dijkstra de 1,2 s à ~ 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 * de 2s à ~ 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 a été utilisé pour importer des données (finland-latest) dans le tableau postgis. index gist ajouté à la colonne geom_way et analyse complète du vide pour la base de données. mémoire partagée 1G. workmem 512M

Je suis finalement arrivé à la conclusion qu'il est préférable de placer le graphique entier (y compris les indices) sur un espace de table séparé qui réside en permanence en mémoire à l'aide d'un disque virtuel.

Pour configurer le ramdisk sur Ubuntu 13.04, j'ai utilisé les instructions suivantes et je dois dire que cela fonctionne assez bien (il comprend des instructions pour recharger les données en mémoire après un redémarrage / redémarrage).

La semaine prochaine, je vais mettre la main sur de nouveaux SSD (1 Go / s en lecture) et essayer de comparer les performances.

Pour autant que je vois, c'est la seule solution pour garder un graphique de 1M + lignes accessible en permanence, car il se produit une lecture aléatoire continue.

Utilisez ce guide pour configurer des index pour une base de données spatiale. En voici l'essentiel:

 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

pour mes tables _4pgr et _vertex, seules les colonnes source et cible avaient des index après l'importation (osm2po-core-5.1.0).