Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je souhaiterais faire connaître la publication d'une extension Postgres écrite en C, accompagnée d'un modèle de données. Cette extension disponible sur https://github.com/olivierch/openBarter permet de mettre en place un serveur de troc. Ce serveur est accessible par un client postgres à travers quelques primitives qui voient des procédures stockées.
Cette extension utilise la bibliothèque Berkeley DB.
Je suis intéressé d'avoir vos réactions, même si la documentation est encore minimale.
Olivier Chaussavoine
Hors ligne
À quoi sert la partie Berkeley DB ?
Marc.
Hors ligne
J'aurais bien aimé pouvoir le faire avec postgres, mais je n'ai pas une connaissance suffisante de ses mécanismes internes pour faire ce que j'ai pu réaliser avec berkeleyDb. Ce sont des tables temporaires dont la durée de vie se limite à la requête postgres, qui me permettent de parcourir très rapidement le graphe des offres, et appliquer plusieurs algo de recherche. Toutes les tables berkeleydb restent en mémoire vive, et n'ont aucun mécanisme de sémaphore, ce qui permet d'éviter les problèmes de verouillage cyclique qu'on rencontre souvent lors de parcours de graphe. Lorsque les résultats sont rapatriés, les données sont versionnées, et rejetées si elles ne sont pas à jour. Je ne crois pas que ça doit arriver trop souvent.
Avantages du choix - ça marche. Inconvénients majeur - je dois allouer environ 4Mo par client séparément de la gestion mémoire de postgres. Je fais en sorte que ce quota ne soit jamais dépassé.
Il y a certainement moyen de faire la même chose en postgres, mais je ne m'y connais pas assez. Une partir de mon code pourrait en tout cas être repris car l'interface se limite à deux fichiers: 1) l'initialisation de la structure des tables 2) un ensemble d'itérateurs sur ces tables. Les tables contiennent des structures C propres à l'appli. Rien d'autre est dépendant de berkeleydb.
Hors ligne
J'aurais bien aimé pouvoir le faire avec postgres, mais je n'ai pas une connaissance suffisante de ses mécanismes internes pour faire ce que j'ai pu réaliser avec berkeleyDb. Ce sont des tables temporaires dont la durée de vie se limite à la requête postgres, qui me permettent de parcourir très rapidement le graphe des offres, et appliquer plusieurs algo de recherche. ...
Les parcours de graphes peuvent être réalisés avec de simples requêtes SQL récursives. La syntaxe normalisée depuis la version 1999 du langage SQL permettant ce type de requête est implémenté depuis la version 8 de PG.
Lisez l'exemple de recherche du plus court chemin que j'ai donnée dans cet article :
http://sqlpro.developpez.com/cours/sqls … ecursives/
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Il n'y a pas de version 8 dans PostgreSQL. La version majeure, c'est toujours les deux premiers nombres. Et dans le cas des requêtes CTE, il s'agit de la 8.4.
Guillaume.
Hors ligne
Merci de l'information, mais les requêtes SQL récursives ne peuvent résoudre à elle seules les questions qui sont traitées, car le module openbarter produit un premier graphe à partir de la base, puis un autre à partir du premier, puis encore un autre pour obtenir les résultats. A chaque phase, il y a un algorithme différent: le premier est depth-first, le deuxième est aussi depth-first, et le troisième une version adaptée de bellman-ford.
Il serais dans doute faisable de coder le tout en plgsql, mais avec les performances d'un langage interprété, et les problèmes de verouillages cycliques propres à la base. La stratégie que j'ai choisi consiste à extraire de la base les données d'entrée (un gros volume), les traiter en mémoire vive indépendamment des mécanismes de la base, et de soumettre les résultats à la base (très faible volume) en vérifiant que ces données ne sont pas obsolètes.
A+
Hors ligne
D'ailleurs je n'ai pas trouvé un tableau de synthèse des fonctionnalités en fonction des versions de postgresql. Sais tu si cela existe ?
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Il y a toujours ça:
http://www.postgresql.org/about/featurematrix
Marc.
Hors ligne
Merci de l'information, mais les requêtes SQL récursives ne peuvent résoudre à elle seules les questions qui sont traitées, car le module openbarter produit un premier graphe à partir de la base, puis un autre à partir du premier, puis encore un autre pour obtenir les résultats. A chaque phase, il y a un algorithme différent: le premier est depth-first, le deuxième est aussi depth-first, et le troisième une version adaptée de bellman-ford.
Il serais dans doute faisable de coder le tout en plgsql, mais avec les performances d'un langage interprété, et les problèmes de verouillages cycliques propres à la base. La stratégie que j'ai choisi consiste à extraire de la base les données d'entrée (un gros volume), les traiter en mémoire vive indépendamment des mécanismes de la base, et de soumettre les résultats à la base (très faible volume) en vérifiant que ces données ne sont pas obsolètes.A+
Bonjour,
très intéressant.
Pour le partie publication/communication, je vous suggère d'en faire une extension utilisable avec CREATE EXTENSION (9.1), puis de la publier sur PGXN. Vous pouvez l'annoncer sur la mailling list pgsql-announce, David Fetter se charge de la news hebdomadaire et vous pouvez aussi lui envoyer un mail en direct (cf archive postgresql pour avoir son mail). Vous pouvez aussi faire une annonce sur la mailling pgsql-fr-generale. (cf postgresql.org pour consulter/ss'abonner)
Utiliser le moteur PostgreSQL ne veut pas dire recoder votre extension en plpgsql, le C est très bien. La question qui demeure est qu'est-ce que berkely DB apporte que n'apporte pas déjà postgresql dans votre contexte. Je n'ai pas lu votre code mais je suppose qu'il suffit de changer le 'backend' berkeleyDB par postgresql, et voilà, non ?
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation
Hors ligne
Bonjour Cédric,
L'extension est portée sur la version 9.1 . Je vais prendre connaissance de CREATE EXTENSION, et suivre tes recommandations.
Merci pour ces conseils.
Hors ligne
Merci de l'information, mais les requêtes SQL récursives ne peuvent résoudre à elle seules les questions qui sont traitées, car le module openbarter produit un premier graphe à partir de la base, puis un autre à partir du premier, puis encore un autre pour obtenir les résultats. A chaque phase, il y a un algorithme différent: le premier est depth-first, le deuxième est aussi depth-first, et le troisième une version adaptée de bellman-ford.
Il serais dans doute faisable de coder le tout en plgsql, mais avec les performances d'un langage interprété, et les problèmes de verouillages cycliques propres à la base. La stratégie que j'ai choisi consiste à extraire de la base les données d'entrée (un gros volume), les traiter en mémoire vive indépendamment des mécanismes de la base, et de soumettre les résultats à la base (très faible volume) en vérifiant que ces données ne sont pas obsolètes.A+
Il est dommage que PostGreSQL n'implémente d'ailleurs pas toute la norme, car par exemple DEPTH FIRST est prévu dans la norme SQL. En sus, sachez que toutes les requêtes dans un SGBDR sont faites en mémoire, avec en sus l'optimisation, ce qui conduit dans les cas de fort volume à des performances au dessus de ce que vous feriez en codage C.
Il est aussi dommage que PostGreSQL contrairement à SQL Server ou Oracle ne soit pas capable de parallélisé une seule et même requête, car là encore les performances du SGBDR deviennent sans communes mesure à ce que l'on peut faire en C, à moins d'avoir prévu de lancer des threads en //
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Je suis conscient du fait que l'optimisation est remarquable, mais à chaque fois qu'une case mémoire est sollicitée, elle est protégée par un sémaphore. Si l'on écrit dans cette case, postgresql enclenche des mécanismes qui peuvent conduire à des blocages cycliques qu'on rencontre fréquemment en parcourant des graphes. Il existe de la littérature sur le sujet dont je pourrais vous retrouver les références. J'excuse donc grandement la décision de ne pas implémenter la norme SQL sur ce point. Les rédacteurs de la norme ont-il étudié la faisabilité de ce qu'ils demandaient? J'ai du utiliser berkeleydb pour m'affranchir de ces blocages.
J'envisage la parallélisation en délégant à des bases miroir la charge d'assurer le fort volume de lecture, et en retournant le petit résultat sur la base maitre en lecture/écriture. La version 9 de postgresql apporte exactement ce qu'il faut pour celà. Comme le goulot d'étranglement est bien souvent la bande passante du disque dur, je ne crois pas que les threads apporteraient grand chose. Avec cette méthode, on exploite les bandes passantes des disques des bases miroir en les ajoutant. C'est le plan, pour le futur, qui nécessiterait de prévoir sur la base maître un module qui déterminerait le miroir le moins chargé. Ce qui n'est pas encore fait.
Hors ligne
DIJXSTRA qui est un pionnier de la théorie de graphes, a été le premier à publier en 1965 un court article sur le sujet:
http://www.dis.uniroma1.it/~baldoni/p569-dijkstra.pdf
Bien d'autres ont ensuite fait référence au problème de fond qu'il a soulevé.
Hors ligne
Marc et Cédric bonjour,
J'ai tenu compte de vos conseils, et suis parvenu à supprimer de l'extension openbarter la bibliothèque berkeleydb qui nécessitait de faire coexister deux systèmes de gestion dynamique de mémoire qui s'ignorent souverainement. La nouvelle version 0.2.0 est publiée sur pgxn. Elle met la clause WITH à rude épreuve pour le parcours ainsi qu'un type nommé flow.
Il reste certainement des choses à ajuster mais la documentation permet aux personnes intéressées par le sujet de s'y plonger et de contribuer au développement sur github. Je vais de ce pas annoncer la nouvelle aux endroits que Cédric m'a indiqué.
Merci de vos critiques bienveillantes.
http://olivierch.github.com/openBarter/
Cdt.
Hors ligne
Bravo pour cette extension !
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Bonjour,
Super travail. Merci beaucoup !
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne
Bonjour Damien et Jean Paul,
Merci pour ces encouragements.
Auriez vous connaissance de la manière de s'y prendre pour proposer une présentation au fosdem sur le sujet?
___________________________
Olivier Chaussavoine
Hors ligne
La proposition doit être enregistrée sur https://www.postgresql.eu/events/callfo … osdem2012/
Guillaume.
Hors ligne
J'ai proposé l'extension à Prague PGConf.EU 2012 comme l'as suggéré Guillaume, mais la proposition n'a pas été acceptée.
L'extension qui fait maintenant l'usage de requêtes récursives - c'est vraiement pratique - a été portée sans problème sur postgreSql 9.2.
Je ne sais vraiement pas m'y prendre avec les questions de communication.
Voilà un exemple: http://olivierch.github.com/openBarter/
Si vous avez des suggestions, elles sont bienvenues.
Hors ligne
Le fait que votre proposition n'ait pas été acceptée à pgconf.eu ne veut pas dire que votre proposition soit mauvaise. Beaucoup de propositions sont envoyées et il faut réussir à choisir les meilleures d'entre elles. N'étant pas dans le comité de sélection cette année, je ne saurais pas dire pourquoi elle ne l'a pas été pour pgconf.eu. Cela étant, il ne faut pas se décourager et proposer de nouveau l'année prochaine si le cœur vous en dit.
Concernant le FOSDEM, il s'agit d'un événement très orienté développeurs. Je vous conseille donc d'orienter votre conférence/proposition pour qu'elle soit intéressante pour des développeurs.
Guillaume.
Hors ligne
Pages : 1
