[OSM-talk-fr] téléchargement d'une zone trop grande - Mirroirs de la base OSM

Philippe Verdy verdy_p at wanadoo.fr
Mer 22 Fév 18:48:02 UTC 2012


L'autre problème du système Postgresql c'est qu'il est totalement lié
à la version même du moteur. Ça manque d'ouverture et c'est une
solution technique insurmontable pour un vrai travail collaboratif,
alors qu'on a un schéma d'échange en XML parfaitement viable et
utilisable pour l'alimentation en streaming, et indépendant du moteur
utilisé.

Bref, si le système de réplication Postgres est utilisé, il servira
surtout à alimenter un second système local, lequel produira un stream
XML qui peut alors être souscrit et diffusé efficacement (et si un
client veut s'inscrire en partant de rien, il doit exister des
serveurs permettant d'obtenir, en un temps plus ou moins long une
image XML de base produite par un snapshot daté, tandis que le même
client reçoit déjà le stream live qui contient les autres mises à
jour: le premier objet du stream qu'il reçoit contient un marqueur de
la date de référence à demander au serveur de snapshot, de sorte qu'en
chargeant ensuite ce snapshot, les objets déjà reçus depuis le stream,
et qui sont davantage à jour, ne seront pas écrasés par d'anciennes
versions provenant du snapshot reçu et chargé ultérieurement).

Si on ne veut pas avoir à générer autant de snapshots que de client,
pour des raisons de coût/performance/espace, on peut aussi sur le
serveur de snapshots n'en garder qu'un ou quelques-uns, lequel serveur
peut aussi fournir aussi un stream contenant tous les objets depuis ce
snapshot jusqu'à une date assez récente (qui sera postérieure à la
date de souscription au stream "live" que le client lit déjà).

Il reste donc juste à s'assurer que les objets du stream et ceux di
serveur contiennent bien leur numéro de version afin de pouvoir
retenir celui qui est le plus avancé. On n'est pas non plus obligé de
mettre dans le stream ni dans le snapshot toutes les versions passées.
Pour les recherches d'historique, cela se fait plutôt à la demande,
objet par objet, et on peut malgré tout imaginer que les historiques
soient servis par une autre base de données sur un autre serveur,
destiné à la consultation des archives.

Le 22 février 2012 18:35, sly (sylvain letuffe) <liste at letuffe.org> a écrit :
> On mercredi 22 février 2012, Emilie Laffray wrote:
>> Postgresql merde quand il y a des tables
>> temporaires. C'est un bug connu qu'on espere voir corrige dans 9.2.
>
> Que postgresql s'améliore sur ce point c'est bien, mais je ne suis pas sûr que
> ça soit la meilleure voie car cela restreindrait à postgresql là ou
> des "mirroirs" dans d'autres schémas, base, formats pourraient profiter d'une
> réplication temps réél.
>
> Mais quoi qu'il en soit, ça sera du boulot et je souhaite beaucoup de courage
> à ceux qui vont se lancer dans le projet
>
> --
> sly
> qui suis-je : http://sly.letuffe.org
> email perso : sylvain chez letuffe un point org
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr




Plus d'informations sur la liste de diffusion Talk-fr