Journal PostgreSQL: mais que reste-t'il aux grandes ?

Posté par  .
Étiquettes : aucune
0
17
mar.
2006
Un petit article publié aujourd'hui sur PostgreSQL fait état de la migration de huit bases de données allant jusqu'à 180 Go, avec réplication.

http://www.postgresqlfr.org/?q=node/625

Je suis étonné lorsque je discute avec mes collègues du peu de connaissances que les gens ont de cette fantastique base de donnée libre.

Lorsque les gens cherchent une base de donnée libre, ils se tournent généralement vers MySQL, non pas pour des raisons techniques mais essentiellement pour des raisons marketing. La réputation de MySQL classe ce SGBD dans la tranche faible volumétrie et applications non critiques ou annexe. Oracle s'accapare une énorme partie du reste.

Les gens ont rarement étudié une solution basée sur PostgreSQL, ce qui est à mon avis un tord. La base offre un support ACID (Atomicity, Consistency, Isolation, Durability) de première qualité qui permet d'implémenter ses transactions sans soucis. Elle supporte également toutes les fonctionalités que l'on peut attendre d'une base relationnelle complète: triggers, vues, héritage, séquences, procédures stockés, curseurs, type de données définis par l'utilisateur (adresse email...), requêtes sur des requêtes, authentification externe, journalisation des écritures, sauvegarde à chaud, interface avec de nombreux langages. On trouve plusieurs avantages par rapport à Oracle: possibilité d'écrire les procédures dans plusieurs langages: PL/pgSQL qui ressemble beaucoup au PL/SQL d'Oracle, Perl, Python, C, TCL ce qui permet aux personnes qui ont l'habitude d'Oracle de ne pas être trop perdus.

Je l'utilise depuis plus de 8 ans et je suis toujours surpris par le support qu'elle offre. Certains projets qui utilisaient initialement une seule table simple ont pu évolué par l'ajout de triggers et de procédures stockés tout naturellement en fonction de l'évolution des besoins.

