Oracle, nouvel éditeur de MySQL suite au rachat de Sun, vient d'annoncer une nouvelle version 7.2 de MySQL Cluster sous licence GPL (les numéros de version de la version « cluster » sont déconnectés de la version classique). MySQL Cluster est une version dite « distribuée » de MySQL utilisant le moteur NDB (Network DataBase), en lieu et place des classiques MyISAM et InnoDB, permettant une répartition des données et un fonctionnement sur plusieurs serveurs. Le développeur ne voit qu'un seul serveur : le répartiteur de charge.
Cette nouvelle version augmenterait les performances d'un facteur 70 sur les requêtes SQL complexes incluant des jointures sur plusieurs partitions. Un benchmark interne affiche que cette version est désormais capable de dépasser le milliard de requêtes par minute. Il faut évidemment avoir le matériel adéquat. Il a été réalisé sur un « cluster » de 8 nœuds, chaque nœud ayant été équipé de serveur avec 2 Intel Xeon X5670 et 48 Go de RAM, le tout relié par un bus InfiniBand.
Enfin, quant à la version GPL, on se souviendra de la tendance d'Oracle à ajouter tout un tas d'extensions fermées au cœur de MySQL afin de mieux retenir ses utilisateurs.
- L'annonce Oracle (69 clics)
- Les explications du benchmark à un milliard de requêtes par minutes (110 clics)
- MySQL Cluster sur Wikipédia (108 clics)
- Oracle may "fork itself" with recent MySQL moves (55 clics)
Les benchmarks n'ayant valeur que de benchmarks, voici la preuve marketing absolue en Nimage :
Avec ce graphe, plus aucun doute n'est possible.

# Extensions au cœur de MySQL ?
Posté par magnetik (page perso, jabber id) . Évalué à 3.
J'ai une petite question sur la dernière phrase, il s'agit d'extensions à la "norme SQL" ou de blob propriétaire au sein du code GPL ?
merci
# Partition
Posté par Barret Michel (page perso, jabber id) . Évalué à 3.
L'objectif des partitions n'est-il pas justement de limiter le nombre de requêtes sur plusieurs partition ? Par exemple si on crée une partition par mois, généralement c'est parce qu'on sait que la majorité des requêtes concernent le mois en cours. De même pour le partitionnement vertical si on sépare les blobs (entre autre) du reste de la table ça devrait être fait car le nombre de requêtes sur la partie blob devrait être limité.
Bref j'ai l'impression que cette optimisation n'est pas inutile mais a un intérêt limité dans la majorité des cas.
Égoïste, irresponsable décerné par devnewton
# Quelle différence !
Posté par kubrick . Évalué à 2.
De là à dire que la version précédente était boguée, il n'y a qu'un pas...
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.