Por que uma função de roteamento pgr_ * demora para sempre com base nos dados do OSM em um banco de dados habilitado para pgrouting

Carreguei o conjunto de dados OSM alemão no banco de dados pgrouting usando osm2po 4.7.7. Tudo funciona bem. Eu tenho o osm2po configurado via sua configuração e está funcionando como um encanto pela parte Java.

Eu tive a tabela * _2po_4pgr importada sem problemas. Até a tabela * 2po_v é importada, embora eu não entenda completamente a relação dessa tabela.

Eu executei a função pgr_createTopology, que funcionou por um bom tempo (12000 segundos) enquanto calculava todas as bordas de 6m. Eu pensei que isso faria o acordo, mas ainda é insuportavelmente lento.

Gostaria de saber se esqueci alguma coisa. Eu estava pensando em usar o pgRouting em vez da biblioteca java, mas no momento seu desempenho é apenas uma comparação.

Problema com o desempenho do pgRouting parece que o novo pgr_astar e pgr_dijkstra usam o gráfico inteiro (o que garante a solução, se houver). A solução simples para obter melhor desempenho é limitar o gráfico usado a uma área menor. Tem problemas próprios, como às vezes pode criar gráficos que não podem ser resolvidos

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

Cria BBOX sobre a coleção de origem e destino e a expande em 0,1 graus; a mesma consulta é usada para limitar o tamanho do gráfico na 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
    );

o osm2po foi usado para importar dados (último da finlândia) para a tabela postgis. índice de essência adicionado à coluna geom_way e análise de vácuo total executada no banco de dados. memória compartilhada 1G. workmem 512M

Finalmente cheguei à conclusão de que é melhor colocar o gráfico inteiro (incluindo índices) em um espaço de tabela separado, que reside permanentemente na memória usando um ramdisk.

Para configurar o ramdisk no Ubuntu 13.04, usei as seguintes instruções e devo dizer que está funcionando muito bem (inclui instruções para recarregar os dados na memória após uma reinicialização / reinicialização).

Na próxima semana, vou conhecer os novos SSDs (leitura de 1 GB / s) e tentar comparar o desempenho.

Até onde eu vejo, é a única solução para manter um gráfico de linhas de mais de 1 milhão permanentemente acessível, pois há uma leitura aleatória contínua acontecendo.

Use este guia para configurar índices para um banco de dados espacial. Aqui está a essência disso:

 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 minhas tabelas _4pgr e _vertex, apenas as colunas de origem e de destino tinham índices após a importação (osm2po-core-5.1.0).