Je pense que cette base gagnerait à être plus connue. Et si vous tentiez un essai ?

  • # Va plutot voir du côté des diseurs de bonne aventure.

    Posté par  . Évalué à 9.

    Pas assez chez, mon fils.

  • # Autre article intéressant

    Posté par  (site web personnel) . Évalué à 7.

    Sur les 5 "légendes urbaines" qui ralentissent l'adoption de PostgreSQL : Top 5 Reasons People Dismiss PostgreSQL

    Article : http://searchopensource.techtarget.com/originalContent/0,289(...)

    Commentaires sur /. : http://developers.slashdot.org/article.pl?sid=06/03/14/21122(...)

  • # une question

    Posté par  . Évalué à 2.

    Est-ce que pgSQL sait faire la réplication comme MySQL (voir par ex. http://dev.mysql.com/doc/refman/5.0/en/replication.html) ?
    Est-ce que tu l'as déjà utilisé/teste?


    Je sais, si je ne sais pas c'st que j'en ai pas besoin, toussa .... MAIS SI j'ai besoin et je voudrais savoir si ca fonctionne bien et si c'est difficile a mettre en oeuvre sous pgSQL.

    • [^] # Re: une question

      Posté par  . Évalué à 1.

      C'est absolument pas pour troller, si vous l'interpretez comme ça, je m'ene xcuse, mais est ce que PgSQL supporte es Rollback Segment, est ce qu'une base peux être partagé entre plusieurs.
      Est ce qu'il y a au moins un control file ?

    • [^] # Re: une question

      Posté par  . Évalué à 2.

      Je suis actuellement chez France Telecom. Pour le développement d'une application, nous avons étudié les fonctionnalités de réplication respectives de pgsql et mysql. Voici ce qu'il en est ressorti :
      - la réplication est gérée nativement par mysql (et fonctionne particulièrement bien, avec des temps de propogation d'une modification très inférieurs à la seconde, propogation des modifications du schéma de base, etc.) ;
      - la réplication est gérée par un projet externe en ce qui concerne pgsql. Ce projet, slony, n'est pas nécessairement complexe à mettre en place, mais fonctionne nettement moins bien que le système de réplication de mysql. Il est notamment beaucoup plus long à propager les changements (à machines identiques), et ne propage pas les modifications du schéma (toujours désagréable pendant les phases de développement).

      Au final, nous avons choisi mysql, essentiellement pour cette raison.

      Just my 0.02¤

  • # j'vais dire un gros mot...

    Posté par  (site web personnel) . Évalué à 2.

    Au taf, on a des serveurs sous linux et d'autres sous windows, les outils que l'on utilise tournent généralement sur l'un ou l'autre (pour éviter d'avoir à apprendre des outils spéciaux pour l'un et d'autres pour l'autre OS)

    python, Java, Oracle, MySQL...

    Je crois que PG ne tourne pas sous NT... Sinon j'aurais bien tenté de leur faire utiliser...

    Axel

  • # Mon avis personnel sur la question

    Posté par  . Évalué à 3.

    Mon avis personnel sur la question :

    - Il n'y a pas de vrai réplication sur PostgreSQL, slony n'est qu'une sorte de bidouille sur les procèdures stocké. ça marche, ça marche même surement bien mais cela reste une surcouche. De plus, il y a des contraintes d'index/primary key de tables que n'a pas la réplication sous MySQL.
    - Mettre en place une réplication sur un serveur MySQL est BEAUCOUP plus simple que sur un PostgreSQL
    - Les fonctionnalités avancés transforme rapidement la base en unité monobloque qu'il est ensuite difficile de fractionner afin, par exemple, de répartir la charge (execpté si l'on a rigoureusement prévu ce cas avant, mais c'est rarement le cas).
    - Il faut d'avantage voir les triggers et autres procédures stocké comme une différenciation de contrôle et de gestion des données en base plutôt que dans le code. ça a ses avantages et ses inconvénients (clustring, fragmentation, etc).
    - PostgreSQL 8.1 à des fonctionnalité qui déchires (journalisation des logs, posibilité de réinjection dans une base de secours avec des délais pouvant atteindre la minute).
    - Pour de la donnée brute necessitant peu de traitement et de contrôle, MySQL demeure à mon avis le meilleur choix.

  • # L'argent

    Posté par  . Évalué à 1.

    ça fait pas le bonheur, mais ça y contribue.

    D'un côté, dire, je m'appelle M. Oracle, et avec toute ma thune de mormon, je me porte garant que mon système il a beau être relou et pas beau et dinausoresque, il est robuste, et que toute ta compta ou tes bdd clients elles vont pas partir en fumée, c'est quelque chose que sur lequel le libre est pas encore aussi "concurrentiel"

    • [^] # Re: L'argent

      Posté par  (site web personnel) . Évalué à 2.

      je ne suis pas persuadé de cela
      ce qui manque c'est surtout un bon marketing,
      parce qu'en ce qui concerne les offres de support et de garantir des temps d'intervention et la fiabilité des données, les sgbd libres sont bien armés
      par exemple une boite comme l'opérateur téléphonique canadien Distributel gère toutes ses données (y compris les autorisation d'accès à son réseau, les logs des connexions) soit en gros 2.000.000 d'appels par jour plus leur support client dans un SGBD open-source mais avec un contrat de support avec une entreprise spécialisée.
      Il faut préciser qu'ils n'ont droit qu'à une erreur tous les 100.000 appels.

      Donc c'est bien de poster des infos comme celle ci, en rencontrant plusieurs fois les gens de PostgreSQLfr, nous arrivons au même constat, les boites qui utilise nos produits ne le font pas assez savoir, si nous arrivions à faire des livres blanc comme PHP l'a fait, la commmunication des produits SGBD libres s'améliorerait grandement. Il faut donc aussi convaincre toutes ces entreprises d'adhérer aux différentes associations ou fondation que ce soit PostgreSQLfr ou la Fondation Firebird, ce sont des bons moyens de promotion.

      • [^] # Re: L'argent

        Posté par  . Évalué à 0.

        hum... j'avoue, gérer une base de données de taille moyenne (> 500 go) autrement qu'avec Oracle, et pour une utilisation "réelle" (cad hors bench TPC), je n'y crois pas trop...

        qu'on me démontre le contraire !!!

        Plus grosse base de données en 2005: 100 To, Yahoo
        -> Oracle

        • [^] # Re: L'argent

          Posté par  . Évalué à 2.

          je n'y crois pas trop...
          qu'on me démontre le contraire !!!
          C'est toi qui y crois pas. C'est a toi de démontrer pourquoi tu n'y crois pas, pas le contraire !

        • [^] # Re: L'argent

          Posté par  (site web personnel) . Évalué à 1.

          rigolo va ;)

          parce que tu crois que c'est uniquement la taille qui justifie telle ou tel SGBD ?

          mais bon que crois tu que SAS utilise ?
          Vulcan qui n'est autre que Firebird modifié et qui va devenir Firebird 3
          Que crois tu qui est utilisé à la bourse de Moscou pour gérer tous les échanges de titres ?
          tiens Firebird

          mais bon SAS et la salle des marchés de Moscou doiven gérer des bases naines et sans importance.

          De toute façon le marché des SGBD ne commence pas à 500 Go, loin de là

  • # C'est aussi une question de compétences ...

    Posté par  . Évalué à 2.

    Au taff, on a eu un dilemme sur le choix de la base de donnée libre à utiliser pour un projet de régionalisation des donnés du centre d'appel (un gros truc quoi). Et là deux choix sérieux: Postgres ou Mysql. Postgres est effectivement beaucoup + mammouth que Mysql (quoique l'écart se ressert) mais peut-être trop mammouth en fait:

    - pour faire tourner un Mysql, on l'installe, on le démarre, on utilise un des nombreux gui (PhpMyAdmin, Mysql Browser, Sql Yog, MysqlFront, ...) on se connecte avec root sans mdp et on commence

    - pour PG, on installe d'abord un linux (plus maintenant heureusement), on installe l'appli, on configure les droits d'accès dans les fichiers de config (pg_hba.conf) , on cherche un gui sur le net, on en trouve que très peu (PhpMyAdmin, PGAdmin, ...), on tente de se connecter, on essaie de comprendre la notion de schéma, ... bref pour quelqu'un qui s'y connait peu, on galère.

    Postgres mérite effectivement d'être connu mais souffre d'être trop bien (c'est tout de même incroyable, pour une fois qu'un soft libre est aussi abouti !!!) et dans une équipe de développement où tout le monde n'a pas la compétence dba, il faut essayer de faire simple et efficace. Et là, on tombe totalement dans le crénau de Mysql.

    Mais c'est promis, on va faire des essais sur ce sgbd pour notre prochaine maquette ;-)

    • [^] # Re: C'est aussi une question de compétences ...

      Posté par  (site web personnel) . Évalué à 2.

      on cherche un gui sur le net, on en trouve que très peu (PhpMyAdmin, PGAdmin, ...)

      Tu as oublié SQLmanager de EMS (non libre) :
      http://sqlmanager.net/fr/products/postgresql/manager
      (existe aussi pour MySQL et SQL*server)

    • [^] # LAMP

      Posté par  . Évalué à 3.

      cela peut être un faux problème, mais je pense aussi qu'il y a le fait que la plupart des serveurs des fournisseurs d'accès (free et compagnie) tournent avec php, mysql, apache...
      Ainsi si je dois faire mes premières armes en base de données, je vais me tourner vers ce qui est le plus répandu (les 3 sus nommés), même si d'autres solutions semblent alléchantes. C'est un cercle vicieux (ou vertueux, selon le point de vue)

      Ces solutions libres alternatives méritent sans doute que l'on s'y penche également.

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

    • [^] # Re: C'est aussi une question de compétences ...

      Posté par  . Évalué à 5.

      Juste une question (pas méchante, hein !) : "un gros truc quoi" puis "on essaie de comprendre la notion de schéma" et enfin "pour quelqu'un qui s'y connait peu"...
      Ma question bête : euh, là, justement, si c'est "un gros truc", est-ce qu'on est pas dans un cas où il faudrait faire appel à quelqu'un qui s'y connait ?!! La BDD, c'est quand même un métier, ce n'est peut-être pas *tout à fait* pour rien ! (je dis ça, mais je bidouille de la BDD et ce n'est ni mon job, ni ma formation ;-))
      Il y'a de très nombreuses notions qui demandent au moins un peu d'expérience... J'en découvre personnellement tous les jours, et plus ça va, plus je me dit "je n'aurais pas pensé que c'était aussi complexe, qu'il y'avait autant de choses à penser avant même de commencer à choisir un SGBD".

      Sinon, la notion de schéma n'est pas une spécificité de PG, loin de là ! Toutes les grosses BDD la contiennent !

      Vala !

      • [^] # Re: C'est aussi une question de compétences ...

        Posté par  . Évalué à 3.

        Tout ce que je lis est bel et bon, mais je rejoins l'avis de ceux qui pensent que pour une "grosse" BdD (pas en taille, en complexité), il faut une "grosse" artillerie.

        Selon moi (évidemment ;-)
        MySQL: très bien pour les bases "simples", quelle que soit la volumétrie
        PostgreSQL: C du sérieux: héritage, schéma, et surtout contraintes d'intégrité référentielle, procédures stockées ...
        Quand j'ai regardé (au temps des dinosaures, mysql 3xx) qu'on se paluche à la main dans l'appli les contraintes d'intégrité, j'ai halluciné !

        Et puis, je connais mes développeurs: ils installent un easyphp, "jouent" dessus, et pensent que je vais passer en prod leur jouet ! "Mais si, c'est simple, t'as qu'à installer easyphp sur le site web, et Youpi ! Quoi, c'est quoi cette histoire de mot de passe ? Tout le monde n'est pas admin ? Mais non, ils vont pas faire de quoi déjà, sql injection. Et puis, s'ils sont pas admin, ils font comment pour ajouter un enregistrement les users, Haha !!" (sob)

        Comme toujours, un projet, ça s'analyse. Je suis pour MySQL sur des trucs de sa complexité (en pensant malgré tout à l'aspect exploitation), et sur des machins "complexes" comme PostgreSQL là où s'est nécessaire.

  • # Réponse facile a donner...

    Posté par  (site web personnel) . Évalué à 0.

    Tu te pose la question? pfff... C'est trop simple.
    Dans le desordre :
    - http://www.postgresql.org/download/ , j'y comprend rien. http://dev.mysql.com/downloads/mysql/5.0.html , j'y comrpend quelque chose.
    - MySQL, je peux m'y habituer tranquillement sous ma machine Windows au bureau (celle qu'on m'iumpose, j'ai pas le choix, c'est la seule sur laquelle je peux installer des hcoses sans faire une demande compliquée), je fais une maquettte, je la presente. C'est accepté, j'achette une grosse machine sous Linux, j'ai la flemme de redevelopper / valider, je prend la meme config : Apache + MySQL.
    - Un ami qui travaille avec de grosses (pas complexes, grosses), a mis en place la réplcation en peu de temps, alors qu'avec PostgreSQL...

    Bref, pour resumer, si tu as besoin d'un concurent a Oracle, oui PsotgreSQL est super. A part ca (99% du temps, meme sur de gros sites), MySQL est genial pour maquetter et installer.
    MySQL repond au besoin de la masse, contrairement a celui que tu adores, c'est tout.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.