L'antenne parisienne de l'AFUP, que j'anime avec Christophe et Amaury a organisé jeudi dernier un RDV sur les BDD relationnelles. Le dernier en date était celui sur les design pattern et anti pattern, et il faut avouer, qu'il date un peu ! On s'était un peu « endormis » (<=> surchargés de boulot), on va essayer de reprendre un rythme plus régulier. Si vous avez des idées de RDV, que vous voulez organiser une soirée, ou sponsoriser, surtout n'hésitez pas à nous contacter à ce sujet (sur twitter @afup_paris, ou par ce formulaire) !

La soirée de jeudi dernier quant à elle s'est très bien déroulée, une ambiance sympa comme toujours, des conférenciers dynamiques et un apéro barbecue offert par SkySQL avec Linagora dans une ambiance...euh ...rythmée ! En s'éloignant de la sono, ça allait ;)

Thomas Reiss, présentation PostgreSQL :

• respect des normes,
• respect des données,
• excellente portabilité.

Un code source en C et tout un tas de fonctionnalités sympas comme des contraintes d'exclusion, la possibilité de mettre en place différents types et algo internes, de mettre de nouveaux types supplémentaires, d'extraire directement les data en json etc.

Possibilité aussi avec de nouvelles extensions d'accéder à des objets distants, de mettre en place une réplication en cascade...

Donc utiliser Postgre pour :

• beaucoup de transactions simultanées
• assurer l'intégrité des données
• la sécurité
• beaucoup d'utilisateurs en même temps
• des requêtes complexes

Merci à thomas d'avoir eu le courage d'exposer Postgre au beau milieu de la secte d'adorateurs du dauphin ;)

Olivier Dasini, méthodologie d'optimisation des requêtes mySQL :

La méthode :

• récupérer les infos
• extraire les problèmes
• optimiser
• tester

Récupérer les infos :

avec slowlog, anenometer, appDynamics, Percona Toolkit

Extraire les problèmes :

d'après les infos recueillies on repère quelles sont les requêtes les plus longues, en temps cumulé (donc en tenant compte du nombre de fois où la requête revient).

Optimiser les requêtes :

• index :
  • sur les champs du WHERE en premier
  • si possible aussi sur les champs appelés par le SELECT
• données :
  • essayer de prévoir la taille minimum dans la base de données (pas besoin de mettre un varchar 255 pour un champ mail)
  • pas de SELECT *
• innoDB

NB : attention, les index ne fonctionnent plus s'ils sont utilisés dans des fonctions.

Tester :

« Le meilleur emplacement...c'est la prod » :) (#QOTD)

En général pas possible=>donc pré-prod.

Utiliser mysqlslap

Comme partout l'optimisation est un processus itératif.

Une conf particulièrement vivante et pleine d'humour, bravo Olivier !

Retour d'expériences de SkySQL sur leur driver PHP/MySQL :

Peu de dépendances, beaucoup de possibilités de cache, de load balancing master/slave... bref de possibilités d'optimisations assez pointues.

Fin de la conf par une question pour un champion : connaître la dernière version de mariaDB m'aurait permis de gagner un livre...tant pis !

• http://afup.org/templates/rendezvous/slides/20130228_mysql_query_tuning.pdf
• http://afup.org/templates/rendezvous/slides/20130228_postgresql.pdf
• http://afup.org/templates/rendezvous/slides/20130228_mysqlnd.pdf