Dlaczego jakakolwiek funkcja routingu pgr_ * trwa wiecznie na podstawie danych OSM w DB obsługującej pgrouting

Załadowałem niemiecki zestaw danych OSM do DB pgrouting przy użyciu osm2po 4.7.7. Wszystko działa dobrze, mam skonfigurowane osm2po poprzez jego konfigurację i działa jak urok dzięki części Java.

Miałem tabelę * _2po_4pgr zaimportowaną bez żadnych problemów. Nawet tabela * 2po_v jest importowana, choć nie do końca rozumiem jej związek.

Wykonałem funkcję pgr_createTopology, która działała dość długo (12000 sek.) Podczas obliczania wszystkich krawędzi o długości 6 m. Myślałem, że to załatwi sprawę, ale wciąż jest nieznośnie powolna.

Chciałbym wiedzieć, czy coś zapomniałem. Myślałem o użyciu pgRouting zamiast biblioteki Java, ale w tej chwili jego wydajność nie jest porównywalna.

Problem z wydajnością pgRouting polega na tym, że nowe pgr_astar i pgr_dijkstra używają całego wykresu (co gwarantuje rozwiązanie, jeśli takie istnieje). Prostym rozwiązaniem dla uzyskania lepszej wydajności jest ograniczenie wykorzystywanego wykresu do mniejszego obszaru. Ma swoje własne problemy, takie jak czasami może tworzyć wykresy, których nie można rozwiązać

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

Tworzy BBOX ponad kolekcję źródłową i docelową i rozwija ją o 0,1 stopnia, następnie to samo zapytanie służy do ograniczenia wielkości wykresu w zapytaniu pgr_

Dijkstra od 1,2 s do ~ 65 ms

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 * od 2s do ~ 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 został użyty do importowania danych (najnowsza Finlandia) do tabeli Postgis. dodano indeks gist do kolumny geom_way i uruchomiono analizę próżni dla bazy danych. pamięć współdzielona 1G. workmem 512M

W końcu doszedłem do wniosku, że najlepiej umieścić cały wykres (w tym indeksy) w osobnym obszarze tabel, który na stałe znajduje się w pamięci za pomocą ramdysku.

Aby skonfigurować ramdysk na Ubuntu 13.04, skorzystałem z poniższych instrukcji i muszę powiedzieć, że działa całkiem dobrze (zawiera instrukcje ponownego ładowania danych do pamięci po ponownym uruchomieniu / ponownym uruchomieniu).

W przyszłym tygodniu zdobędę rękę na nowych dyskach SSD (odczyt 1 GB / s) i spróbuję porównać wydajność.

Z tego, co widzę, jest to jedyne rozwiązanie, aby wykres 1M + wierszy był stale dostępny, ponieważ zdarzają się ciągłe losowe odczyty.

Użyj tego przewodnika do utworzenia indeksów dla bazy danych przestrzennych. Oto jego sedno:

 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

dla moich tabel _4pgr i _vertex tylko kolumny źródłowa i docelowa miały indeksy po imporcie (osm2po-core-5.1.0).