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 <verd...@wanadoo.fr> 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 <emilie.laff...@gmail.com> 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 <verd...@wanadoo.fr> >>> >>> Le 22 février 2012 15:49, sly (sylvain letuffe) <li...@letuffe.org> 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 >>> Talk-fr@openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-fr >> >> _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
