Non je ne parle pas de l'installation du socle logiciel.Le problème c'est bien la réplication des données et là on est vraiment à la ramasse: il suffit de voir comment c'est compliqué et long de redémarrer quand une instance est plantée, et pas du tout à cause du logiciel opensource utilisé ou de l'OS.
On a un problème sérieux dans l'architecture des données elles-mêmes et leur mode de distribution/réplication. Et on n'a pratiquement rien fait pour améliorer ça. Le 23 juillet 2017 à 19:59, marc marc <marc_marc_...@hotmail.com> a écrit : > Philippe je me perd dans la structure de ton message. > > ma réponse si j'ai bien compris ton avis : > - la doc d'installation d'un overpass api est limpide pour un sysadmin > (même si je ne l'ai pas encore testé). jesaispluski a fait un ansile. > il ne reste qu'à valider mais si c'est confirmé, déployer une nouvelle > instance n'est qu'une question d'avoir un serveur pour l'héberger et des > humains qui s'en occupent... > Passer à du propriétaire ne change rien à ces 2 besoins. > Au contraire ca implique de changer l'existant. > > - la majorité des énormes site mondiaux tournent sur un socle open > source. Tous les besoins que tu décris existent en open source et sont > massivement utilisé. > Changer de roue (le logiciel) ne résout rien. > > - avoir un opendata en logiciel propriétaire signifie que tu ne peux pas > la répliquer pour tel ou tel projet sans devoir faire appel à du > propriétaire... souvent payant... > Avoir une roue payante ne résout rien. > > Le 23. 07. 17 à 19:00, Philippe Verdy a écrit : > > 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 > > <mailto: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 > > <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 > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
