Tests : la nouvelle version du SGBD MySQL 5.4 est vraiment plus rapide

Tests : la nouvelle version du SGBD MySQL 5.4 est vraiment plus rapide
et deux fois plus rapide que ProgreSQL en lecture


MySQL est un des SGBD les plus utilisés par les hébergeurs de sites Web, et en particulier pour les solutions Web à base de PHP ou Python.

A l'annonce de la sortie de la nouvelle version 5.4 de MySQL, Sun affirmait qu'elle était 90% plus rapide que les précédentes. L'explication tenait aux efforts coordonnés des différents acteurs du projet : Sun bien sûr, mais également Oracle et Google. Cette affirmation est elle devenue réalité ?

Les différents tests effectués depuis semblent montrer que c'est bel et bien le cas : MySQL 5.4 tire profit à merveille des architectures multi-coeurs des nouveaux micro-processeurs.

Cet excellent test publié sur le blog de Dimitri Kozma montre non seulement que la nouvelle version MySQL 5.4 est beaucoup plus rapide que les versions précédentes, mais aussi que MySQL 5.4 est deux fois plus rapide en lecture que PostgreSQL 8.3.7 !

Encore un autre benchmark montre que MySQL 5.4 reste encore très performant même en activant les logs.

Source : Le benchmark des performances de MySQL.

Lire aussi :
:fleche: Oracle rachète Sun Microsystems
:fleche: La rubrique MySQL
:fleche: Le forum d'entraide MySQL

Avec des performances aussi exceptionnelles peut on penser que MySQL va continuer à avoir la faveur des hébergeurs pour servir un très grand nombre de transactions SQL à très faible cout ?

Ou alors est ce que le rachat de Sun, et donc de MySQL par Oracle est un danger pour le futur de MySQL ?

Et vous ?
:fleche: Avez-vous testé MySQL 5.4 et pensez-vous qu'il est effectivement le meilleur SGBD du moment ?
:fleche: Lui préférez-vous PostgreSQL ?
:fleche: Ou les solutions propriétaires vous paraissent-elles plus performantes ?

Citation:

---

Envoyé par Gordon Fowler

Et vous ?
:fleche: Avez-vous testé MySQL 5.4 et pensez-vous qu'il est effectivement le meilleur SGBD du moment ?
:fleche: Lui préférez-vous PostgreSQL ?
:fleche: Ou les solutions propriétaires vous paraissent-elles plus performantes ?

---

Chaque probleme a sa solution, donc non, Mysql n'est pas le meilleur SGBD pour toutes les solutions, pour un site web, il est pas mal certes, J'aime beaucoup Postgresql et Mysql, j'aime mysql car il est relativement simple a utiliser et administrer, j'aime bien le système de sécurité au niveau des connexions (user@host), l'event scheduler j'aime bien la commande SHOW qui est vraiment très pratique, les capacité de monitoring qui sont énormes, par contre je n'aime pas trop avoir plusieurs moteurs de stockage pour disperser les fonctionnalités entre tous, c'est pas vraiment ce qu'on pourrait dire pratique, et il manque pas mal de trucs par apport a Postgresql, par exemple pouvoir définir ses propres types de données, qu'il y au un "database-space" qui permettent de pouvoir absolument tout modifier dans sa base de données sans affecter tout le serveur (pouvoir définir ses types, les modifiers, ses triggers, etc), en gros chaque database a sa propre copie de pratiquement tout les éléments systèmes, mais ca a aussi un inconvénient, ca prend de la place, une base Postgresql VIDE prend presque 5Mo... On apprécie aussi la compression a la volée de Postgresql, je suis pas sure que Mysql puisse faire ca...

Par contre au niveau SQL on a des fois des mauvaises surprises, pour faire par exemple un

Code:

---

SELECT "foo" FROM bar;

---

Vous n'aurez pas la colonne foo, mais que du "foo", "foo", "foo" (bon il suffit de SET SESSION sql_mode="AINSI"; pour régler le probleme temporairement ;p).... on est obligé d'aller utiliser les quotes bizarres qui sont même pas sur le clavier (et si vous mettez bar en "bar", pour erreur) (autre mauvais point pour Mysql, les erreurs vraiment pas explicites la plupart des cas) :/

