Tout semble donc bien aller dans le petit monde de MySQL. Certes la nouvelle version s'est faite attendre et ce n'est qu'une version intermédiaire avant le grand saut de la version 6.0 (qui sera basée sur Falcon) mais après tout une base de données est un composant critique et il vaut mieux prendre le temps de proposer un produit stable. Même si cela prend plus de trois ans.
L'ennui se situe justement là. Selon un article posté sur le blog du créateur de MySQL (Michael Widenius) cette version est bourrée de bugs critiques !
NdM : Détails dans la suite de la dépêche. Merci à patrick_g pour son journal à l'origine de celle-ci.. LinuxFr.org utilise MySQL 5.0 au moment de la publication de cette dépêche. Alors que la 5.1 n'est qu'une version « d'attente » de la 6.0 et qu'elle doit donc ne proposer que des nouveautés sans risques et traquer les bugs c'est le contraire qui est constaté par M. Widenius. On trouve dans son post des phrases comme :
- Ne vous attendez pas à ce que tous les bugs critiques que vous aviez rencontré dans la 5.0 soient corrigés dans la 5.1.
- Si vous projetez d'utiliser les nouveautés de MySQL 5.1 alors considérez ces fonctions comme étant en qualité béta.
- Nous avons encore 20 bugs connus provoquant des crashs et des résultats erronés dans la 5.1. Et 35 bugs de plus si on ajoute ceux de la 5.0 qui doivent toujours être présents dans la 5.1. Nous avons également encore plus de 180 bugs sérieux (P2) dans la 5.1.
- Concernant les nouveautés si vous avez un crash d'une table partitionnée alors il est très difficile (parfois impossible) de la réparer.
- Si vous avez un crash serveur pendant un ALTER TABLE sur une table partitionnée alors vous pouvez perdre toutes les données de cette table.
- Le log dans les tables est si lent (-30%) que la fonction est inutilisable pour les sites chargés.
Widenieus ne critique pas Sun et il déclare même que la faute revient exclusivement au management de MySQL. La seule faute de Sun serait de ne pas avoir changé l'organisation pour corriger les dysfonctionnements. Il plaide finalement pour un mode de fonctionnement « proche de celui de postgreSQL où la communauté a un rôle moteur dans ce qui est fait et décidé ».
Aller plus loin
- Journal à l'origine de la dépêche (5 clics)
- MySQL (3 clics)
- Heise Online : article listant les principales nouveautés (64 clics)
- Critiques de la version 5.1 par Michael Widenius (58 clics)
- Falcon (44 clics)
# haha
Posté par Julien . Évalué à 10.
[^] # Re: haha
Posté par patrick_g (site web personnel) . Évalué à 6.
Comme le dit Monty Widenius il suffit sans doute d'attendre un peu et de ne pas se précipiter tout de suite sur la 5.1 : "It may even be the best to wait for a couple of minor/patch releases before putting the MySQL 5.1 server into production."
Là ou ça va être critique c'est pour le passage à la 6.0. C'est là qu'on va voir si MySQL à un avenir assuré face à PostgreSQL ou pas. Si Sun se rate sur la 6.0 ça peut faire très mal.
[^] # Re: haha
Posté par Raoul Volfoni (site web personnel) . Évalué à 6.
Une infrastructure basée sur MySql n'est pas franchement ce qu'il y a de plus stable. C'est peut-être un outil convenable pour un site comme dlfp où personne n'ira se plaindre en cas de crash, mais ce n'est certainement pas un sgbd qui a sa place en milieu critique. Et cette dépêche ne fait que confirmer mon opinion sur ce produit que j'ai toujours trouvé bancal. (Je bosse avec des sgbd depuis plus de 20 ans ce n'est donc pas un jugement à l'emporte-pièce même si j'ai la flemme de développer mon argumentation).
Alors oui, migrer vers PostgreSQL est la meilleure chose à faire pour ceux qui veulent un véritable sgbdr libre qui soit digne de ce nom.
[^] # Re: haha
Posté par herodiade . Évalué à 10.
> C'est peut-être un outil convenable pour un site comme dlfp où personne n'ira se
> plaindre en cas de crash,
C'est ça.
Sauf que tout les gros LAMP à forte progression / populaires utilisent MySQL lorsqu'ils n'utilisent pas une techno proprio : Youtube, Slashdot, Wikipedia, Flickr, Linkedin, Livejournal, Twitter, Facebook, Digg, Mixi, Yahoo Finance, ...
C'est sans doute parce que les admins de ces sites sont des dilettantes mal informés et ne lisent pas assez les trolls velus des pg afficionados sur dflp.
PostgresSQL a ses (gros) avantages, comparé à MySQL, mais il a aussi des défauts critiques pour certains besoins.
[^] # Re: haha
Posté par Jerome Alet (site web personnel) . Évalué à 0.
> critiques pour certains besoins.
Peux tu élaborer ?
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . Évalué à 10.
1- la réplication via log shipping qui n'est pas intégré (nécessité de scripts externes). Ceci dit, elle est par contre beaucoup plus stable que la réplication MySQL par log shipping ;
2- impossibilité d'accéder en lecture au slave dans le cas de réplication par log shipping ;
3- quelques requêtes type le SELECT COUNT(*) FROM table qui sont lentes comparées à du Oracle (MyISAM ne compte pas vraiment à cause du table locking et le fait que ce ne soit pas MVCC et InnoDb a le même problème que PostgreSQL) ;
4- le fait que la locale et l'encoding soient globaux et par par colonne ;
5- le partitionning vraiment vraiment pas top.
Beaucoup de ces points vont être améliorés par le travail fait sur la 8.4 (en tous les cas, si tous les patches en attente sont intégrés) :
- les points 1 et 2 ont des patches en attente ;
- le point 3 devrait bénéficier du travail sur la visibility map fait en 8.4 mais ne sera pas résolu avant la 8.5 au moins ;
- le point 4 est très partiellement traité : on pourra avoir une locale par base de données ;
- le point 5 n'a pas vraiment bougé (il y a eu du boulot de fait mais je ne pense pas que ce sera intégré).
Ca n'empêche pas PostgreSQL d'être mon SGBDR de prédilection mais il faut aussi être au courant de ses points faibles pour l'apprécier pleinement.
[^] # Re: haha
Posté par herodiade . Évalué à 6.
(disclaimer, je parle en tant qu'admin, pas développeur).
AMHA la réplication est effectivement un gros point faible de PostgreSQL. Et il est clair que la roadmap de 8.4 montre que les développeurs prennent les choses en main et ne jouent pas à l'autruche (c'est toujours la différence avec les fanboys ;).
Qu'elle ne soit pas intégrée dans les sources standards de PostgreSQL n'est vraiment pas le problème cependant. Outre le cout (en ressources et en entretien) des outils de réplication basés sur des triggers (autant dire, du bricolage) à la Slony ou Londiste, l'aspect bizantin de la mise en œuvre, il faut bien dire que les fonctionnalités sur ce point sont vraiment à la traine, et c'est vraiment un show stopper pour certains utilisations. Quelques exemples de ce que MySQL fait, que j'adorerai voir dans PG rapidement (et explication des cas d'utilisation) :
* La réplication master-master (avec garantie d'autoincrements, pour les pk, uniques par noeud) : fort utile our une architecture HA qui permette un "scale out" (qui permet d'augmenter les performances et la disponibilité en ajoutant des serveurs "moyens" plutôt qu'en étant bloqué sur un seul serveur maitre très puissant). À mon avis ceci (avec les possibilité de sharding) est une des raisons de l'utilisation fréquente de MySQL pour des applications web à forte croissance. Dans le web, où l'argent arrive souvent au compte goutte au fur et à mesure du succès, et où l'utilisation peut grossir très soudainement, pouvoir augmenter les capacités au fur et à mesure des besoins avec des machines bon marché est critique (à l'opposé par ex. d'un système bancaire dimensionné selon les besoins dès le départ).
* La réplication délayée : où les slaves récupèrent bien les mises à jour sur le master, mais ne les appliquent aux bases qu'après un délai définis par l'utilisateur. Si une application bugguée, une erreur de manipulation de maintenance, un piratage, etc. venait à corrompre les données sur la base master, il suffit de switcher les applicatifs sur un slave et de demander à celui-ci d'appliquer illico les mises à jour en attende jusqu'à celle qui a causé des pertes. D'une certaine manière, c'est une assurance contre la perte des données à cause humaine. Pour certaines applications (en tout cas chez moi), perdre toutes les données modifiées depuis le dernier snapshot/backup (quotidien, dans mon cas, car mes bases sont très grosses) c'est mettre la clef sous la porte.
* Et toutes ces petites choses qui simplifient la vie, qui manquent à pg, et sont certainement dues au fait que la réplication est native de longue date : le support du SSL (y compris de l'auth des slaves par certificat X.509), la possibilité d'initialiser la réplic sur un slave à partir de l'import d'un dump (si dumpé avec l'option "--master-data"), la possiblité de faire du daisy-chaining (replication A -> B -> C -> A), la simplicité et rapidité de mise en place, le fait qu'on puisse demander de répliquer toutes les bases (ou bien une base complète) et que les ajouts/drops/changements de tables soient naturellement répliqués sans qu'on intervienne, ...
Je ne l'ai pas encore essayé, mais il y a désormais (5.1) un mode de réplication mixte (statements et row based) qui permet à MySQL de décider ce qui sera optimal niveau perfs et bp (la réplication par statements oblige parfois mysqld à joindre des infos complémentaires en commentaires dans les binlogs répliqués pour que les slaves puissent appliquer ces statements de façon identique (ie. résultats des fonctions comme NOW(), RAND(), etc.)).
Un autre choix pertinent de MySQL (important dans certains cas) est l'utilisation, pour les bases InnoDB d'un cache des rows en RAM. Le cache disque généraliste du noyau est *beaucoup* moins efficace (parce qu'il est aveugle et met en cache des choses qui ne nous intéresseront pas, parce qu'il n'est pas très déterministe et peu se vider d'un moment à l'autre, parce qu'y accéder oblige à construire et scheduler une requète block complète,...). Les performances en lecture s'en trouvent considérablement améliorées.
Il y a en revanche des choses que je deteste dans MySQL, *en tant qu'admin*, comme le fait que les alter sont appliqués immédiatement (transaction ou pas, le rollback ne rendra pas l'état initial). Les tablespaces assez peu pratiques par rapport à PostgreSQL, du moins lorsqu'on veux distribuer la charge sur plusieurs arrays (et MySQL ne permet pas de déplacer physiquement une table à chaud, c'est souvent handicapant pour moi), le fait que les performances de MySQL ne progressent plus au-delà de 8 cpus, ...
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . Évalué à 7.
C'en est un, en fait. Il faut vraiment que ça marche out of the box sans avoir à scripter des trucs (même si plusieurs scripts existent mais c'est déjà un problème en soi : lequel choisir).
Ca ne pose pas de souci aux gens qui ont l'habitude mais ça rend cette fonctionnalité peu accessible alors qu'elle est simplissime et très robuste.
"La réplication master-master"
Mouaif. La réplication master-master pose énormément de problèmes en soi et MySQL n'est vraiment vraiment pas un modèle du genre... Clairement, il ne faut pas espérer voir arriver ça dans PostgreSQL avant très très longtemps (si ça arrive un jour).
Au delà de la fiabilité, le moteur NDB induit tout un tas de limitations que je trouve inacceptable.
"La réplication délayée"
Mauvaise réponse au problème. Tu tomberas toujours dans le cas où, pas de bol, ton délai n'était pas suffisant. PostgreSQL répond à ce problème avec le Point In Time Recovery : tu indiques simplement le moment où tu veux t'arrêter dans le "rejouage" des logs. C'est *beaucoup* plus fiable.
"les ajouts/drops/changements de tables soient naturellement répliqués sans qu'on intervienne"
C'est déjà le cas dans la réplication via log shipping. Evidemment le fait que le slave ne soit pas accessible en lecture pour l'instant le limite au failover. J'espère que cette limitation sera levée en 8.4.
Slony n'est clairement pas un modèle du genre de simplicité et il est, à mon sens, assez difficile à imposer en dehors du cadre de sa propre boîte (typiquement, je ne le propose pas au client dont on exploite les plates-formes).
Personnellement, je vois pas mal d'admins MySQL se plaindre de l'instabilité de la réplication via log shipping.
Clairement, un hot standby est suffisant pour 99% des besoins et je préfère très largement avoir un failover très fiable qu'un truc bancal qui me permet de faire du readonly sur un autre noeud. Note bien que je suis d'accord que c'est limitant pour certains besoins, juste que je préfère des fondations solides, ça se casse moins souvent la gueule :).
Pour l'histoire du cache disque, c'est l'argument qu'on entend souvent. Je dois avouer qu'on voit assez peu de cas où ça pose réellement un problème. Clairement, PostgreSQL se focalise sur faire du SGBDR, pas sur faire un OS au dessus de l'OS. Ca a parfois un coût, tout le monde en convient, mais c'est finalement assez sain.
Sinon, tu es gentil sur le "les performances de MySQL ne progressent plus au-delà de 8 cpus", j'ai vu plus de benchs où ça s'écroulait dès que le nombre de CPU et le nombre de connexions augmentaient et je vois encore souvent des bases en production en 5.0 qui n'utilisent qu'un core sur 4 malgré une configuration correcte. Le fait de ne pas avoir sorti de version en 3 ans (et donc de ne pas avoir pu s'adapter à la nouvelle mode des multi-cores) joue sans doute un peu là-dessus.
[^] # Re: haha
Posté par herodiade . Évalué à 5.
> si plusieurs scripts existent mais c'est déjà un problème en soi : lequel choisir).
Enfin, ceux qui n'ont pas l'envie ou le temps de s'occuper d'installer Slony peuvent toujours utiliser les paquets de leur distribution. Je préfère une implémentation native (plutôt parce que c'est l'assurance que ce composant suit le même processus de rewieving/qualité/release que le reste), mais c'est quand même un détail secondaire.
A moins que tu ne parle des scripts qu'on doit se bricoler pour ajouter les sets et les séquences au fur et à mesure que la structure de la / des base change ? (mais dans ce cas il s'agit plutôt d'un problème de configuration et d'"interface utilisateur" que d'intégration dans pg non ?).
> Mouaif. La réplication master-master pose énormément de problèmes
> [...] Au delà de la fiabilité, le moteur NDB induit tout un tas de limitations que je trouve inacceptable.
Je crois que tu confonds. La réplication master-master c'est une réplication traditionnelle (mais configurée dans les deux sens), utilisant le moteur de son choix (enfin, InnoDB quoi), et une ou deux petites fonctionnalités aidant les applications à éviter les conflits, et ça marche bien.
NDB c'est le moteur imposé pour "MySQL Cluster", tout autre chose. MySQL Cluster est un truc très limité, avec un nom designé pour le marketing, et exploitable pour des cas d'utilisation à mon avis franchement peut courants (et inadéquat pour le reste).
> PostgreSQL répond à ce problème avec le Point In Time Recovery
C'est une bonne fonctionnalité, mais ce n'est pas la réponse au problème.
Si tu n'a pas les WAL depuis les tout débuts de ta base (bonjour le volume), tu dois tomber un backup puis repérer jusqu'où tu applique tes logs, ce qui prendra un temps infernal (s'il s'agit d'un pg_dump, c'est très long, s'il s'agit d'un snapshot filesystem, il faut attendre que les DLT te tombent tes 400 Go de bases ...) (on parle de reprise de prod là). En outre, la méthode dont je parle permet de réellement voir les statements SQL en queue, et en quelques secondes repérer le fautif et demander au sgbd d'avancer jusqu'au précédent (ou de tout appliquer, y compris les suivants, sauf le fautif).
> Personnellement, je vois pas mal d'admins MySQL se plaindre de l'instabilité de la réplication via log shipping.
Sérieux, c'est une blague ? Je veux bien reconnaître les mérites et avantages de PostgreSQL, et ils sont nombreux, mais il ne faut pas déconner non plus : la réplication chez MySQL est native depuis au moins la version 4.0 (il y a très longtemps quoi), et c'est bien une des choses que MySQL a fini par gérer de façon correcte, simple et pratique (et qui évolue, la nouvelle replic mixte étant censée permettre d'avoir des slaves sur des machines bien moins puissantes en théorie (j'ai pas essayé cela dit)).
>> "les ajouts/drops/changements de tables soient naturellement répliqués sans qu'on intervienne"
>
> C'est déjà le cas dans la réplication via log shipping. Evidemment le fait que le slave ne soit pas accessible en lecture pour l'instant le limite au failover
Pas seulement le failover, ça limite diablement l'utilité qu'on peut tirer du slave, en toute franchise ;). J'ai cru comprendre que problème serait réglé *après* que le support pour la réplication "row based" serait intégrée, soit peut être dans 8.4, plus probablement post-8.4, quelqu'un à des nouvelles ?
> Pour l'histoire du cache disque, c'est l'argument qu'on entend souvent.
> Je dois avouer qu'on voit assez peu de cas où ça pose réellement un problème.
Il n'y a rien de spécial à « voir ». C'est juste que les selects sont beaucoup plus lents qu'ils pourraient l'être parce que les ressources disponibles ne sont pas exploitées de façon optimale.
Cela dit c'est vrai que dans beaucoup de cas, c'est l'appli en amont qui devrait maintenir son propre cache (ie. via memcached), pour bien faire.
> et je vois encore souvent des bases en production en 5.0 qui n'utilisent qu'un core sur 4 malgré une configuration correcte.
hmm, ça c'est pas normal. Avec innodb_thread_concurrency et thread_concurrency > 1 ?
(nb attention à ps, il faut passer des options adéquates pour qu'il liste les threads et pas seulement les processus).
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . Évalué à 4.
Non, je ne parle même pas de Slony mais de la réplication par log shipping qui demande des scripts pour gérer tout ça correctement.
"et une ou deux petites fonctionnalités aidant les applications à éviter les conflits, et ça marche bien"
Hmmm, un doute sur le "ça marche bien". Ca doit bien marcher dans certains cas, oui, mais la résolution de conflit dans le cas du multi master est très loin d'être trivial.
C'est là où MySQL a une approche beaucoup plus pragmatique que les autres bases. Le fait que ça marche dans la majorité des cas suffit en général.
"Si tu n'a pas les WAL depuis les tout débuts de ta base (bonjour le volume), tu dois tomber un backup puis repérer jusqu'où tu applique tes logs"
Euh, personnellement, je fais régulièrement des snapshots de la base. Donc, ce n'est pas depuis le tout début mais depuis le dernier snapshot. C'est déjà beaucoup moins long, même si ça peut effectivement déjà l'être.
"Sérieux, c'est une blague ?"
Non non. La réplication via log shipping qui saute a l'air d'être assez classique (je ne fais que répéter ce que les gens m'en ont dit - des gens en contact direct avec le problème et des gens assez variés et assez compétents pour que ça ne me paraisse pas une erreur triviale).
"Pas seulement le failover, ça limite diablement l'utilité qu'on peut tirer du slave, en toute franchise ;)"
Tu as mal compris ma phrase. Je disais justement que ça le limitait au failover donc que ça n'avait pas d'utilité en dehors de ça. On est bien d'accord là-dessus.
"J'ai cru comprendre que problème serait réglé *après* que le support pour la réplication "row based" serait intégrée, soit peut être dans 8.4, plus probablement post-8.4, quelqu'un à des nouvelles ?"
Il y a deux patches en attente d'intégration pour la 8.4 :
- un patch pour gérer la réplication standard en interne au lieu de recourir à des scripts, réplication toujours basée sur l'envoi des fichiers de WAL ;
- un patch pour permettre d'accéder au standby en lecture seule.
Après, nul ne peut parier qu'ils seront intégrés dans la 8.4.
"Il n'y a rien de spécial à « voir ». C'est juste que les selects sont beaucoup plus lents qu'ils pourraient l'être parce que les ressources disponibles ne sont pas exploitées de façon optimale."
Tu prends un peu trop les mots au pied de la lettre :). L'OS est loin de faire un mauvais boulot au niveau du cache disque dans beaucoup de cas. Comme je le disais, ça a un coût, tout le monde en convient, mais c'est un choix.
Le cache de requêtes est un autre sujet et PostgreSQL n'a aucune intention d'en implémenter un.
"hmm, ça c'est pas normal. Avec innodb_thread_concurrency et thread_concurrency > 1 ?"
Sur du MyISAM en l'occurrence (pas moi qui ai fait le choix). Et j'ai vu plusieurs personnes avec ce même problème.
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . Évalué à 2.
C'était pas très clair donc je précise :
Le fait que ça marche dans la majorité des cas suffit en général *pour MySQL*.
Ce n'est pas trop ma position sur le sujet : je préfère la bonne vieille rigueur :).
[^] # Re: haha
Posté par herodiade . Évalué à 5.
Ah okok, ma confusion, je pensais que tu parlais de Slony effectivement.
> Hmmm, un doute sur le "ça marche bien". Ca doit bien marcher dans certains cas, oui, mais la résolution de conflit dans le cas du multi master est très loin d'être trivial.
> C'est là où MySQL a une approche beaucoup plus pragmatique que les autres bases. Le fait que ça marche dans la majorité des cas suffit en général.
Pour clarifier, je parlais de l'aspect réplication, au sein sgbd : le stockage et les tuyaux marchent bien, c'est robuste.
Pour l'application cliente, en effet, la question se pose en d'autres termes. Ce type de solution n'est pas adaptée à tout les types d'applications (ie. les verrous ne sont pas partagés entre serveurs, c'est asynchrone, etc.). C'est plutôt pour les applications qui ont de gros besoins en écriture, et qui peuvent se contenter d'une logique type "le dernier qui update a raison" (en cas d'update d'une même chose simultanément sur plusieurs machines). Il faut aussi éviter les appli qui génèrent elles-même les pk qu'elles vont utiliser. C'est donc un truc spécifique mais qui s'avère souvent pratique. Ces limites/contraintes sont parfois plus simples à mettre en oeuvre coté applicatif que celles imposées par l'utilisation du sharding/partitionnement.
La solution supportée officiellement par MySQL pour les application généralistes désirant de la haute disponibilité avec reprise très rapide (mais sans répartition de charge), est différente, c'est DRBD (+ keepalived ou heartbeat) (à mon avis on doit pouvoir utiliser ces mêmes outils pour obtenir de la HA rapide avec pg d'ailleurs), mais, comme indiqué, c'est de la ha sans répartition de charge.
Dans tout les cas, le "scaling horizontal" (ha + lb) (par sharding/partitionnement, ou solutions type master-master, ou mysql-cluster/ndb, ...) avec les sgbd libres demande un peu de coopération de la part des applis clientes. Si j'en crois les brochures commerciales d'Oracle RAC (que je n'ai jamais essayé), eux n'imposeraient pas de telles contraintes. Bon, j'espère que le libre (PG et My) pourra un jour fournir ce niveau de service, le reste du stack applicatif libre en est généralement déjà capable (dns, lvs, proxys, serveurs applicatifs web, etc.), le sgbd est la pièce manquante (mais la plus délicate bien entendu).
> Il y a deux patches en attente d'intégration pour la 8.4 :
> - un patch pour gérer la réplication standard en interne au lieu de recourir à des scripts, réplication toujours basée sur l'envoi des fichiers de WAL ;
> - un patch pour permettre d'accéder au standby en lecture seule.
> Après, nul ne peut parier qu'ils seront intégrés dans la 8.4.
Cool ! Je ne savais pas que le patch permettant l'accès en lecture existait déjà ; c'est une super bonne nouvelle, ça veux dire qu'il ne s'agit pas seulement d'un souhait, de type "on aimerai bien avoir ça, on verra plus tard ce qu'il est possible de faire". Savoir ça, un peu d'espoir, me rendra le Slony moins amer d'ici là :).
> L'OS est loin de faire un mauvais boulot au niveau du cache disque dans beaucoup de cas.
hmm, j'aurais bien aimé causer de ça un peu, mais il va falloir que j'aille travailler, dommage ;)
> Le cache de requêtes est un autre sujet et PostgreSQL n'a aucune intention d'en implémenter un.
Note bien que le "cache des requètes" est aussi autre chose chez MySQL (ça existe (option query_cache_size), mais c'est généralement mois bénéfique, et en tout cas je parlais du cache des données (option innodb_buffer_pool_size)).
> Sur du MyISAM en l'occurrence (pas moi qui ai fait le choix).
Ah ok. C'est pas très étonnant alors : la granularité la plus fine des verrous utilisés par ce gros balot de MyISAM c'est ... le verrous par table (!). Ceci expliquant probablement cela ;)
[^] # Re: haha
Posté par Jerome Alet (site web personnel) . Évalué à 1.
> courant de ses points faibles pour l'apprécier pleinement.
C'est bien pour cela que je te demandais d'élaborer, merci donc pour toutes ces informations.
[^] # Re: haha
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
Ce qui est justement le cas de Slashdot qui a migré il y a déjà belle lurette de MySQL vers DB2 suite à de trop nombreux problèmes...
Sinon cette archi LAMP n'est pas à considérer comme le fin du fin en matière de représentabilité des capacités des sgbdr. Tous les cites dont tu parles doivent supporter une charge essentiellement en lecture qui est surtout du ressort d'un cache de données et non du sgbd. On est vraiment pas dans le cadre du transactionnel lourd.
Bref, nous n'avons pas vraiment les même repères. Le jour où je verrai une société faire du 10k insertions par seconde avec MySQL en environnement critique (transports, télécoms, météo, etc.) je changerai peut-être de point de vue.
[^] # Re: haha
Posté par herodiade . Évalué à 2.
> de représentabilité des capacités des sgbdr.
Tout à fait, loin s'en faut.
C'est juste un des cas d'utilisation possible, celui où MySQL a du succès (alors qu' il me semble, à vue de nez, que PostgreSQL a pour sa part plus de succès dans les applications métier, plus complexe et « relationnelles » si on veux).
> Tous les cites dont tu parles doivent supporter une charge essentiellement
> en lecture qui est surtout du ressort d'un cache de données et non du sgbd.
Les sites que je cite les savent déjà, et utilisent des serveurs de cache. J'ai cité par exemple LiveJournal : ce sont les inventeurs et mainteneurs de memcached. Il n'empêche que leurs serveurs bases sont nombreux et en (des écritures, plutôt que des lectures, donc) prennent plein les dents (ils ont communiqué sur leur achi). Idem pour les Digg et consorts.
[^] # Re: haha
Posté par Greg (site web personnel) . Évalué à 1.
Les gros sites de rencontres français aussi utilise MySQL. Meetic a eu une mauvaise expérience avec mysql par le passé, ce qui a provoqué un brutal passage à Oracle. Mais aujourd'hui, leur "frontaux" DB sont des mysql, et ils sont en train de passer au full mysql.
Easyflirt n'utilise que du mysql, Dailymotion aussi...
C'est peut-etre pour Monty une manière de promouvoir son nouveau projet: Drizzle...
[^] # Re: haha
Posté par taupette . Évalué à -2.
Mysql est effectivement largement utilisé car le marketing de ce produit a été bien fait mais Postgresql lui est supérieur techniquement (au moins pour l'instant car les investissements sur mysql sont nombreux )
Alors faut il privilégier un développement soutenu par une seule grosse société commerciale (ce qui rassure d'ailleurs certaines entreprises) ou par une grosse communauté assez indépendante d'objectifs commerciaux ?
[^] # Libre
Posté par Zenitram (site web personnel) . Évalué à 4.
MySQL est libre à 100%, que ça te plaise ou non.
Après, que ce ne soit pas un modèle ouvert (décisions communautaires) n'a rien a voir avec le libre. C'est un mode de fonctionnement, et le mode de fonctionnement n'a AUCUN impact sur les 4 libertés qui permettent de dire su un logiciel est libre ou non.
Il y a une définition de "libre", pas la peine d'en inventer une par personne. Ce dont tu parles est le modèle de développement.
[^] # Re: Libre
Posté par briaeros007 . Évalué à 2.
C'est pour ça qu'il est important de lire tout le commentaire avant d'entamer le sien.
Il a dis
du moins au sens des décisions communautaires
et
même si c'est un vrai logiciel libre au sens du code .
Il a été tout a fait clair dans son discours, et je ne vois pas vraiment ce que ton commentaire apporte.
Il y a une définition de "libre", pas la peine d'en inventer une par personne. Ce dont tu parles est le modèle de développement.
Et ce dont tu parle n'est pas de "libre" (qui, dans le sens d'un projet, n'a pas de définition stricte) mais de "logiciel libre".
Si tu veux être précis et faire la moral aux gens, soit aussi précis dans tes propos.
[^] # Re: haha
Posté par herodiade . Évalué à 6.
* Les bugs dont parle Monty concernent les nouvelles fonctionnalités (ormis sa brève évocation de 35 bugs graves hérités de 5.0 mais pas corrigés). Il ne s'agit pas de régression (bugs affectant des choses qui marchaient auparavant) ; au contraire : Monty affirme que certains bugs graves de 5.0 sont corrigés dans 5.1, au point qu'il invite à utiliser cette dernière plutôt que la branche 5.0 (mais en mettant en garde contre l'utilisation des nouvelles fonctionnalités).
* PostgreSQL n'est pas exempt de bugs graves. J'en sais quelques choses, j'utilise les deux SGBD dans des environnement à forte sollicitation. Il suffit de consulter le changelog de la 8.3.5 pour voir que la branche 8.3 est sortie avec des problèmes sévères. Je ne dis pas ça pour critiquer ce logiciel (je pense que tout logiciel de cette taille a ce problème), mais pour suggérer de nous épargner les lancers de trolls velus (comme dans le post grand-parent) à chaque fois qu'il est question de MySQL (et oui, même si PG a de nombreux afficionados motivés et passionnés dans les rangs de dflp).
* La décision de ne pas surseoir indéfiniment à la sortie d'une version, malgrè les bugs, est un choix qui peut se défendre, sous certaines conditions. Par exemple Linus Torvalds considère que la qualité du noyau s'effilocherai au fil du temps s'il attendait que tout soit corrigé (il soutient parfois, par exemple, que la release permet de galvaniser les testeurs et d'obtenir plus d'informations sur les bugs torteux, et qu'un délai trop long produirait un déluge ingérable de patchs lors de la « merge window » suivante).
* Un point qui me semble plus gênant, évoqué en fin de dépêche, est la difficulté avec laquelle les employé de Sun intègrent (ou plutôt, ne mergent pas) les patchs externes (ou « de la communauté »). Je pense en particulier aux patchs de Google, Percona, Proven Scalability etc., brefs diverses sociétés employant des anciens devs de MySQL, dont les patchs sont accueillis par des félicitations dans le bug tracker, mais rarement mergés (ou après un très long délai seulement). C'était déjà le cas avant le rachat de MySQL A.B. par Sun, mais vu la politique usuelle de ce dernier (cf. OpenOffice.org ou Java), je crains que les
choses ne s'arrangent pas.
[^] # Re: haha
Posté par stephwww . Évalué à 2.
* PostgreSQL n'est pas exempt de bugs graves. J'en sais quelques choses, j'utilise les deux SGBD dans des environnement à forte sollicitation. Il suffit de consulter le changelog de la 8.3.5 pour voir que la branche 8.3 est sortie avec des problèmes sévères. Je ne dis pas ça pour critiquer ce logiciel (je pense que tout logiciel de cette taille a ce problème), mais pour suggérer de nous épargner les lancers de trolls velus (comme dans le post grand-parent) à chaque fois qu'il est question de MySQL (et oui, même si PG a de nombreux afficionados motivés et passionnés dans les rangs de dflp).
[...]
Je n'ai pas de pratiques sérieuses sur postgreSQL (et aucune de mysql) mais la description des bugs corrigées dans les patchs d'Oracle sont interminables.
Mon impression et que toutes les bases sont critiquables et que les nouvelles fonctionnalités méritent d'être sérieusement tester.
Ce qui pourrait être grave ce serait des régressions...
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . Évalué à 4.
Bof. Le principal problème corrigé dans la 8.3.5 (et qui a principalement motivé sa sortie) est un problème introduit dans la version mineure d'avant et qui n'était pas présent dans la 8.3.0. Mais c'est clair qu'il y avait des bugs dans la 8.3 comme dans toutes les versions précédentes.
La grosse différence est que la 8.3 est sortie sans bug grave connu. Après il y a toujours des bugs comme dans tout logiciel et ils sont découverts et corrigés au fur et à mesure.
Pour voir arriver les bugs sur les mailing lists, ils ne restent en général pas longtemps non corrigés, raison pour laquelle PostgreSQL peut encore se passer d'un bugtracker, d'ailleurs.
[^] # Re: haha
Posté par herodiade . Évalué à 4.
Très marrant d'affirmer ça pour un projet qui n'a pas de bug tracker (ce qui est précisément le seul point concernant l'organisation/le communautaire/l'ouverture où pg est moins bon que my). Belle ironie.
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . Évalué à 1.
Le fait que tu ne puisses pas le vérifier sans faire un travail conséquent ne dit pas que je mens (cf plus bas pour les raisons qui font que c'est une réalité).
PostgreSQL n'a jamais eu besoin de bugtracker et les développeurs préfèrent gérer cela avec des mails. C'est leur choix... Ce choix est remis en cause régulièrement mais pour l'instant, c'est comme ça. Je suis d'accord que ça a parfois des inconvénients mais la recherche dans les archives des listes marche assez bien pour que ça ne soit pas vraiment gênant (en tous les cas, pas dans l'utilisation que j'en ai).
Et je maintiens ce que je disais pour la sortie de la 8.3.
Et la 8.4 sortira également sans bug majeur connu. C'est comme ça que ça marche depuis la nuit des temps avec PostgreSQL.
Ils reculeront la sortie le temps nécessaire s'il y a un bug connu ou enlèveront la fonctionnalité qui pose problème : il n'y a pas de deadline ou de fonctionnalités cibles imposées et la décision de publier une version est faite par les développeurs eux-même : ça fait une grosse différence.
Comme je le disais dans un autre post, ça n'empêche pas qu'il y ait de bugs découverts après la release.
[^] # Re: haha
Posté par Guillaume Smet (site web personnel) . Évalué à 3.
http://blog.hagander.net/archives/128-On-the-topic-of-releas(...)
[^] # Re: haha
Posté par TheGuit (site web personnel) . Évalué à -2.
Quel est l'interet de ce billet ? C'est comme si on lisait une étude sur la qualité du code d'Ubuntu de la part de Microsoft. Quel interet ?
[^] # Re: haha
Posté par calimo . Évalué à 2.
Mais c'est sûr que pour toute autre application critique, où texte et chiffres sont importants, où l'atomicité des transactions doit être respectée, il ne me vient pas à l'esprit d'utiliser MySQL (bien sûr il y a innodb...). Et ce n'est pas la version 6 qui me fera changer d'avis, fût-elle même parfaite sur ce plan là, et même si ce ne sont plus les mêmes développeurs qui avaient écrit, dans le manuel de la version 3.2, que ce n'était pas à la base de données de vérifier ce genre de choses.
[^] # Re: haha
Posté par andeus . Évalué à 0.
3.2, elle date de quand déjà cette version ?
En parlant de manuel tu devrais te pencher un peu dessus, tu verrais que ce comportement n’a rien d’immuable.
> Et ce n'est pas la version 6 qui me fera changer d'avis, fût-elle même parfaite sur ce plan là
[...]
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.