[OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

[Philippe Verdy]

Le 23 juillet 2017 à 23:37, <osm.sanspourriel at spamgourmet.com> a écrit :

> Si je comprends bien le souci c'est qu'en cas de plante il faut remonter
> une base puis appliquer les diff.
>
> C'est ça qui est lent.
>
> Mettre du propriétaire n'y changera rien.
>
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.

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).

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.

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...).

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)

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.

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.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20170724/213b80e5/attachment.htm>