La réplication simple Master<-->Slave est aussi plus simple a mètre en place sur Mysql que Postgresql, par contre il parrait que c'est pas terrible pour faire des trucs pour évolué, j'ai entendu dire que Mysql Cluster devais garder toute la base de données en Ram sur CHAQUE cluster (donc si la base de données fait 30Go, il faut minimum 30Go de ram sur chaque cluster... youpi ;)

Citation:

---

Envoyé par kedare

[...]
Par contre au niveau SQL on a des fois des mauvaises surprises, pour faire par exemple un

Code:

---

SELECT "foo" FROM bar;

---

Vous n'aurez pas la colonne foo, mais que du "foo", "foo", "foo" (bon il suffit de SET SESSION sql_mode="AINSI"; pour régler le probleme temporairement ;p).... on est obligé d'aller utiliser les quotes bizarres qui sont même pas sur le clavier (et si vous mettez bar en "bar", pour erreur) (autre mauvais point pour Mysql, les erreurs vraiment pas explicites la plupart des cas) :/
[...]

---

Tu te fais des nœuds dans la tête là ;).
C'est normal que " soit interprété comme étant une chaine de caractère. Si tu as besoin d'afficher une chaine de caractère géré par toi même tu fais comment ? Exemple

Code:

---

SELECT CONCAT("HTTP://", `monUrl`) AS url FROM MaTable

---

Placer une double cote sur le nom d'une table c'est que tu cherches des embêtement là. La cote inversé c'est la touche Altgr+7 et c'est la touche que nous trouvons de manière directe sur un clavier américain.

C'est pas sorcier :aie:
http://img.ozap.com/01053264-photo-c...as-sorcier.jpg

En tout cas chapeau à l'équipe pour avoir de telle performance et je pense que Mysql à toujours de bon temps devant. Mysql ne marche pas sur les plats de bande d'Oracle, ils ne s'adresse pas au même utilisateur et n'ont pas les mêmes objectifs. Par contre Oracle à tout à y gagner à faire valoir les performances de Mysql et les services qui peut y avoir autour pour une entreprise qui est en demande.

La rapidité d'une base de données est une chose très relative.

Si c'était le seul critère de choix : ça serai simple :)

Le choix d'une base de données dépend de tes besoins :
- Exemple simple : si tu as besoin des CTEs (norme SQL 99) tu peux oublier MySQL 5.4 et tu devras te diriger sur PostgresSQL 8.4, Firebird 2.1 ou d'autres solutions propriétaires.

Citation:

---

Envoyé par VLDG

La rapidité d'une base de données est une chose très relative.

Si c'était le seul critère de choix : ça serai simple :)

Le choix d'une base de données dépend de tes besoins :
- Exemple simple : si tu as besoin des CTEs (norme SQL 99) tu peux oublier MySQL 5.4 et tu devras te diriger sur PostgresSQL 8.4, Firebird 2.1 ou d'autres solutions propriétaires.

Avant developpez.com était un site d'entraide de développeur...
Maintenant, j'ai l'impression qu'il "balargue" tout ce qu'il trouve mais c'est surement la rançon du succès...

---

En faite, l'information donnée c'est pas pour dire au personne de passer sur Mysql mais plus à ceux qui y était déjà ou ceux qui se pose la question et là c'est pour ajouter un argument à leur choix. Bien évidemment, la rapidité n'est pas le seul critère mais elle du poids

Citation:

---

Envoyé par VLDG

La rapidité d'une base de données est une chose très relative.

Si c'était le seul critère de choix : ça serai simple :)

Le choix d'une base de données dépend de tes besoins :
- Exemple simple : si tu as besoin des CTEs (norme SQL 99) tu peux oublier MySQL 5.4 et tu devras te diriger sur PostgresSQL 8.4, Firebird 2.1 ou d'autres solutions propriétaires.

---

Oui.
Sauf que Mysql est extrêmement utilisée dans l'exploitation des sites internet (effet php), hors un site internet, 95 cas sur 100 c'est (en suivant mes exemples) 100 lectures pour 1 écriture, si ce n'est un rapport plus grand encore.

