En poursuivant votre navigation sur ce site, vous acceptez nos CGU et l'utilisation de cookies afin de réaliser des statistiques d'audiences et vous proposer une navigation optimale, la possibilité de partager des contenus sur des réseaux sociaux ainsi que des services et offres adaptés à vos centres d'intérêts.
Pour en savoir plus et paramétrer les cookies...

PostgreSQL, meilleure base de données open source

PostgreSQL, meilleure base de données open source
 

01net. et Novaforge ont comparé, avec l'aide d'un jury d'experts, cinq bases de données open source. Le meilleur choix pour l'entreprise est PostgreSQL, suivi de MySQL.

Inscrivez-vous à la Newsletter BFM Business

Newsletter BFM Business

A voir aussi

Votre opinion

Postez un commentaire

18 opinions
  • Céou
    Céou     

    Moi je ne le vois même pas le sommaire du comparatif. Et je suis pas aveugle pourtant.

  • Guillaume Smet
    Guillaume Smet     

    Bonjour,

    Oulala non. PostgreSQL n'est pas un produit de Sun. PostgreSQL n'appartient à aucune société mais au PGDG (PostgreSQL Global Development Group) qui comprend des personnes de tous horizons, des gens sponsorisés par des sociétés, des gens qui font ça pour leur plaisir.

    A l'inverse des autres SGBDR Open Source (MySQL, Firebird, Ingres), il n'y a pas d'éditeur de PostgreSQL mais bien un "écosystème" composé notamment de Red Hat, EnterpriseDB, 2nd Quadrant, Command Prompt, Sun, Skype, Conova, Credativ, Fujitsu, NTT, OmniTI et, en France, des implications de sociétés comme CS, Dalibo, JFG Networks (qui édite OverBlog) ou Open Wide. J'en ai probablement oublié beaucoup et je n'ai cité que des sociétés et pas tous les gens impliqués à titre individuel. Désolé pour ceux que j'aurai oublié.

    Sun est impliqué dans PostgreSQL mais représente vraiment une petite part (de mémoire 1 porte drapeau + quelques personnes impliquées sur des benchmarks et du support + du sponsoring de conférences). Cette implication n'a pas changé depuis le rachat de MySQL (ils ont même réembauché un autre porte-drapeau, Peter Eisentraut, suite au départ de Josh Berkus qui a eu lieu quelques temps après le rachat de MySQL).

    Conclusions :
    - pour l'instant, l'implication de Sun dans PostgreSQL n'a pas bougé d'un poil. Après, il est difficile de savoir si ça va rester comme cela mais il n'y a pas eu de signe de désengagement pour l'instant ;
    - PostgreSQL n'est pas du tout dépendant de Sun et si Sun se désengage, ça n'aura que peu de conséquence sur le développement de PostgreSQL lui-même ;
    - l'histoire de PostgreSQL a montré qu'il y avait parfois des grosses réorganisations (la fermeture de Great Bridge qui était un des très gros sponsors de PostgreSQL à l'époque, par exemple, il y a quelques années) mais que l'écosystème lui-même est globalement en développement malgré ces aléas.

    De manière assez amusante, le rachat par Sun de MySQL a conduit aussi à la naissance d'un écosystème assez similaire autour de MySQL et à moins de concentration chez l'éditeur. C'est encore naissant mais ça semble être une vraie tendance.

    --
    Guillaume

  • Le Galou
    Le Galou     

    Ça fait environ 3 ans que Sun supporte PostgreSQL. Jusque là PostgreSQL n'avait pas eu besoin de Sun pour être le meilleur SGBD du marché "Open Source". Si Sun ne fait plus de support, l'équipe continuera à avancer et conservera sa longueur d'avance. En fait, ça ne change rien !
    En plus, l'organisation du développement de MySQL connaît quelques difficultés, ça ne va donc pas aider les équipes de développement à avancer...

  • mhausherr
    mhausherr     

    PostgreSQL et MySQL sont actuelement des produits de Sun Microsytem. Or la politique officielle de SUN est de ne plus supporter PostgreSQL. Aujourd'hui la seule équipe qui continue à travailler sur PostgreSQL et c'est celle d'OpenSolaris. Il y a bien sûr toujous la communautée mais il est plus propable de voir des avancées majeures dans MySQL pour les prochaines années.

  • ConsultDba
    ConsultDba     

    Oracle Express l'est.
    Mais ces fonctionnalité le sont moins !

  • ConsultDba
    ConsultDba     

    Pas convainquant effectivement car aucune donnée fiable et mesurable n'est donnée a titre d'exemple.
    Pourquoi des sujets comme le
    mecanisme de lock, l'optimisation statististiques, la replication, la haute disponibilité, le backup online, le type de base utilisée (oltp 24h/24 ou batch), la volumétrie, le temps de recovery en cas de crash, le type de console de monitoring, l'aspect securité et pour finir les OS qui ont servi pour les tests, ne sont ils pas mentionnés ?
    Combien de clients utilisent des bases "Open" pour leur production quotidienne (pas icommerce ou web) ?,
    Le taux d'incident de production par base par an serait interessant a connaitre egalement.
    Le ROI pourrait être également démontré.
    Bref guère convaincu par cet article.
    Il aurait été plus honnete de dire que le choix d'une base de donnée est avant tout dicté par des aspects financiers plutot que techniques a charge ensuite aux DBAs de se débrouiller ...

    Senior DBA Oracle,Mysql SqlServer.

  • Guillaume Smet
    Guillaume Smet     

    Bonjour,

    Pour ce qui est des performances d'Oracle, c'est difficile à dire car il n'est pas possible de publier de benchmark sans la permission d'Oracle. C'est clairement un des fleurons du marché et elle a des fonctionnalités qu'aucun autre SGBD n'a.

    La version Express ne rentre pas dans ce comparatif car elle n'est pas open source. Elle est, par ailleurs, extrêmement limitée :
    "XE will store up to 4GB of user data, use up to 1GB of memory, and use one CPU on the host machine"
    (directement du site d'Oracle), ce qui rend son utilisation en production hasardeuse.

    --
    Guillaume

  • Guillaume Smet
    Guillaume Smet     

    Bonjour,

    Avant toute chose, la synthèse faite pour chacune des produits ne joue pas vraiment sur les notes. La notation s'est faite de manière beaucoup plus détaillée.

    Je pense que l'auteur a choisi de mettre en avant les outils d'administration PostgreSQL dans la synthèse car PostgreSQL traîne toujours une image de SGBDR complexe à administrer alors que ce n'est plus le cas depuis très longtemps. D'où le petit focus sur ce point.

    Si c'est la phrase "Les outils pour administrateurs se révèlent parfois un peu limités." qui vous chagrine, elle ne parle pas des outils type PHPMyAdmin ou du client lourd - qui sont effectivement très bien -, j'y reviens plus bas dans les explications détaillées.

    Pour ce qui est des versions de MySQL et PostgreSQL dont on a discuté, il s'agit bien des versions 5 et 8.3 - les versions stables de quand on a fait ce comparatif. La 5.1 n'était pas sortie quand on a travaillé sur ce comparatif et vu son cycle de release un peu chaotique, on n'avait pas trop d'idée de si elle allait sortir bientôt. Et même si on prenait la 5.1 maintenant, je ne pense pas que cela changerait grand chose.

    Par ailleurs, je ne vois pas trop en quoi ce que vous dites contredit la notation qui a été faite. Il y a plein de gens qui sont contents de MySQL pour l'usage qu'ils en font, de même qu'il y a plein de gens satisfaits par PostgreSQL/Firebird/Ingres/Oracle/... Le fait que l'outil réponde à vos besoins ne veut pas dire qu'il est parfait (et c'est valable pour toutes les bases de données du comparatif, PostgreSQL 8.3 a ses points faibles également - réplication pas intégrée, partitionnement pas top du tout).

    Je vais détailler les points où MySQL est en dessous de PostgreSQL (ça reste ma vision des choses, ça n'engage pas les autres membres du jury).

    - Communauté (4.5 au lieu de 5) : communauté trop contrôlée par l'éditeur et pas assez ouverte. Ca commence à s'ouvrir avec l'arrivée de Drizzle et le départ de Monty Widenius. Le contrôle par l'éditeur et sa visibilité ont par contre amené le 5 sur la partie Offres commerciales

    - Fonctionnalités (4 au lieu de 5) : manque de cohérence et finition de certaines fonctionnalités, vision des standards SQL parfois créatives, des fonctionnalités en moins mais aussi des fonctionnalités en plus mais pas toujours disponibles sur tous les moteurs.

    - Robustesse (4 au lieu de 5) : problèmes de corruption avec MyISAM - ah, les REPAIR TABLE..., quand même pas mal de bugs (et même le créateur de MySQL a fait un article assez polémique sur la sortie de la 5.1 et il est encore plus critique par rapport à la 5 - http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html ). L'objectif du fork Drizzle était aussi d'alléger et de fiabiliser MySQL et de revenir à ses fondamentaux. Clairement, il y a plein d'installations de MySQL qui marchent mais la robustesse, ça ne se mesure pas au "chez moi, ça marche". Et l'avis général, l'expérience des différents intervenants et même l'avis des gens qui travaillent sur MySQL est plutôt cohérent avec notre notation.

    - Documentation (4.5 au lieu de 5) : ça reste subjectif mais je la trouve beaucoup beaucoup moins clair que la documentation PostgreSQL et la recherche moins pertinente. Ce qui est purement objectif, c'est ce dont je parlais dans un autre post : le regroupement de la documentation de toutes les anciennes versions en une. Ce n'est clairement pas acceptable : quand on se retrouve à remanipuler des MySQL 3.23 - oui, ça arrive -, ça devient vite sportif.

    - Administration (4 au lieu de 5) : au niveau diagnostic suite à des problèmes d'exploitation, il y a encore des lacunes (ex : le slow_query en seconde, c'est vraiment vraiment très pénible : des gens ont même fait un patch pour ça). Il arrive régulièrement qu'on prenne en main une base MySQL et qu'on ait du mal à comprendre la raison des lenteurs parce qu'on ne peut pas descendre en dessous de la seconde alors qu'on a beaucoup de requêtes qui s'exécutent en 500 ms. Les outils de dump et de restauration sont également moins avancés. Les capacités de sélection de bases/schémas/tables lors du dump et même lors de l'import sont beaucoup plus avancées côté PostgreSQL. Plein de petites choses auxquelles on s'habitue très très vite et dont on a bien du mal à se passer. L'outil en ligne de commande (psql) est également beaucoup mieux pensé et beaucoup plus agréable à utiliser (et ça reste un des moyens d'administration très courant).

    - Utilisation (4.5 au lieu de 5) : on parle ici de l'utilisation par les développeurs. Mon principal souci à ce niveau est le manque de détail du EXPLAIN pour analyser les plans d'exécution. Sur des requêtes complexes, c'est vraiment très très pénible. PostgreSQL, comme Oracle, propose des plans d'exécution beaucoup beaucoup plus lisibles.

    - Déploiement (4.5 au lieu de 5) : gros souci sur

  • Thibaud59000
    Thibaud59000     

    Des auteurs avec de l'expérience sur MySQL l'aurait mis en tête alors ?

    Je voudrais quand même vous rappeler que MySQL obtient 4,5/5 juste derrière PostgreSQL (5/5) ce qui en somme veut dire que c'est un bon produit également.
    Tout ce que tu dis faire avec MySQL confirme sa bonne qualitée. Ce qui n'enlève rien à PostgreSQL.

    Pour moi ce test confirme ce que j'avais déjà expérimenté moi même : PostgreSQL possède plus de fonctionnalités et est plus robuste que MySQL (même version 5). Nous utilisons PostgreSQL que lorsque MySQL ne fournit pas ce dont nous avons besoin.

  • freeben
    freeben     

    Les arguments cités dans cet articles ne sont pas fondés. Par exemple les auteurs mettent en avant un outil bien pratique pour PostgreSQL : pgAdmin ; et bien il existe le même (voir en mieux !) pour MySQL : MySQL Administrator (appli desktop) ; De plus, il manque les numéro des versions testées (y-a-t'il réellement eu test ??) car il y a eu beaucoup de différences entre un MySQL 4 et 5 (idem entre PostgreSQL 7 et 8...) notamment au niveau "robustesse" ;
    Je travaille pour une très grosse SSII et nous optons depuis longtemps pour MySQL, qui gère plusieurs millions de lignes dans des bases en cluster de plusieurs téra de données ; rien n'est dis concernant l'usage fait des bases (volumétrie, clustering, montée en charge, etc...)
    Bref je trouve ça trop light : en fait on se base sur l'expérience et non sur des tests réels (à mon avis les auteurs manquent d'expériences sur MySQL...)

Lire la suite des opinions (18)

Votre réponse
Postez un commentaire