¿Por qué alguna función de enrutamiento pgr_ * tarda para siempre según los datos de OSM en un DB habilitado para pgrouting

Cargué el conjunto de datos OSM alemán en la base de datos pgrouting utilizando osm2po 4.7.7. Todo funciona bien, tengo osm2po configurado a través de su configuración y funciona de maravilla a través de su parte de Java.

Tenía la tabla * _2po_4pgr importada sin ningún problema. Incluso la tabla * 2po_v se importa, aunque no entiendo completamente la relación de esta tabla.

Ejecuté la función pgr_createTopology que se ejecutó durante bastante tiempo (12000 segundos) mientras calculaba los 6m de bordes. Pensé que esto haría el trato, pero aún así es insoportablemente lento.

Me gustaría saber si olvidé algo. Estaba pensando en usar pgRouting en lugar de la biblioteca de Java, pero en este momento su rendimiento solo es incomparable.

El problema con el rendimiento de pgRouting parece ser que los nuevos pgr_astar y pgr_dijkstra usan un gráfico completo (que garantiza la solución si hay uno). Una solución simple para obtener un mejor rendimiento es limitar el gráfico usado a un área más pequeña. Tiene sus propios problemas, ya que a veces puede crear gráficos que no se pueden resolver.

 (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 sobre la colección de origen y destino y lo expande 0.1 grados, luego se usa la misma consulta para limitar el tamaño del gráfico en pgr_ query

Dijkstra de 1.2s a ~ 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 * de 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 se utilizó para importar datos (finlandia-último) en la tabla postgis. índice Gist agregado a la columna geom_way y análisis de vacío completo para la base de datos. memoria compartida 1G. workmem 512M

Finalmente llegué a la conclusión de que es mejor colocar todo el gráfico (incluidos los índices) en un espacio de tabla separado que reside permanentemente en la memoria utilizando un disco RAM.

Para configurar el ramdisk en Ubuntu 13.04, utilicé las siguientes instrucciones y debo decir que funciona bastante bien (incluye instrucciones para volver a cargar los datos en la memoria después de reiniciar / reiniciar).

La próxima semana echaré un vistazo a los nuevos SSD (1 GB / s de lectura) e intentaré comparar el rendimiento.

Por lo que veo, es la única solución para mantener un gráfico de filas de 1M + permanentemente accesible, ya que ocurren lecturas aleatorias continuas.

Use esta guía para configurar índices para una base de datos espacial. Aquí está la esencia de esto:

 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

para mis tablas _4pgr y _vertex, solo las columnas de origen y destino tenían índices después de la importación (osm2po-core-5.1.0).