Warum dauert eine pgr_ * -Routingfunktion basierend auf OSM-Daten in einer pgrouting-fähigen Datenbank ewig?

9

Ich habe den deutschen OSM-Datensatz mit osm2po 4.7.7 in die pgrouting-Datenbank geladen. Alles funktioniert gut Ich habe osm2po über seine Konfiguration eingerichtet und es funktioniert wie ein Zauber durch seinen Java-Teil.

Ich hatte die Tabelle * _2po_4pgr ohne Probleme importiert. Sogar die * 2po_v-Tabelle wird importiert, obwohl ich die Beziehung dieser Tabelle nicht vollständig verstehe.

Ich habe die Funktion pgr_createTopology ausgeführt, die eine ganze Weile (12000 Sekunden) ausgeführt wurde, während alle 6-m-Kanten berechnet wurden. Ich dachte, das würde den Deal machen, aber es ist immer noch unerträglich langsam.

Ich würde gerne wissen, ob ich etwas vergessen habe. Ich dachte daran, pgRouting anstelle der Java-Bibliothek zu verwenden, aber im Moment ist es in Bezug auf die Leistung nur aus Vergleichsgründen.

Johnny Cusack
quelle
1
Haben Sie Indizes erstellt, haben Sie Postgis-Speichervariablen optimiert? createTopology wird nur einmal für das gesamte Dataset ausgeführt, sodass die Leistung nicht so wichtig ist. Randnotiz. Ich hatte ganz Finnland aus dem Digiroad-Datensatz (wie 2G Straßennetz) und lieferte Ergebnisse in maximal 250 ms, normalerweise 125 ms ohne Optimierungen. Also sollte es jetzt Tage besser sein
Simplexio
Es gibt Indizes für die Quell- und Zielspalte, die vom osm2po-Skriptgenerator automatisch erstellt werden. Mehr benötigt? Ich habe die Variablen work_mem /tenance_work_mem in einen GigaByte-Wert geändert , neu gestartet, aber immer noch keine Änderung. Gibt es eine Startskriptvorlage, die ich benötigen könnte?
Johnny Cusack
1
Hmmm ... Was macht createTopology ()? Ich meine, osm2po erstellt bereits die Topologie basierend auf OSM-Node-IDs. Es ist also nicht nötig, etw auszuführen. wieder ähnlich. Für pgRouting (shortest_path & shortest_path_astar) benötigen Sie nur die erstellte 4pgr-Tabelle. Das ist alles.
Carsten
Ich habe jetzt Finnland Datensatz, Postgis 2.0.3, pgrouting 2.0.0-dev. Und ich muss sagen, das ist langsam. Bei Verwendung von pgr_astar () ist das Ergebnis immer länger als 1 Sek. Ich überprüfe, ob ich dieses bisschen schneller
bekomme

Antworten:

5

Das Problem mit der Leistung von pgRouting scheint zu sein, dass neue pgr_astar und pgr_dijkstra das gesamte Diagramm verwenden (was eine Lösung garantiert, wenn es eines gibt). Eine einfache Lösung, um eine bessere Leistung zu erzielen, besteht darin, das verwendete Diagramm auf einen kleineren Bereich zu beschränken. Es hat seine eigenen Probleme, wie es manchmal Diagramme erstellen kann, die nicht gelöst werden können

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

Erstellt BBOX über der Quell- und Zielsammlung und erweitert sie um 0,1 Grad. Anschließend wird dieselbe Abfrage verwendet, um die Diagrammgröße in der Abfrage pgr_ zu begrenzen

Dijkstra von 1,2 s bis ~ 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 * von 2s bis ~ 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 wurde verwendet, um Daten (spätestens in Finnland) in die Postgis-Tabelle zu importieren. Hauptindex zur Spalte geom_way hinzugefügt und vollständiger Vakuumanalyselauf für die Datenbank. gemeinsamer Speicher 1G. Workmem 512M

Simplexio
quelle
Ich hatte die gleiche Idee mit dem Begrenzungsrahmen, immer noch weit über 90 Sekunden, selbst wenn Speichervariablen usw. eingestellt waren.
Johnny Cusack
Ich habe 380k Zeilen? Sie haben wahrscheinlich so etwas wie 3M + Leitungen in der Routing-Tabelle?
Simplexio
1
Dies ist eines der Hauptprobleme in Postgres, nicht das gesamte Diagramm zwischenzuspeichern. Es funktioniert ziemlich schnell. Aber ich muss es mit anderen Datenbanktabellen verbinden, was in der aktuellen (Test-) Situation einen riesigen Engpass mit nur 5qps (Abfragen pro Sekunde) schafft
Johnny Cusack
1
Ich habe gerade eine Teilmenge von 1 Million Zeilen in eine Ramdisk geladen, um sie zu vergleichen. pgr_dijkstra benötigt im Kaltlauf 3 Sekunden. pgr_astra mit dem von @simplexio bereitgestellten bbox-Beispiel dauert ein Kaltlauf ca. 900 ms. Es scheint also, dass ich alles in eine Ramdisk stecken muss, um die richtige Leistung zu erzielen.
Johnny Cusack
1
Groß! Mit den Indizes von @ kttii laufe ich jetzt schnell!
Magno C
5

Ich kam schließlich zu dem Schluss, dass es am besten ist, das gesamte Diagramm (einschließlich der Indizes) in einem separaten Tabellenbereich abzulegen, der sich mithilfe einer Ramdisk permanent im Speicher befindet.

Zum Einrichten der Ramdisk unter Ubuntu 13.04 habe ich die folgenden Anweisungen verwendet und muss sagen, dass sie ziemlich gut funktioniert (sie enthält Anweisungen zum erneuten Laden der Daten in den Speicher nach einem Neustart / Neustart).

Nächste Woche werde ich neue SSDs (1 GB / s gelesen) in die Hand nehmen und versuchen, die Leistung zu vergleichen.

Soweit ich sehe, ist dies die einzige Lösung, um ein Diagramm mit mehr als 1 Million Zeilen dauerhaft zugänglich zu halten, da dort fortlaufend zufällige Lesevorgänge stattfinden.

Johnny Cusack
quelle
Wie haben Sie das gesamte Diagramm (einschließlich Indizes) erstellt? Ich habe nichts in der Pgrouting-Dokumentation gesehen.
Dennis Bauszus
Ich habe osm2po verwendet, ein erstaunliches Stück Java-Code! osm2po.de
Johnny Cusack
5

Verwenden Sie dieses Handbuch , um Indizes für eine räumliche Datenbank einzurichten. Hier ist der Kern davon:

 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

Für meine _4pgr- und _vertex-Tabellen hatten nur die Quell- und Zielspalten nach dem Import Indizes (osm2po-core-5.1.0).

kttii
quelle
Fantastisch! von ~ 45 Sek. bis ~ 15 Sek. unter Verwendung von OSM South America mit Selbstverbindung.
Magno C
Entschuldigung, mein Fehler. von ~ 45 Sek. bis ~ 5 ms !!!!!!
Magno C