<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Le 23 juillet 2017 à 23:37,  <span dir="ltr"><<a href="mailto:osm.sanspourriel@spamgourmet.com" target="_blank">osm.sanspourriel@spamgourmet.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="transparent">
    <p>Si je comprends bien le souci c'est qu'en cas de plante il faut
      remonter une base puis appliquer les diff.</p>
    <p>C'est ça qui est lent.</p>
    <p>Mettre du propriétaire n'y changera rien.</p></div></blockquote><div>Je ne dis pas mettre nécessairement du propriétaire, mais des solutions de réplication rapides existent et font appel à autre chose que nos très couteux "diff" et l'import de la base monde: on peut travailler à un niveau inférieur.</div><div><br></div><div>En attendant on a bien un gros problème puisque presque personne ne s'aventure plus à utiliser la solution actuelle (base monde+diffs) qui est beaucoup trop lourde et inefficace. C'est là qu'il faudrait étudier autre chose (et sans doute revoir le modèle de données).</div><div><br></div><div>Des réplications de base qui ne prennent pas des jours ça existe. Et ça ne demande même pas de stopper une base en production, ça se fait en live avec des mécanismes de synchronisation déjà éprouvés. Mais du côté de Postgres je ne connais pas trop ce qu'on peut faire.</div><div><br></div><div>Oracle, Sybase, MSQSQL là oui je connais et pour des volumes beaucoup plus importants que ceux de la base OSM avec avec de très gros traitements en plus, pour monter des "cubes" statistiques ou simplement pour assurer la redondance et une reprise relative rapide après un incident, qui ne coutera pas plusieurs journées de travail à des centaines de personnes qui ont besoin de remonter des informations et de produire des données avec des horaires impératifs tous les jours: on ne parle pas là de juste quelques heures mais des délais qui ne peuvent pas excéder la demi-heure; tout retard entraine des annulations de commandes, des remboursements, des pénalités, ou des retards de facturation et d'encaissement qui peuvent mettre en péril la santé financière d'une entreprise en l'obligeant à piocher dans des trésoreries limités ou faire des emprunts à court terme très couteux...).</div><div><br></div><div>OSM pourtant c'est d'abord et avant tout un projet de données, amis il faut reconnaître qu'on est très mauvais pour les distribuer comme on devrait. L'édifice est fragile. Et ça touche ensuite tout le reste de la chaine aval : controle qualité, lutte contre le vandalisme, récupération des dommages, rendus divers... Et dans ce domaine des sociétés privées ont mis en place d'autres solutions pour exploiter les données OSM et prévenir les graves incidents qu'on connait à répétition et où on peine beaucoup trop à se sortir. Cela nuit gravement à l'image d'OSM et est aussi une raison pour laquelle plein de services web préfèrent encore utiliser des données propriétaires (même si elles sont non neutres)</div><div><br></div><div>Disons donc que le logiciel utilisé par OSM on s'en fout. S'il faut le remplacer il ne faut pas hésiter, ce n'est pas le coeur du projet qui est avant tout les données elles-mêmes, qui sont de plus en plus lourdes et compliquées à gérer, et dont l'accès commence aussi à être de plus en plus difficile: ce n'est pas le même type de restriction, mais ces restrictions finissent par être pire que celles imposées par les API propriétaires de Google and Co ou les problèmes de licences et coûts d'accès (même si au passage Google lui en profite pour monter les prix sachant qu'il devient de plus en plus incontournable). Ce n'est pas parce qu'en dessous du plancher on aura utilisé des logiciels propriétaires (eux aussi remplaçables) qu'on aura touché à nos données.</div><div><br></div><div>Wikimedia par exemple a change de moteur PHP, puis de moteur SQL, il a aussi change d'OS, changé de matériels, changé de support réseau, de datacenters, il a décentralisé plein de services et facilité les migrations d'un système à l'autre. Dedans il y a plein de composants propriétaires mais c'est transparent et autant que possible ils ont essayé de ne pas s'astreindre à la solution unique, pour que tout soit remplaçable (avec juste des différences de performance qui peuvent être réglées). Les outils propriétaires ou opensource sont évalués pour ce qu'ils savent faire le mieux et permet aussi de maitriser les couts avec des moyens humains limités, rien n'est figé dans le marbre.</div><div><br></div></div></div></div>