Tại sao bất kỳ chức năng định tuyến pgr_ * nào lại mất mãi mãi dựa trên dữ liệu OSM trong DB kích hoạt tính năng mở rộng

Tôi đã tải bộ dữ liệu OSM của Đức vào DB mở rộng bằng cách sử dụng osm2po 4.7.7. Mọi thứ đều hoạt động tốt, tôi đã cài đặt osm2po thông qua cấu hình của nó và nó hoạt động như một nét quyến rũ thông qua phần Java.

Tôi đã nhập bảng * _2po_4pgr mà không gặp vấn đề gì. Ngay cả bảng * 2po_v cũng được nhập, mặc dù tôi không hoàn toàn hiểu mối quan hệ của bảng này.

Tôi đã thực thi hàm pgr_createTopology chạy khá lâu (12000 giây) trong khi tính toán tất cả các cạnh 6m. Tôi nghĩ rằng điều này sẽ làm thỏa thuận, nhưng vẫn chậm đến mức không thể chịu đựng được.

Tôi muốn biết nếu tôi quên một cái gì đó. Tôi đã nghĩ đến việc sử dụng pgRouting thay vì thư viện java nhưng hiện tại, hiệu năng của nó chỉ là so sánh.

Vấn đề với hiệu suất pgRouting dường như là pgr_astar và pgr_dijkstra mới sử dụng toàn bộ biểu đồ (đảm bảo giải pháp nếu có). Giải pháp đơn giản để có hiệu suất tốt hơn là giới hạn biểu đồ được sử dụng cho diện tích nhỏ hơn. Nó có vấn đề riêng như đôi khi nó có thể tạo ra các biểu đồ không thể giải quyết

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

Tạo BBOX qua bộ sưu tập nguồn và đích và mở rộng 0,1 độ, sau đó cùng một truy vấn được sử dụng để giới hạn kích thước biểu đồ trong truy vấn pgr_

Dijkstra từ 1,2 đến ~ 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 * từ 2 giây đến ~ 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 đã được sử dụng để nhập dữ liệu (mới nhất là finland) vào bảng postgis. chỉ số chính được thêm vào cột geom_way và phân tích chân không đầy đủ chạy cho cơ sở dữ liệu. chia sẻ bộ nhớ 1G. công việc 512M

Cuối cùng tôi đã đi đến kết luận rằng tốt nhất là đặt toàn bộ biểu đồ (bao gồm các chỉ mục) trên một không gian bảng riêng biệt tồn tại vĩnh viễn trong bộ nhớ bằng cách sử dụng ramdisk.

Để thiết lập ramdisk trên Ubuntu 13.04, tôi đã sử dụng các hướng dẫn sau và phải nói rằng nó hoạt động khá tốt (bao gồm các hướng dẫn để tải lại dữ liệu vào bộ nhớ sau khi khởi động lại / khởi động lại).

Tuần tới tôi sẽ có được một tay trên SSD mới (1GB / giây đọc) và thử so sánh hiệu suất.

Theo như tôi thấy đó là giải pháp duy nhất để giữ đồ thị hàng 1M + có thể truy cập vĩnh viễn, vì có một lần đọc ngẫu nhiên liên tục xảy ra.

Sử dụng hướng dẫn này để thiết lập các chỉ mục cho cơ sở dữ liệu không gian. Đây là ý chính của nó:

 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

đối với các bảng _4pgr và _vertex của tôi, chỉ các cột nguồn và cột đích có các chỉ mục sau khi nhập (osm2po-core-5.1.0).