Почему любая функция маршрутизации pgr_ * работает вечно на основе данных OSM в базе данных с поддержкой pgrouting

Я загрузил немецкий набор данных OSM в базу данных pgrouting с помощью osm2po 4.7.7. Все работает нормально, я настроил osm2po через его конфигурацию, и он работает как шарм в своей части Java.

У меня таблица * _2po_4pgr была импортирована без проблем. Даже таблица * 2po_v импортируется, хотя я не совсем понимаю отношение этой таблицы.

Я выполнил функцию pgr_createTopology, которая работала довольно долго (12000 сек), вычисляя все 6-метровые ребра. Я думал, что это сделает сделку, но все же это невыносимо медленно.

Я хотел бы знать, если я что-то забыл. Я думал о том, чтобы использовать pgRouting вместо библиотеки java, но на данный момент его производительность просто вне сравнения.

Проблема с производительностью pgRouting заключается в том, что новые pgr_astar и pgr_dijkstra используют целый граф (который гарантирует решение, если таковой имеется). Простое решение для повышения производительности - ограничить используемый граф меньшей областью. У него есть свои проблемы, как иногда он может создавать графики, которые не могут быть решены

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

Создает BBOX для исходной и целевой коллекции и расширяет ее на 0,1 градуса, затем тот же запрос используется для ограничения размера графика в запросе pgr_

Дейкстра от 1.2 с до ~ 65 мс

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 * от 2 с до ~ 50 мс

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 использовался для импорта данных (finland-latest) в таблицу postgis. добавлен индекс gist в столбец geom_way и проведен полный анализ вакуума для базы данных. разделяемая память 1G. Workmem 512M

Я наконец пришел к выводу, что лучше всего поместить весь график (включая индексы) в отдельное табличное пространство, которое постоянно находится в памяти с помощью виртуального диска.

Для настройки виртуального диска в Ubuntu 13.04 я использовал следующие инструкции и должен сказать, что он работает довольно хорошо (в него входят инструкции по перезагрузке данных в память после перезагрузки / перезагрузки).

На следующей неделе я познакомлюсь с новыми твердотельными накопителями (1 Гбайт / с) и попытаюсь сравнить производительность.

Насколько я вижу, это единственное решение для постоянного доступа к графу 1M + строк, так как происходит непрерывное случайное чтение.

Используйте это руководство для настройки индексов для пространственной базы данных. Вот суть этого:

 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

для моих таблиц _4pgr и _vertex только столбцы источника и назначения имели индексы после импорта (osm2po-core-5.1.0).