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

9

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

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

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

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

Джонни Кьюсак
источник
1
Вы создали индексы, настроили ли вы переменные памяти postgis? createTopology запускается только один раз для всего набора данных, поэтому его производительность не имеет большого значения. Примечание. У меня была вся Финляндия из набора данных digiroad (например, 2G дорожной сети), и результаты возвращались максимум через 250 мс, обычно 125 мс без каких-либо оптимизаций. Так что должно быть лучше сейчас дни
симплексио
В исходном и целевом столбцах есть индексы, автоматически создаваемые генератором сценариев osm2po. Больше нужно? Я изменил переменные work_mem / maintenance_work_mem на значение GigaByte , перезапустил, все еще без изменений. Есть какой-нибудь шаблон сценария запуска, который мне может понадобиться?
Джонни Кьюсак
1
Хммм ... Что делает createTopology ()? Я имею в виду, osm2po уже создает топологию на основе идентификаторов узлов OSM. Таким образом, нет необходимости запускать что-либо. опять похоже. Для pgRouting (shorttest_path & shortest_path_astar) вам понадобится только созданная таблица 4pgr. Это все.
Карстен
Теперь у меня есть набор данных Финляндии, postgis 2.0.3, pgrouting 2.0.0-dev. И я должен сказать, что это медленно. всегда в течение 1 секунды для результата при использовании pgr_astar (). Я проверяю, получаю ли я это немного быстрее
симплексио

Ответы:

5

Проблема с производительностью 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

simplexio
источник
У меня была та же идея с ограничительной рамкой, которая продолжалась более 90 секунд, даже с установленными переменными памяти и т. Д.
Джонни Кьюсак
у меня есть 380k линий? у вас наверное что-то вроде 3M + строк в таблице маршрутизации?
симплексио
1
Это одна из основных проблем в Postgres - не кэшировать весь график. Это работает довольно быстро. Но мне нужно связать его с другими таблицами базы данных, что создает в текущей (тестовой) ситуации огромное узкое место всего с 5qps (запросов в секунду)
Джонни Кьюсак
1
Я просто загрузил подмножество 1M строк в виртуальный диск для сравнения. pgr_dijkstra занимает 3 секунды в холодном режиме. pgr_astra с примером bbox, предоставленным @simplexio, для холодного запуска требуется около 900 мс. Так что, кажется, я должен поместить все в ramdisk для правильной работы.
Джонни Кьюсак
1
Большой! с индексами @ kttii я бегу быстро сейчас!
Магно C
5

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

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

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

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

Джонни Кьюсак
источник
Как вы создали весь график (включая индексы)? Я ничего не видел в документации по pgrouting.
Деннис Баусус
Я использовал osm2po, удивительный кусок кода Java! osm2po.de
Джонни Кьюсак
5

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

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

kttii
источник
Фантастический! от ~ 45 сек до ~ 15 сек с использованием полного OSM Южная Америка с самостоятельным присоединением.
Magno C
Извините моя ошибка. от ~ 45 сек до ~ 5 мс !!!!!!
Магно C