pgrouting 가능 DB에서 pgr_ * 라우팅 기능이 OSM 데이터를 기반으로 영원히 사용되는 이유


9

osm2po 4.7.7을 사용하여 독일어 OSM 데이터 세트를 pgrouting DB에로드했습니다. 모든 것이 잘 작동합니다. 설정을 통해 osm2po를 설정했으며 Java 부분을 통해 매력처럼 작동합니다.

아무 문제없이 * _2po_4pgr 테이블을 가져 왔습니다. 이 테이블의 관계를 완전히 이해하지 못하더라도 * 2po_v 테이블조차 가져옵니다.

6m 가장자리를 모두 계산하면서 꽤 오랫동안 (12000 초) 실행되는 pgr_createTopology 함수를 실행했습니다. 나는 이것이 거래를 할 것이라고 생각했지만 여전히 느리게 느립니다.

내가 무언가를 잊었는지 알고 싶습니다. Java 라이브러리 대신 pgRouting을 사용하려고 생각했지만 현재 성능 측면에서는 비교할 수 없습니다.


1
인덱스를 생성 했습니까? postgis 메모리 변수를 조정 했습니까? createTopology는 전체 데이터 세트에 대해 한 번만 실행되므로 성능은 그다지 중요하지 않습니다. 사이드 노트. 나는 2G와 같은 digiroad 데이터 세트에서 핀란드 전체를 가지고 있었고 최적화없이 최대 250ms, 일반적으로 125ms의 결과를 반환했습니다. 그래서 지금은 나아질 것입니다
— simplexio

osm2po 스크립트 생성기에 의해 자동으로 작성된 소스 및 대상 열에 색인이 있습니다. 더 필요한가요? 나는 변경되지 work_mem / maintenance_work_mem로의 다시 시작하는 기가 바이트 값에 여전히 변화가 변수. 필요한 시작 스크립트 템플릿이 있습니까?
— Johnny Cusack

1
흠 ... createTopology ()는 무엇을합니까? osm2po는 이미 OSM-Node-ID를 기반으로 토폴로지를 만듭니다. 따라서 sth를 실행할 필요가 없습니다. 다시 비슷합니다. pgRouting (shortest_path & shortest_path_astar)의 경우 생성 된 4pgr 테이블 만 필요합니다. 그게 다야.
— Carsten

이제 finland dataset, postgis 2.0.3, pgrouting 2.0.0-dev가 있습니다. 그리고 나는 이것이 느리다고 말해야합니다. pgr_astar ()를 사용할 때 결과는 항상 1 초 이상입니다. 좀 더 빨라
— 졌는지

답변:


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_ query에서 그래프 크기를 제한합니다.

1.2에서 ~ 65ms의 Dijkstra

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 ;

2 초 ~ ~ 50ms의 A *

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 컬럼에 추가 된 gist 색인 및 데이터베이스에 대한 전체 진공 분석 실행. 공유 메모리 1G. 작업장 512M


메모리 바 등을 설정해도 90 초가 넘는 경계 상자와 동일한 아이디어를 얻었습니다.
— Johnny Cusack

나는 380k 라인을 가지고 있습니까? 라우팅 테이블에 3M + 라인과 같은 것이 있습니까?
— simplexio

1
이것은 전체 그래프를 캐시하지 않는 Postgres의 주요 문제 중 하나입니다. 상당히 빠르게 작동합니다. 그러나 나는 현재의 (테스트) 상황에서 단지 5qps (초당 쿼리)로 큰 병목 현상을 일으키는 다른 데이터베이스 테이블과 연결해야합니다.
— Johnny Cusack

1
방금 비교하기 위해 1M 행의 하위 집합을 램 디스크에로드했습니다. pgr_dijkstra는 콜드 런에서 3 초가 걸립니다. @simplexio에서 제공하는 bbox 예제를 사용한 pgr_astra는 콜드 런에 약 900ms가 걸립니다. 따라서 적절한 성능을 얻으려면 모든 것을 램 디스크에 넣어야합니다.
— Johnny Cusack

1
큰! @kttii의 색인으로 지금 빨리 달리고 있습니다!
— Magno C

5

마지막으로 램 디스크를 사용하여 메모리에 영구적으로 존재하는 별도의 테이블 스페이스에 전체 그래프 (인덱스 포함)를 배치하는 것이 가장 좋다는 결론에 도달했습니다.

Ubuntu 13.04에서 램 디스크를 설정하려면 다음 지침을 사용했으며 제대로 작동한다고 말해야합니다 (다시 시작 / 재부팅 후 데이터를 메모리에 다시로드하는 지침이 포함되어 있음).

다음 주에는 새로운 SSD (1GB / s 읽기)를 살펴보고 성능을 비교하려고합니다.

내가 아는 한, 연속 임의 읽기가 발생하기 때문에 1M + 행 그래프를 영구적으로 액세스 할 수있는 유일한 솔루션입니다.


전체 그래프 (인덱스 포함)를 어떻게 만들었습니까? pgrouting 문서에서 아무것도 보지 못했습니다.
— Dennis Bauszus

놀라운 자바 코드 인 osm2po를 사용했습니다! osm2po.de
— Johnny Cusack

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


환상적인! 자체 조인 기능이있는 전체 OSM 남아메리카를 사용하여 ~ 45 초 ~ ~ 15 초
— Magno C

미안 ... 내 실수. ~ 45 초 ~ ~ 5ms !!!!!!
— Magno C
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.