¿Por qué cualquier función de enrutamiento pgr_* tarda una eternidad basada en los datos de OSM en una DB habilitada para pgrouting?

Question

He cargado el conjunto de datos OSM alemán en la base de datos de pgrouting utilizando osm2po 4.7.7. Todo funciona bien tengo osm2po configurado a través de su configuración y está trabajando como un encanto a través de su parte de Java.

He importado la tabla *_2po_4pgr sin problemas. Incluso la tabla *2po_v se importa, aunque no entiendo del todo la relación de esta tabla.

Ejecuté la función pgr_createTopology que se ejecutó durante bastante tiempo (12000secs) mientras calculaba las 6m aristas. Pensé que esto haría el trato, pero todavía es insoportablemente lento.

Me gustaría saber si he olvidado algo. Estaba pensando en usar pgRouting en lugar de la librería java pero por el momento su rendimiento está fuera de comparación.

Answer 1

El problema del rendimiento de pgRouting parece ser que los nuevos pgr_astar y pgr_dijkstra utilizan todo el grafo (lo que garantiza la solución si la hay). Una solución simple para obtener un mejor rendimiento es limitar el gráfico utilizado a un área más pequeña. Tiene sus propios problemas, como que a veces puede crear gráficos que no pueden ser resueltos.

 (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 la expande 0,1 grados, luego se utiliza la misma consulta para limitar el tamaño del gráfico en la consulta pgr_

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 los datos (finland-latest) a la tabla postgis. índice gist añadido a la columna geom_way y análisis de vacío completo ejecutado para la base de datos. memoria compartida 1G . workmem 512M

Answer 2

Utilice esta guía para configurar los índices de una base de datos espacial. Esto es lo esencial:

 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, sólo las columnas de origen y destino tenían índices después de la importación (osm2po-core-5.1.0).

Answer 3

Finalmente llegué a la conclusión de que lo mejor es poner todo el gráfico (incluyendo los índices) en un tablespace separado que resida permanentemente en memoria usando un ramdisk.

Para configurar el ramdisk en Ubuntu 13.04 he utilizado lo siguiente instrucciones y debo decir que funciona bastante bien (incluye instrucciones para recargar los datos en la memoria después de un reinicio/reinicio).

La semana que viene le echaré mano a los nuevos SSD (1GB/s de lectura) e intentaré comparar el rendimiento.

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