C'est pour ça qu'il y a le type gist sous postgresql. Mais je te conseille vraiment de pousser l'idée sur la mailing list internationale de développement.
Emilie Laffray 2012/2/22 Philippe Verdy <[email protected]> > Enfin je me suis expliqué plus longuement pourquoi une requête de > simple comptage peut être très efficace et soulager énormément le > serveur. > > Car les technologies d'indexation multidimensionnelle dans une base de > données relationnelle existent depuis longtemps (plusieurs dizaines > d'années qu'elles sont proposées au départ comme extensions dans les > SGBD, puis intégrées totalement à ces systèmes qui incluent nativement > la création de tels index, pour différentes applications y compris les > "métacubes" qui effectuent des agrégations complexes de données au > départ purement relationnelles et à valeur simples). > > La syntaxe de création de tels index multidimensionels peut être aussi > simple que: > > CREATE INDEX nodes_coords ON nodes ((x, y)) > > où les parenthèses internes indiquent que les attributs indiqués ne > privilégient pas un ordre d'indexation d'un attribut par rapport à un > autre, mais demandent à l'index de maintenir automatiquement un > parcours équilibré de l'index entre les dimensions indiquées. > > En l'absence de tels index multidimensionnels intégrés au moteur SQL, > il fallait d'abord créer dans la table de noeuds une valeur d'attribut > supplémentaire, produite par une transformée alternant les bits de > données successifs de chaque coordonnées, et ensuite créer un index > basé sur la valeur de cet attribut spécial. > > Mais c'était coûteux en espace, et pas optimal non plus car la > transformation était prédéterminée en fixant dès le départ le mode de > découpage strictement alterné entre les dimensions, sans tenir compte > du poids statistique réel de chaque découpe fixée aussi sur des > valeurs de seuil prédéterminées (sans tenir compte de la densité > réelle des éléments dans chaque découpe : l'arbre de découpage n'était > pas bien équilibré à cause justement de cette transformation > arbitrairement prédéterminée sur des seuils fixes, là où un index > multidimensionnel détermine localement et automatiquement les seuils > les plus adéquats pour maintenir le meilleur équilibre statistique et > une densité à peu près constante dans tous les parcours possibles et à > tous les niveaux de l'arbre). > > Le 22 février 2012 18:31, Philippe Verdy <[email protected]> a écrit : > > Non, la signature numérique ne modifie pas du tout l'API car cela > > n'apparaîtra que comme des attributs de plus parmi d'autres. > > > > Le 22 février 2012 18:29, Emilie Laffray <[email protected]> a > écrit : > >> Salut, > >> > >> c'est fort intéressant mais plutôt que nous abreuver de ce genre de > détails > >> peut être faudrait il en parler sur la liste de Développement en > anglais, la > >> ou toutes les réelles discussions techniques ont lieu. > >> De plus, il y a des raisons historiques et de performances pour le > >> comportement de l'API. Déjà, c'est un choix volontaire de réduire la > taille > >> car c'est une API pour les contributeurs. Quand le point est soulevé, on > >> pointe vers le fichier planète avec synchronisation. > >> Ce que tu offres c'est un peu un raisonnement un peu déconnectée de la > >> réalité. De plus, la réplication est déjà possible. Passer vers une > solution > >> décentralisée avec une signature ne résoudra pas grand chose et le coup > de > >> calcul des signatures sera important, sans parler le coup de la > >> synchronisation (il suffit de demander aux gens qui ont des miroirs ici) > >> rend une vrai solution décentralisée extrêmement compliquée. > >> Ta solution de la signature si elle n'est pas valide obligerait de > rappeler > >> l'API et donc de rajouter une charge supplémentaire. > >> > >> Emilie Laffray > >> > >> 2012/2/22 Philippe Verdy <[email protected]> > >>> > >>> Le 22 février 2012 15:49, sly (sylvain letuffe) <[email protected]> a > >>> écrit : > >>> > On mercredi 22 février 2012, sukran.geo sukran.geo wrote: > >>> >> Bonjour, J'ai une zone dans OSM que je veux télécharger, mais... > >>> >> apparemment, elle est trop grande, et voici le message qui > s'affiche. > >>> >> (voir > >>> >> JPEG Joint) J'ai ensuite téléchargé le fichier de Geofabrik, mais > idem, > >>> >> pb > >>> >> de taille. Que faire ? Il me faut toute la zone, et je ne veux pas > pas > >>> >> faire > >>> >> plein de petits morceaux. > >>> > > >>> > Elle est grosse comment ta zone ? > >>> > Parce que si tu veux ouvrir un département complet dans JOSM, il vaut > >>> > mieux > >>> > oublier tout de suite et faire autrement ;-) > >>> > Si c'est raisonnablement petit, mais que l'api officielle te bloque, > >>> > dans JOSM > >>> > tu peux tenter de remplacer api.openstreetmap.org par > >>> > api.openstreetmap.fr > >>> > les limites en téléchargement son plus élevées > >>> > >>> Mais c'est vrai aussi qu'il manque à la base OSM un vrai système de > >>> réplication sur des miroirs synchronisés, capables de répondre de > >>> concert à une même requête. > >>> > >>> Quelques idées suivent... > >>> > >>> Une sorte de RSYNC mais adapté aux bases de données (et non à un > >>> système de fichiers hiérarchique), par lequel toute modification > >>> enregistrée dans la base principale permet d'alimenter un flux de > >>> redistribution des transactions "committées" vers un ensemble de bases > >>> miroirs. De tels systèmes de réplication sont dans tous les RDMBS > >>> commerciaux, mais pas toujours dans les RDBMS libres où ce sont > >>> souvent des greffons mal intégrés ne garantissant pas la > >>> synchrinisation de l'ensemble et la cohérence relationelle des > >>> transactions annulées par un "rollback". > >>> > >>> Cela nécessite des systèmes réellement transactionnels pour valider > >>> l'état réel des modifications confirmées sur une base centrale, mais > >>> aussi un système de "rattrapage" permettant même de resynchroniser une > >>> base esclave qui aurait perdu à un moment donné le fil et devrait se > >>> remettre à jour (par exemple en cas d'arrêt momentané pour une > >>> maintenance, ou à cause d'un problème réseau temporaire, ou simplement > >>> pour démarrer une nouvelle base esclave au départ vierge, avec une > >>> synchronisation qui va progressivement charger les donnés manquantes). > >>> > >>> Enfin si une telle réplication était réellement opérationnelle et > >>> assez rapide pour qu'un ensemble de bases miroirs puissent toutes > >>> répondre à une demande de chargement de données (je ne parle pas des > >>> requêtes de modification de ces données), une déclaration de ces bases > >>> miroirs opérationnelle pourrait avoir lieu dans le système DNS afin > >>> que ces requêtes soient distribuées au hasard sur n'importe laquelle > >>> de ces bases et pas forcément la base centrale qui est bien plus utile > >>> et seulement nécessaire pour valider les transactions de modification. > >>> > >>> Cela imposerait d'avoir deux adresses (URL) de bases de données dans > >>> les éditeurs : une pour les chargements et mises à jour, l'autre pour > >>> les modifications, sachant que ce n'est qu'au moment où on va valider > >>> les données (dans un système de « validation en deux phases ») que la > >>> première chose qui sera faite sera de comparer les versions provenant > >>> des miroirs et celles actuellement dans la base, afin qu'à ce seul > >>> moment-là le serveur central puisse fournir une URL vers les données à > >>> jour dans un des miroirs disponibles sur lequel le serveur central > >>> pourrait poser un verrou temporaire sur les objets correspondants, > >>> pour la validation en deux phases, jusqu'à ce que soit la transaction > >>> soit validée par un "commit" soit annulée par un "rollback", soit que > >>> cette annulation ait lieu automatiquement après un délai raisonnable, > >>> le client devant alors refaire ses transactions et étant prévenu que > >>> sa dernière transaction a été annulée). > >>> > >>> Bote: les transations sont autre chose que les groupes de > >>> modifications qui sont des regroupements logiques effectués > >>> utilisateur par utilisateur (selon leur propre logique et leur > >>> déploiement car un même utilisateur peut utiliser simultanément > >>> plusieurs outils et donc avoir plusieurs groupes de modification > >>> ouverts. Ces groupes sont ouverts pour une durée relativement longue > >>> (la fermeture automatique n'a lieu qu'au bout de deux heures > >>> d'inactivité sur ce groupe, en théorie du moins car j'ai déjà vu le > >>> serveur fermer prématurément un groupe en moins de 5 minutes, et même > >>> parfois au beau milieu d'un enregistrement, les autres modifications > >>> non envoyées étant alors rejetées mais devant être enregistrées dans > >>> un autre groupe). > >>> > >>> Pour moi la fermeture automatique des groupes n'est pas nécessaire, > >>> sauf pour leur attacher quelques attributs en commun. Notamment le > >>> suivi des attributs indiquant quel est logiciel utilisé, qui l'a créé, > >>> quand il a commencé et quand *l'utilisateur* a indiqué qu'il avait > >>> terminé, et finalisé son commentaire. > >>> > >>> Le commentaire ne devrait être finalisé que si *toutes* les modifs ont > >>> pu être envoyées. En cas de conflit d'édition, un groupe de modifs > >>> peut rester ouvert relativement longtemps, le temps pour l'utilisateur > >>> de régler ces conflits avant de soumettre les autres données, dont bon > >>> nombre d'ailleurs ne sont pas en conflit. > >>> > >>> Mais le serveur alors va fermer prématurément un groupe de modifs, > >>> alors que les données envoyées sont incomplètes, ce qui laisse par > >>> exemple des noeuds ajoutés, mais pas les chemins qui les connecte, ou > >>> des voies ajoutées sensées remplacer une autre dont la demande de > >>> suppression n'est pas encore passée. > >>> > >>> A cause de cela, cela laisse des doublons et données incohérentes dans > >>> la base, et aucun moyen pour les outils de suivi de savoir quoi faire. > >>> D'autant plus que le serveur OSM ne renseigne même pas quand il a > >>> *lui-même* fermé un groupe de modification laissé ouvert (normalement > >>> le temp pour l'utilisateur de régler les conflits ou ses problèmes de > >>> connexion). > >>> > >>> Bref, la fermeture automatique des groupes de modification est une > >>> très mauvaise idée, et même une totale et complète ***aberration*** du > >>> schéma actuel. Cela ne correspond d'ailleurs à rien en terme > >>> transactionnel, puisque les validations (commits) et réplications se > >>> feront à une échelle bien plus petite, celles des objets (avec leurs > >>> attributs et leurs membres pour les relations). > >>> > >>> Les groupes de modifications eux-mêmes sont un objet distinct de la > >>> base de données. Leur existence est nécessaire avant toute autre > >>> opérations de création/modification/suppression sur les autres objets, > >>> mais personne d'autre que l'utilisateur qui l'a créé via son logiciel, > >>> ***pas même le serveur***, ne doit avoir à en contrôler l'indication > >>> de sa fermeture, ni certains autres attributs tels que le commentaire, > >>> voire des métadonnées nécessaires à la l'octroi de licence, car > >>> personne d'autre que lui ne pourra les changer (en revanche le serveur > >>> continuera à contrôler des attributs comme l'identité de > >>> l'utilisateur, si cette identité a été certifiée par un protocole > >>> sécurisé, et les dates d'ouverture ou de dernière modification dans ce > >>> groupe ; il ne fera éventuellement qu’exiger que certains autres > >>> attributs soient renseignés dans le groupe de modifications, comme > >>> l'identification suffisante du logiciel utilisé, ou le "user-agent" > >>> d'un navigateur, et quelques autres données comme la langue utilisée > >>> dans le logiciel de l'utilisateur). > >>> > >>> Ces objets "groupes de modifications" entrent dans les données > >>> nécessaires pour analyser les historiques, retrouver les auteurs, > >>> comprendre les raisons de certaines données, ou à quoi elles étaient > >>> peut-être destinées; elles sont aussi indispensable pour suivre les > >>> conditions de licence et donc doivent être conservées si les autres > >>> objets qui sont listés dans ce groupe à une version donnée sont encore > >>> présents dans la base. Ces groupes de modification sont aussi à > >>> transporter dans les systèmes de synchronisation, au même titre que > >>> les objets géométriques (neuds et chemins) et les relations (ces > >>> objets les référencent version par version). > >>> > >>> Un groupe de modifications peut être mis à jour autant de fois que > >>> nécessaire par un même utilisateur et sans limite de durée — du moins > >>> tant que le même utilisateur n'a pas rouvert un autre groupe > >>> référençant des modifications sur un ou plusieurs des mêmes objets > >>> géométriques ou relations, seul cas où éventuellement on peut admettre > >>> une fermeture automatique. Mais je penche plutôt sur une condition de > >>> fermeture basée sur un volume maximum en nombre d'objets modifiés dans > >>> le groupe (basée davantage sur une politique mise en œuvre par le > >>> logiciel client qu'un contrôle absolu par le serveur), afin que le > >>> client s'assure d'envoyer des données cohérentes et suffisantes dans > >>> un même groupe de modifications, notamment quant il doit créer ou > >>> modifier un chemin, dont les nœuds modifiés/créés/ajoutés devraient > >>> toujours être dans le même groupe de modifications. Le logiciel client > >>> pourra créer automatiquement autant de groupes de modifications que > >>> nécessaire pour respecter correctement les contraintes de volume par > >>> groupe, mais seul l'utilisateur doit en contrôler la fermeture, même > >>> s'il y en a plusieurs, afin qu'il puisse finaliser le commentaire et > >>> les données nécessaires à une licence ou le contrôle ultérieur de > >>> validité de cette licence, telles que la citation d'une source > >>> autorisée, ou encore des commentaires destinés à une maintenance > >>> ultérieure sur des données seulement estimées ou incomplètes, ou > >>> encore pouvoir résoudre un conflit partiel nécessitant de modifier > >>> encore un objet déjà envoyé dans ce groupe de modifications. > >>> > >>> En revanche les transactions sur le serveur c'est autre chose ! Cela > >>> ne concerne que les objets individuels (ou presque) et se limite à > >>> assurer qu'il n'y a pas de conflit de versions, ni perte de la > >>> cohérence référentielle de base: > >>> * un chemin doit toujours associer au moins deux nœuds (quitte à ce > >>> qu'ils soient superposés géométriquement). > >>> * les nœuds d'un chemin doivent toujours exister, et doivent avoir un > >>> numéro de rang unique dans ce chemin (afin de pouvoir définir un > >>> ordre). > >>> * les membres d'une relation doivent toujours exister, et doivent > >>> avoir un numéro de rang unique dans la relation (afin de pouvoir > >>> définir un ordre). > >>> * chaque version d'un noeud/chemin/relation doit toujours référencer > >>> un groupe de modifs existant, > >>> * une même version d'un noeud/chemin/relation ne peut pas être > >>> référencée par plusieurs groupes de modifs, > >>> * un groupe de modifs doit toujours référencer un utilisateur > >>> existant et cette référence à un utilisateur ne peut pas être changée > >>> (on ne peut que supprimer un groupe de modifiations et les versions de > >>> nœuds/chemins/relations qui référencent ce groupe). > >>> * et certains attributs sur ces objets sont obligatoires et respecter > >>> certaines contraintes pour leur valeur ou leur format. > >>> > >>> Ces règles de base (purement relationnelles) sont celles servant à > >>> définir les briques minimales de ce qui sera synchronisé entre > >>> serveurs ou miroirs et lors des transactions (même pour les > >>> transactions à validation multiphase). Avec cela on peut sérieusement > >>> envisager un déploiement solide et plus large de serveurs coopérant > >>> entre eux, y compris pour la contribution de leur bande passante, et > >>> avec les utilisateurs, avec un coût partageable qui pourra être réduit > >>> pour le bénéfice de tout le monde pour peu que chacun puisse faire une > >>> contribution, même petite au regard du volume total des transactions > >>> échangées, mais pourtant utile à tous car elle aussi partagée et > >>> offerte aussi aux autres en tant que service supplémentaire. > >>> > >>> Toutefois pour que les miroirs fonctionnent réellement, il doit > >>> exister un moyen de vérifier que ceux-ci ne véhiculent pas > >>> d'informations altérées par rapport au serveur central où sont > >>> validées les modifs. La solution simple consiste à ce que le serveur > >>> central calcule une signature numérique des données qu'il a validées, > >>> avec un certificat de sécurité dont il détient seul la clé privée, > >>> tandis qu'il fournit à tous une copie du certificat de sécurité > >>> contenant la clé publique permettant de comparer les signatures > >>> numériques recalculées. Cette signature numérique serait alors un > >>> attribut de tous les objets qui peuvent accessibles et sont distribués > >>> par la base. > >>> > >>> La signature numérique d'une version d'un objet étant dépendante de la > >>> date de cette version, ainsi que du certificat utilisé pour la > >>> calculer à cette date, il faut aussi que l'objet contiennent la > >>> référence à ce certificat (devenu un objet relationnel à part entière > >>> dans la base). Ce qui permet aussi plus tard de mettre à jour ou > >>> changer ces certificats et de recalculer les signatures numériques des > >>> autres objets relationnels (et leurs attributs textuels, numériques ou > >>> géométriques) en cas d'expiration du certificat. Bref deux attributs > >>> par objet: la signature numérique (par exemple une chaine hexadécimale > >>> de longueur fixe dans un attribut "Signature:SHA1"), et un URI (URL ou > >>> URN) vers la copie publique du certificat de sécurité (dans un > >>> attribut comme "Signature:Certificate"). > >>> > >>> Ces attributs seront calculés par le serveur de validation uniquement > >>> et présentés dans toutes les requêtes. Il faut une signature séparée > >>> par objet (nœud, chemin, relation, groupe de modifications, > >>> utilisateur), cette signature exposée publiquement ne devant être > >>> calculée QUE sur les données publiques accessibles (pas les données > >>> privées ou secrètes, par exemple dans un objet de type utilisateur). > >>> > >>> De la même façon le serveur central de validation peut aussi calculer > >>> une signature numérique pour un objet représentant un serveur > >>> lui-même, si le système autorise ce serveur à effectuer des > >>> validations locales qui seront ensuite transmises par ce serveur local > >>> au serveur central, "au nom de" ses propres utilisateurs sur le > >>> serveur local. Cela permet un système où la confiance et la > >>> responsabilité peut être déléguée et partagée, de façon limitée, avec > >>> une responsabilité assumée par celui qui gère un serveur local. Cela > >>> peut aussi servir à accorder à un serveur local davantage de droits en > >>> terme de bande passante, car il assure un service pour de nombreux > >>> utilisateurs en soulageant le serveur central de la visite de ces > >>> mêmes nombreux utilisateurs. > >>> > >>> Avec un objet dans la base de données représentant un serveur > >>> (probablement représenté par une URL, mais ce peut être aussi un > >>> simple ID numérique vers un objet contenant en attribut cette URL à > >>> priori unique dans la base), une requête à un serveur pourra donner > >>> une réponse contenant la référence à un autre serveur disponible (par > >>> exemple lors d'opérations de maintenance sur l'un d'eux, ou d'un > >>> problème de disponibilité d'une liaison, ou de délai de mise à jour > >>> dans les données en cache d'un serveur DNS utilisé par le client). > >>> > >>> _______________________________________________ > >>> Talk-fr mailing list > >>> [email protected] > >>> http://lists.openstreetmap.org/listinfo/talk-fr > >> > >> >
_______________________________________________ Talk-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-fr
