Je crois que le gros problème pour avoir plus de serveurs et donc de redondance c'est toujours le même: moins un problème de bande passante que de la charge énorme que représente l'installation de la base de données, et le fait que très peu de progrès ont été faits pour faciliter sa réplication.
Les diffs ne sont pas forcément la meilleure façon si on peut disposer de réplication directe entre bases de données. Mais le choix initial de Postgres ne facilite pas les choses, et là où ça marche vraiment très bien c'est sur d'autres moteurs, malheureusement "propriétaires" comme Oracle, mais en fait seulement commerciaux et qui pourtant ne devrait pas coûter très cher en licence en comparaison des coûts nécessaires pour les stockages, l'hébergement dans un datacenter et la bande passante, mais surtout les couts humains que représentent la maintenance sur la solution actuelle. Passer à des moteurs SQL commerciaux plus solides est surtout un seuil psychologique pour les promoteurs du projet. On craint une nouvelle dépendance alors que les dépendances les plus importantes (humaines) ne sont même pas résolues. On en arrive alors à figer les évolutions, et le projet est soutenu par une infrastructure de plus en plus fragile, qu'un rien suffirait à faire s'effondrer du jour au lendemain (avec des pannes qui mettront ensuite le projet en péril pendant des mois, avec de grosses difficultés pour recapter l'audience qu'il avait). On promeut OSM auprès des administrations, mais faute de ressources humaines on n'est crédible que si à côté de nous on a de vrais fournisseurs de services professionnels. Ces fournisseurs existent, on les a incité à utiliser nos données mais on les a trop peu sollicité pour qu'ils continuent aussi à solidifier l'infrastructure (quitte à accepter qu'on y incorpore des composants propriétaires qui seraient transparents pour nous et pas gênants du tout car n'affectant pas les données elles-mêmes, mais juste l'infrastructure qui les supporte). Et tant qu'on ne franchit pas ce seuil psychologique, Google a encore de beaux jours devant lui et continuera à imposer ses services (mais avec en revanche un comportement pas transparent du tout, affectant les données directement, et avec l'accaparement des droits sur ces données, leur disponibilité et les conditions de leur réutilisations, qui ne font que devenir de plus en plus restrictives et chères pour tout le monde) Demandons nous ce qui est important pour OSM: le logiciel qui le supporte est-il si indispensable et non remplaçable ? Ou bien est-ce les données ? Ne fermons pas la porte aux logiciels propriétaires dans l'infrastructure. A la place consolidons les API, formats de données. Là des choses sont à expérimenter, pas forcément uniquement au sein du moteur SQL, mais avec des systèmes de fichiers synchronisés au niveau de l'OS, ou avec les moniteurs transactionnels. ou la réplication dynamique de machines virtuelles contenant une instance d'OS entière avec ses logiciels et données. Le 23 juillet 2017 à 16:28, sly (sylvain letuffe) <lis...@letuffe.org> a écrit : > overflorian wrote > > Est-ce que vous sauriez à quoi cela est dû ? > > Cette page liste l'historique des problèmes rencontrés par les 2 instances > "principales" : > https://wiki.openstreetmap.org/wiki/Overpass_API/status > > > overflorian wrote > > Quelles en sont les causes profondes ? > > Je pense que ça se résume simplement : > - Trop de gens tirent dessus et trop peu de gens installent d'instances > publiques (pour répartir la charge, offrir une possibilité de redondance) > ou > participent à la maintenance. >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
