dasini.net – Journal d'un expert MySQL

Cela fait quelques jours maintenant que MySQL 5.6 est disponible pour la production. Un impressionnant travail a été effectué par les équipe d’Oracle, voici un petit résumé des principales évolution vu par Peter Zaitsev.

L’événement dans l’événement, c’est la « polémique » sur les performances de la 5.6, par rapport à MySQL 5.5 mais surtout par rapport à MariaDB 5.5.

Dimitri (Oracle), montre que MySQL 5.6 écrasent MySQL 5.5 et MariaDB 5.5. Axel (MariaDB), de son coté montre que la 5.6 est moins performante que MariaDB 5.5, ainsi que MySQL 5.5. Peter (Percona), de son coté montre que les perfs de MySQL 5.6 sont en retrait par rapport à celles de MySQL 5.5. Au passage, je note que Percona server 5.5 n’est pas testé… Last but not least, Mark (Facebook) , montre que sa version maison 5.1.63 patchée met tout le monde d’accord. Il montre aussi que le coût du performance schemas n’est pas négligeable.

Les Viadeo Tech Days !
Une conférence qui vous donnera l’occasion d’échanger avec nos équipes de développement et de tout savoir sur les environnements à forte charge.
Rendez-vous les 20, 21 et 22 novembre 2012 à Paris pour 3 nocturnes animées par nos meilleurs ingénieurs.

Viadeo vous donne rendez-vous les 20, 21 et 22 novembre 2012 à Paris à l’occasion des Tech Days.

Au programme des conférences:
– MySQL avec MHA
– HDFS HA
– Neo4J
– Puppet
– UX
…
http://techdays.viadeo.com/

Ce lundi 04 juin 2012, SUP’INTERNET et EPITECH organisent le PHP DAY, avec en guest star Rasmus Lerdorf, au CAMPUS TECHNOLOGIQUE DE IONIS EPITECH-SUP’INTERNET 14-16 rue Voltaire 94276 Kremlin Bicêtre Cedex

MySQL est connu pour ne pas être très performant avec les sous-requêtes. Ce n’est pas faux, et d’ailleurs c’est encore le cas avec MySQL 5.5. Le contournement consiste en général à réécrire la requête, certaines sous-requêtes pouvant être aisément réécrite en jointure.

C’est le cas de

SELECT a FROM T1 WHERE col IN (SELECT col FROM T2…) qui se transforme en

SELECT distinct a FROM T1 INNER JOIN T2 ON TI.col=T2.col WHERE …

Voici la suite du post MySQL 5.6 rock, dans lequel je test MySQL 5.5 & 5.6, MariaDB 5.3 & 5.5 et Percona server 5.5.

Pour cet article, toujours un bench. Le contexte est assez proche, à la différence près que cette fois les serveurs sont testés en lecture (65%) et écriture (35%).

Comme d’habitude, mon but n’est pas de connaître les possibilités maximales du serveur (d’autres le font mieux que moi), mais plutôt d’avoir une idée assez précise de leurs comportements respectifs dans un environnement le plus proche possible de ma prod.

pour ce test, les candidats sont, Percona 5.5, MariaDB 5.3 & 5.5, MySQL 5.5 et la dernière milestone de MySQL 5.6. L’idée est de voir comment se comporte les différentes versions dans un contexte I/O bounds ie un faible hit ratio du buffer pool (ou du moins le plus bas possible), en d’autres termes, simuler le comportement du serveur MySQL dans un environnement où la quantité de données est énorme (comme à Viadeo).

Selon le livre «Audit & optimisation, MySQL 5 – éditions Eyrolles», le cache de requêtes ou query cache est un système de cache mémoire interne à MySQL, transparent pour l’application, qui ne stocke que les requêtes SELECT et leurs résultats.

L’apport de ce cache est particulièrement dépendant de votre application. Il est coutume de dire qu’il est (très) pénalisant dans des environnements où les requêtes d’écritures sont nombreuses, notamment à cause de son mécanisme d’invalidation (et de problèmes de contentions de façon générale).

A l’opposé, il peut être intéressant de l’activer, dans des environnements à forte charges de lectures, si les mêmes requêtes reviennent très fréquemment, plus particulièrement lors de l’utilisation de tables MyISAM.

Cependant, un environnement à forte charge en lecture n’est pas une condition suffisante pour s’assurer de bonne performances avec le query cache, c’est ce que nous allons voir dans cet article.

Les vidéos du meetup Viadeo/LeMUG sont dispo:

Christophe Tibault : Opening keynote
Cédric Peintre : Planification et monitoring de mysqldump avec ZRM community
Stéphane Combaudon : Maatkit/Percona Toolkit en pratique
Marc Thomas : Passer de 10 000 à plus de 10 000 000 de paiements par mois
Olivier Dasini : Étude de cas : migration MySQL Latin 1 vers UTF-8

Vous pouvez consulter les photos du meetup Viadeo/LeMUG sur le compte FB du MUG:

https://www.facebook.com/media/set/?set=a.10150393843136937.345851.46154571936&type=3