J'utilise pgrouting sur une base de données postgis créée via osm2pgrouting. Il fonctionne très bien sur un ensemble de données limité (voies de 3,5 km, toutes les recherches A * du chemin le plus court <20 ms).
Cependant, depuis que j'ai importé une boîte englobante plus grande (122k voies) d'europe.osm, les performances ont beaucoup baissé (le chemin le plus court coûte environ 900 ms).
Je pense que l'utilisation de A * la plupart de ces bords ne seront jamais visités car ils sont à l'écart.
Ce que j'ai fait jusqu'à présent pour essayer d'améliorer la vitesse:
- Mettre un index sur la colonne de géométrie (pas d'effet notable)
- Augmentation de ma mémoire de 8 Go à 16 Go
- Modifiez les paramètres de mémoire postgresql (shared_buffers, effective_cache_size) de (128 Mo, 128 Mo) à (1 Go, 2 Go) (pas d'effet notable)
J'ai le sentiment que la plupart du travail se fait dans la bibliothèque C Boost où le graphique est fait, donc l'optimisation de postgresql ne me donnera pas de bien meilleurs résultats. Comme je fais des changements mineurs à l'ensemble de lignes que je sélectionne pour A * pour chaque recherche, j'ai un peu peur que la bibliothèque de boost ne puisse pas mettre en cache mon graphique et doive reconstruire tous les 122k bords à chaque fois (même si elle n'utilisera qu'une très sous-ensemble limité à chaque requête). Et je n'ai aucune idée du montant dépensé pour cela par rapport à la recherche du chemin le plus court.
L'un de vous utilise-t-il le pgroutage sur un ensemble de données OSM de 122k ou plus? À quelle performance dois-je m'attendre? Quels paramètres affectent le plus les performances?