Чому будь-яка функція маршрутизації pgr_ * приймається назавжди на основі даних OSM в БД, що підтримує програмування

Я завантажив німецький набір даних OSM в БР з використанням даних 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_ запиті

Dijkstra від 1,2s до ~ 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 * від 2s до ~ 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 використовувався для імпорту даних (останніх у Фінляндії) до таблиці postgis. до колонки geom_way доданий індекс суті та запуск вакуумного аналізу для бази даних. спільна пам'ять 1G. workmem 512M

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

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

На наступному тижні я отримаю руку щодо нових SSD-дисків (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).