Sauf que le choix de PostgreSQL n'est pas stupide étant donné ce qui est demandé et déjà fourni:
- moniteur transactionnel anvec transaction log et recovery, backup et réplication "live", gestion des caches, construction des index, niveau de performance et de sécurité, concurrence d'accès très élevée, gestion des supports de stockage, etc. - le package GIS pour PostgreSQL et le support des recherches géométriques par coordonnées - les packages de transformation de géométrie. Ca fait beaucoup à réécrire avec trop de bogues possibles pendant longtemps (alors que PostgreSQL est stable et performant et bien maintenu) ! Certes Overpass n'étant qu'un outil d'interrogation, il n'a pas (ou pas encore!) à gérer des mises à jour de la base de données OSM (exemple sélectionner une liste d'objets, permettre la modification de certains tags, faire des fusions ou conversion de tags, puis soumettre les objets modifiés dans un ou plusieurs changeset au nom de l'utilisateur). Il peut encore monter une copie read-only de la base OSM sans gestion des transactions, mais il a besoin de transactions séparées pour l'exécution de chaque requête et construire des index temporaires de sélection et les combiner. Cependant sa base read-only doit aussi suivre l'intégration des minute-diffs venant de la base principale pour rester synchronisée avec elle. Les transactions évitent aussi une corruption totale et la reconstruction complète à partir d'un planet dump (qui prend plusieurs jours) en cas de plantage temporaire (il y a moyen de se resynchroniser automatiquement en faisant un rollback des transactions incomplètes non "committées" par les minute-diffs incomplètement chargés). Overpass a besoin aussi des outils géométriques pour pas mal de ses requêtes qui font des transformations (exemple: calcul de buffer, cacul d'un centroïde). Pour Overpass en revanche ce qui manque c'est juste un optimiseur de requête permettant de calculer un plan d'exécution correct (car il est clair que le plan d'exécution fait par Overpass est mauvais et oblige à faire de multiples requêtes très lourdes à la base OSM principale pour ensuite appliquer localement sur son propre serveur des fusions et filtres. Le problème n'est pas dans la base OSM elle-même mais bien dans OverPass (sur ses propres serveurs) : - la façon dont il analyse les requêtes utilisateur pour les transformer en requêtes avec la base principale (même s'il en dispose localement d'une copie répliquée pour éviter de faire des requêtes distantes d'un pays à l'autre, puisque Overpass est installé en Allemagne, en France et en Russie mais la base OSM principale en Angleterre: les "lags" seraient beaucoup trop longs et en plus la quantité de données qu"'Overpass demanderait à la base principale serait trop élevée par rapport aux requêtes standards par l'API sur des régions bien plus limitées) - ou la façon dont il gère des caches de données pour les requêtes courantes (sa gestion des "areas" n'est qu'une solution paliative pour une partie spécifique d'un problème en fait plus général). Le 16 mai 2016 à 21:20, Bruno <pa...@free.fr> a écrit : > Le 16/05/2016 17:59, Philippe Verdy a écrit : > Bonjour, > > Pour ma part je pense qu'une base NoSQL sur une architecture distribuée > serait une solution plus perenne, plus performante et avec moins de > contraintes de schéma préétabli que les bases SQL. >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