Qd on sait qu'en plus le plus gros problèmes de la montée en charge réside dans la rapidité d'exécution des calculs (qui peuvent être long et couteux dès que cela devient métier), calculs qui bien souvent sont relegués à la base de données (tout justement pour sa rapidité) le tour est vite fait de l'intérêt de l'annonce.

Fin moi ce que j'en dis, c'est que j'utilise mysql, et que je vais presser mes admins à y passer, et que c'est bien. voilà. et que non ce n'est pas du tout relatif.

Mais que oui on peut y mettre des pincettes, j'attend de voir dans les faits sur quoi je gagne réellement.
Car si c'est pour gagner 90% de rapidité à faire

Citation:

---

SELECT * FROM nowhere LIMIT 0,10

---

Effectivement, ce serait bien nul.

a plus

Code:

---

SELECT * FROM nowhere LIMIT 0,10

---

Sur 200 milles lignes, je pense que ça peut faire sont effet ;)

Ouais, disons que sa pousserait l'utilisation de mysql pour les orm (style ZF, ou SP par exemple) qui fourmillent de ces requêtes.

En tout cas faut éplucher son bench, il c'est donné du mal pour être intéressant
http://dimitrik.free.fr/db_STRESS_My...s_Apr2009.html

Citation:

---

Envoyé par kaymak

Fin moi ce que j'en dis, c'est que j'utilise mysql, et que je vais presser mes admins à y passer, et que c'est bien. voilà. et que non ce n'est pas du tout relatif.

---

si tu as pleins de coeurs tu vas y gagner mais sinon, ça ne sert à rien...

PS : pleins de coeurs = beaucoup d'argent...

Citation:

---

Envoyé par VLDG

si tu as pleins de coeurs tu vas y gagner mais sinon, ça ne sert à rien...

PS : pleins de coeurs = beaucoup d'argent...

---

Pour les hebergeurs.

Citation:

---

Envoyé par berceker united

Tu te fais des nœuds dans la tête là ;).
C'est normal que " soit interprété comme étant une chaine de caractère. Si tu as besoin d'afficher une chaine de caractère géré par toi même tu fais comment ? Exemple

Code:

---

SELECT CONCAT("HTTP://", `monUrl`) AS url FROM MaTable

---

Placer une double cote sur le nom d'une table c'est que tu cherches des embêtement là. La cote inversé c'est la touche Altgr+7 et c'est la touche que nous trouvons de manière directe sur un clavier américain.

---

Pour les strings, la norme SQL dit qu'il faut utiliser le quote simple : '
Le " est censé etre réservé pour les noms de tables/colonnes....

La grosse différence pour moi c'est que postgreSQL j'en fais quasiment ce que j'ai envie, je l'installe en clientèle librement, j'utilise des connecteurs qui ont la gentillesse de ne pas m'obliger à fournir gratuitement les sources de nos 2 années de recherche et développement à mes concurrents :aie:.

Bien que ça n'ait jamais été clair chez mysql, il est évident que sa licence pseudo-libre est bien plus restrictive dans son usage que celle de postgresql (dont on peut faire quasiment ce que l'on veut.).

Par ailleurs, je sais pas si c'est encore le cas aujourd'hui mais les backups à chaud mysql étaient pas 100% garantis en consistence (corrigez-moi sinon) et les possibilités de programmation de procédures stockées beaucoup plus pauvres.

Citation:

---

Envoyé par _skip

Par ailleurs, je sais pas si c'est encore le cas aujourd'hui mais les backups à chaud mysql étaient pas 100% garantis en consistence (corrigez-moi sinon) et les possibilités de programmation de procédures stockées beaucoup plus pauvres.

---

C'est toujours le cas....

salut,
les tests concernent innodb , quelqu'un sait si le moteur myIsam tire bénéfice de ces améliorations ?

bonjour,

y-a-t-il des gens ici (parmi la communauté) qui ont remarqué et constaté une différence énorme de rapidité ou pas ?
j'ai peur que ce soir propre au benchmark et pas dans un cas génral.

Idem, j'aimerai savoir si ça concerne aussi MyIsam ou juste InnoDB.

bon dimanche

hello,

pour ce que j'en ai lu, innodb.
Pour le moment pas de mise en ligne, donc pas de phases de test, et donc pas de retours possible ;)


a plus