Le shell

L’idée : générer un fichier texte des données à insérer puis exécuter le fichier de sortie comme entrée du client mysql.

Cette méthode n’est pas la plus efficace du lot, surtout pour 1 million de lignes, mais on peut néanmoins arriver à ses fins :

debian:/tmp# (for i in `seq 1 1000000`; do echo "insert into test.t(flag) values(round(rand()));"; done;) > /tmp/insertions.txt

Puis :

debian:/tmp# mysql test < /tmp/insertions.txt

Notre million de lignes est inséré.

mysqlslap

mysqlslap est un outil de benchmark que nous avons étudié récemment. Nous détournons ici son utilisation première pour finalement exécuter notre million de requêtes :

debian:/usr/local/mysql51# ./bin/mysqlslap --user=root --socket=/tmp/mysql.sock --concurrency=1 --iterations=1000000 --query="insert into test.t (flag) values (round(rand()))"

Benchmark
Average number of seconds to run all queries: 0.000 seconds
Minimum number of seconds to run all queries: 0.000 seconds
Maximum number of seconds to run all queries: 0.609 seconds
Number of clients running queries: 1
Average number of queries per client: 1

Cette solution est plus rapide que la précédente, aussi si vous disposez de mysqlslap, n’hésitez pas.

La procédure stockée : REPEAT… UNTIL

Dès lors qu’on envisage d’insérer 1 million de lignes dans une table, la notion de “boucle” n’est jamais très loin, et finalement la procédure stockée non plus. Celle-ci est en effet un moyen simple et rapide d’implémenter un traitement répétitif.

Basique et à peine paramétrable (seul le nombre d’enregistrements à insérer est dynamique), voici à quoi ressemble la procédure stockée permettant d’insérer notre million de lignes :

delimiter //
CREATE PROCEDURE fill_table(nb_rows INT)
BEGIN
DECLARE i INT DEFAULT 0;
REPEAT
SET i = i + 1;
INSERT INTO t (flag) VALUES(round(rand()));
UNTIL i >= nb_rows
END REPEAT;
END;
//
delimiter ;

Pas vraiment besoin de commenter le code, on note simplement les “delimiter” qui permettent de définir une autre terminaison que “;” le temps d’écrire la procédure dans le client mysql.

Pour appeler celle-ci :

mysql> CALL fill_table(1000000);
Query OK, 1 row affected (1 min 37.98 sec)

Cette solution est la plus rapide des trois présentées ici.

Mission accomplie ? Presque…

Avant de lancer la procédure stockée, la commande SHOW INDEX affichait une cardinalité de 0 pour la clé primaire et de NULL pour notre index situé sur “flag”.

Une fois la procédure terminée, un SHOW INDEX indique cette fois une cardinalité mise à jour pour la clé primaire (1 000 000) mais celle-ci est toujours à NULL pour l’index “flag”.

La commande ANALYZE permet de laver cet affront :

mysql> ANALYZE TABLE t;
+---------+---------+----------+----------+
| Table   | Op      | Msg_type | Msg_text |
+---------+---------+----------+----------+
| world.t | analyze | status   | OK       |
+---------+---------+----------+----------+

Les statistiques de notre index sont désormais à jour et la commande SHOW INDEX indique désormais une cardinalité de 2 pour l’index “flag”, le champ indexé ne comporte effectivement que des 0 ou des 1.

Nous voilà face à un index de cardinalité 2… Peu sélectif ? Inutile ? Mieux que rien ? Les paris sont ouverts.

Réponse au prochain numéro, stay tuned.

Pour les anglophobes, Drizzle est une version "light" de MySQL basée sur un "fork" de la version 6.0 lancé par Brian Aker. Un fork pour faire simple, on prend une copie des sources à un instant t et on commence à developper dans son coin. Jusqu’à présent, je connaissais celle de mes amis de Proven Scaling et celle de Monty lui même (j’en profite pour saluer Guilhem qui fait parti de ce projet).

Maintenant pourquoi le nom Drizzle? un petit tour sur wikipedia, Drizzle est une petite pluie… humm.. et cet RDBMS à pour cible les applications web et le cloud (nuages) computing… ok! gotcha!

Toujours sur wiki , on prend MySQL, on enlève tout qui n’est pas nécéssaire pour une application web ( procédures stockées, view, triggers,…) et on rajoute, corrige les problèmes actuels de MySQL (core,..)…

Maintenant que nous avons fait un peu le tour de sujet, nous sommes en droit de nous poser quelques questions. De mon point de vue, beaucoup de membres de la communauté n’ont pas toujours pas digéré la séparation de MySQL en communauté et enterprise. Ils ont senti leur "bébé" leur échaper. De même, beaucoup se sont senti frusté lorsque le temps d’intégration d’un fix s’est mis à grandir de façon exponentielle…

J’ai bien aimé le post de Brian aussi, "Drizzle n’est pas un remplacant potentiel de MySQL"… oui… oui et non. Si j’ai une application web, dois je utiliser Drizzle ou MySQL? Sachant quand même que le succes de MySQL est quand même basé sur le succes du web.

Finalement je finirai par le post de Mark, "share the love", "partager l’amour", humm pas très français tout çà. Pour ma part, je suis content qu’une initiative telle que Drizzle voit le jour, et j’attends avec impatience de pouvoir la tester et l’évaluer mais j’attends avec encore plus d’impatience que la 5.1 soit G.A, que Maria sorte une version plug-in, que le plug-in InnoDB devienne stable,…

Et vous, qu’en pensez-vous?

Commençons par les sources d’information en français, c’est vite fait :

Tout d’abord passage obligé par Planet MySQL, dont la déclinaison française est dûe à “Pébé“, il y’a pour l’instant beaucoup moins de blogs MySQL que sur la version originale mais n’hésitez pas à vous faire connaître si vous-même bloggez sur MySQL en français.

Transition toute trouvée vers le site de Nexen.net, dont le flux d’actualité MySQL est lui aussi présent sur Planet MySQL. Je vous encourage tout particulièrement à vous abonner à la newsletter hebdomadaire de Damien Seguy, vous y trouverez une sélection d’articles PHP/MySQL de qualité.

Le contenu français s’arrête là, cependant ne passez pas à côté de la nouvelle édition (été 2008) du MySQL Magazine, au menu différents tutoriels dont un concernant mk-table-checksum, un des outils du célèbre maatkit permettant de s’assurer que le contenu de vos tables sur le slave sont bien identiques à celles du master. Egalement au programme de cette édition, le résultat d’un grand sondage MySQL.

Vous l’aviez sans doute remarqué mais au cas où : le module de recherche du site mysql.com a été grandement amélioré. Reposant désormais sur une technologie Google, les résultats sont plus pertinents.

Un billet de mysqlperformanceblog nous rappelle qu’en installant un GNU/Linux 32 bits sur une architecture 64 bits, MySQL ne pourra utiliser plus de 2.5 GB de mémoire… C’est pourtant une configuration répandue chez les hébergeurs.

Ne ratez pas les slides “Join-Fu” de Jay Pipes : de très bon slides sur l’optimisation des requêtes, le partionnement, il y’a deux séries de slides, lisez au moins la première.

Enfin, un article très intéressant (trouvé via xaprb.com) sur le partionnement des données avec à la clé la présentation d’une stratégie nommée BASE (basically available, soft state, eventually consistent) à comparer avec le plus classique ACID (Atomicity, Consistency, Isolation, Durability), l’idée étant ici de “sacrifier” la cohérence assurée par le SGBD au profit d’une meilleure montée en charge, tout en retombant sur ses pieds bien sûr…

Bonnes lectures !

Haute disponibilité (redondance), montée en charge et haute performance (données en mémoire vive), une architecture en “shared-nothing” (aucun élément du cluster ne partage le même hardware) et un serveur mysql doté d’un nouveau moteur de stockage (NDB encore appelé NDBCLUSTER), voici quelques caractéristiques du cluster MySQL. Voyons comment l’installer en un minimum d’étapes.

Vue d’ensemble des éléments composant un cluster

Ce schéma issu de la documentation MySQL expose les différents élements qui composent un cluster MySQL, passons-les rapidement en revue.

Les trois principaux éléments d’un cluster MySQL sont les suivants :

Le management node (MGM) est un point central du cluster et doit être démarré le premier. Pour cela on utilise la commande ndb_mgmd suivie si besoin du fichier de configuration du cluster. Celui-ci contient une entrée pour chaque noeud susceptible de se connecter au cluster. Les autres noeuds se connectent au MGM node via une chaîne de connexion nommée “connectstring“, nous verrons cela.

Les SQL Nodes reposent sur des serveurs MySQL tels que nous les connaissons déjà, exceptés qu’ici le moteur de stockage NDB est utilisé. Celui-ci permet de dialoguer avec les Datas Nodes et autorise le stockage des données en mémoire (le stockage sur disque est également en partie envisageable). Les SQL Nodes interrogent les Datas Nodes afin de retrouver l’information stockée. A noter : le SQL Node est de façon plus générale un API Node, c’est à dire une application qui accède à l’information stockée par le cluster.

Les Datas Nodes ont pour fonction principale de stocker l’information de façon redondante. Sans rentrer dans les détails pour le moment, il faut au moins deux Datas Nodes pour faire fonctionner le cluster dans une configuration minimale. Un cluster doit être tolérant aux pannes (haute disponibilité), l’information est donc forcément dupliquée afin de supporter la perte d’une machine sans pour autant perdre le cluster. Celui-ci reste viable tant qu’une version au moins de l’information est présente, plus celle-ci est dupliquée, plus on peut se permettre de “perdre” un noeud.

Rajoutons enfin le Management Client (ndb_mgm), il se connecte au MGM Node, n’accède pas aux données mais permet de gérer les noeuds du cluster ou de visualiser le statut de celui-ci.

L’installation du cluster MySQL sous linux

A noter que cette installation aurait été difficile sous Windows puisque le cluster MySQL n’est pour l’instant tout simplement pas disponible sur ce système…

Attention, l’installation qui va suivre n’a pas vocation à être utilisée en production. Cette installation place tous les composants du cluster sur une même machine (mon pc portable en fait) inutile donc d’espérer une quelconque redondance si jamais un des composants de la machine venait à lacher et ne parlons pas de la montée en charge… Le but est simplement d’installer rapidement le cluster MySQL sur votre machine personnelle afin de se familiariser avec les différents éléments du cluster au fil des prochains articles.

Il existe différentes configurations pour installer un cluster, une fois que vous serez familiarisé avec celle-ci, comparez-la avec celle proposée sur le site de MySQL dans le cadre d’une configuration avec plusieurs machines. Libre à vous ensuite de vous construire un cluster dont l’architecture serait plus proche de la réalité, en simulant un noeud par machine virtuelle par exemple.

L’installation d’un cluster MySQL se déroule en grande partie comme une installation MySQL classique à ceci près que certaines options font leur apparition dans les fichiers my.cnf (ndbcluster, connectstring), chaque noeud est censé avoir son fichier my.cnf (ici il sera partagé). Autre nouveauté, un fichier de configuration global, souvent appelé “config.ini”, est présent sur le Management Node uniquement.

Une fois les sources récupérées, voici les étapes suivies (installation sous ubuntu) :

// Décompression de l’archive…
/opt# tar xzvf mysql-cluster-gpl-6.2.15-linux-i686-glibc23.tar.gz

// Création d’un lien symbolique vers le répertoire d’installation
/usr/local# ln -s /opt/mysql-cluster-gpl-6.2.15-linux-i686-glibc23 ndb6215

Si vous n’avez pas encore crée de groupe “mysql” lors d’une précédente installation (peu probable si vous vous intéressez au cluster), c’est le moment :

shell> groupadd mysql
shell> useradd -g mysql mysql

Configuration des permissions adéquates appliqués aux répertoires de l’installation :
/usr/local/ndb6215# chown -R root .
/usr/local/ndb6215# chown -R mysql data
/usr/local/ndb6215# chgrp -R mysql .


Les fichiers “my.cnf” ont entre autres pour but de permettre aux noeuds de se connecter au MGM node via une connecstring. Sachant que nous n’avons qu’une seule machine dans cette procédure d’installation, notre fichier de configuration local, my6215.cnf, sera donc commun aux différents noeuds, excepté le MGM node qui lui pointe vers le config.ini, voici le fichier my6215.cnf crée pour notre cluster :

# my6215.cnf
[client]
port            = 3307
socket          = /tmp/my6215.sock

[mysqld_safe]
ledir           = /usr/local/ndb6215/bin

[mysqld]
ndbcluster
ndb-connectstring= 127.0.0.1
port            = 3307
socket          = /tmp/my6215.sock
basedir         = /usr/local/ndb6215
datadir         = /usr/local/ndb6215/data

[mysql_cluster]
ndb-connectstring=127.0.0.1

Très simplifié, il reprend les entêtes déjà connues du my.cnf classique à savoir “client”, “mysqld_safe” ou encore “mysqld”. J’ai choisi de faire tourner le serveur mysqld sur le port 3307 au cas où un serveur MySQL existerait déjà en 3306 sur la configuration dont vous pourriez déjà disposer.

Pour l’entête “client”, rien de spécial à signaler, le serveur tournant sur le port 3307, on signale au client mysql qu’il faudra utiliser ce port particulier, on pointe vers la socket du serveur qui a été renommée.

L’entête “mysqld_safe” permet de ne pas spécifier en ligne de commande de mysqld_safe le répertoire dans lequel est contenu les binaires, celui-ci est indiqué par la variable “ledir”.

L’entête “mysqld” spécifie que notre serveur MySQL doit tourner en mode NDB (ndbcluster). Sans cet ajout, notre serveur MySQL ne serait pas considéré comme un élément du cluster.

On distingue également la première apparition de la connecstring, celle-ci est composée dans sa version la plus simple d’un nom de machine auquel on ajoute éventuellement un port particulier. Dans le cas par défaut comme ici, le port choisi est le 1186, inutile de le spécifier. Si vous aviez choisi de faire tourner deux cluster MySQL sur la même machine (pour tester la réplication inter-cluster par exemple), il est possible de jouer sur ce paramètre afin de séparer les deux.

Les sockets sont renommées afin de ne pas réutiliser les noms utilisés couramment.

“basedir” et “datadir” sont spécifiés vu que nous avons installés MySQL dans un répertoire qui n’est pas celui par défaut. Si vous rencontrez des erreurs du type “can’t find message file share/english/errmsg.sys”, c’est soit… un bug de votre version, soit un mauvais paramétrage de ces variables, essayez également de jouer avec l’option “language” du serveur mysqld afin de pointer vers les bons fichiers.

Enfin, la catégorie “mysql_cluster” permet de définir des informations valables pour plusieurs exécutables du cluster : ndbd (démarrage des noeuds), ndb_mgmd (Management server node), ndb_mgm (Management client), ndb_restore… C’est donc l’endroit adéquat pour stocker une connectstring par exemple.

Nous aurions pu remplacer [mysql_cluster] par :

[ndbd]
ndb-connectstring = 127.0.0.1
[ndb_mgmd]
ndb-connectstring = 127.0.0.1
[ndb_mgm]
ndb-connectstring = 127.0.0.1
…

C’est d’ailleurs de cette façon qu’est conçu le my.cnf proposé sur le site de MySQL.

L’installation se poursuit ensuite de façon classique :

/usr/local/ndb6215# ./scripts/mysql_install_db –defaults-file=/etc/my6215.cnf –user=mysql –basedir=/usr/local/ndb6215 –datadir=/usr/local/ndb6215/data

La nouveauté dont nous avons parlé : la configuration du fichier config.ini du Management Server (MGM node, le squelette du fichier ci-dessous est tiré d’un fichier fourni par MySQL dans le répertoire “support_files” :

/usr/local/ndb6215/support-files# cp ndb-config-2-node.ini /var/lib/mysql-cluster/config.ini

# Example Ndbcluster storage engine config file.
[ndbd default]
NoOfReplicas= 2
HostName= 127.0.0.1
DataDir= /var/lib/mysql-cluster

[ndb_mgmd default]
DataDir= /var/lib/mysql-cluster
HostName= 127.0.0.1

[ndb_mgmd]
Id=10

[ndbd]
Id= 20

[ndbd]
Id= 21

[mysqld]
Id= 30

[mysqld]
Id= 31

Quelques remarques concernant ce config.ini :

“NoOfReplicas” spécifie le nombre de copies de chaque donnée du cluster, nous approfondirons ce terme au prochain épisode.

“Datadir” définit un répertoire pour les fichiers de logs, d’erreur, de pid, des noeuds.

Chaque élément du cluster est référencé dans le config.ini. Le management serveur lui-même (id=10), les deux datas nodes (id 20 et 30), et notre serveur mysql (id=40). Avec le dernier “emplacement” (id=50), on signale au cluster qu’un serveur mysql est susceptible de se rajouter à l’ensemble, c’est une sorte de réservation, nous aurions procédé de même pour les datas nodes.

Les ID des noeuds sont facultatifs, ils sont indiqués ici pour clarifier les étapes.

// Démarrage du management server
/usr/local/ndb6215# ./bin/ndb_mgmd -f /var/lib/mysql-cluster/config.ini

Une fois le MGM node démarré, on peut lancer le client correspondant et afficher un premier état de la situation du cluster :

/usr/local/ndb6215# ./bin/ndb_mgm –defaults-file=/etc/my6215.cnf

-- NDB Cluster -- Management Client --
ndb_mgm> SHOW
Connected to Management Server at: localhost:1186
Cluster Configuration
———————
[ndbd(NDB)]    2 node(s)
id=20 (not connected, accepting connect from localhost)
id=21 (not connected, accepting connect from localhost)

[ndb_mgmd(MGM)]    1 node(s)
id=10 @127.0.0.1 (mysql-5.1.23 ndb-6.2.15)

[mysqld(API)]    2 node(s)
id=30 (not connected, accepting connect from any host)
id=31 (not connected, accepting connect from any host)

Nos noeuds sont bien référencés, seul notre Management Server est lancé, c’est d’ailleurs grâce à lui que le Management Client (ndb_mgm) a pu se connecter.

Reste à connecter les noeuds suivants, c’est autour des Datas Nodes puis du SQL Node :

// Démarrage des Datas Nodes
/usr/local/ndb6215# ./bin/ndbd –defaults-file=/etc/my6215.cnf –ndb-nodeid=20
/usr/local/ndb6215# ./bin/ndbd –defaults-file=/etc/my6215.cnf –ndb-nodeid=21

// Démarrage du serveur MySQL, on effectue un démarrage classique :
/usr/local/ndb6215# ./bin/mysqld_safe --defaults-file=/etc/mycluster.cnf &

Appliquons à nouveau la commande SHOW dans le Management Client :

ndb_mgm> show
Cluster Configuration
---------------------
[ndbd(NDB)]    2 node(s)
id=20 @127.0.0.1 (mysql-5.1.23 ndb-6.2.15, Nodegroup: 0, Master)
id=21    @127.0.0.1 (mysql-5.1.23 ndb-6.2.15, Nodegroup: 0)

[ndb_mgmd(MGM)]    1 node(s)
id=10    @127.0.0.1 (mysql-5.1.23 ndb-6.2.15)

[mysqld(API)]    2 node(s)
id=30    @127.0.0.1 (mysql-5.1.23 ndb-6.2.15)
id=31 (not connected, accepting connect from any host)

Cette fois-ci tous les noeuds sont connectés, on remarque l’emplacement laissé libre pour un éventuel nouveau serveur MySQL (id=31).

Le serveur MySQL étant désormais lancé, n’oubliez pas d’ajuster votre politique de sécurité avec l’utilisation du script mysql_secure_installation par exemple, voir le billet consacré à ce sujet.

Connectons-nous à la base :

/usr/local/ndb6215#./bin/mysql –defaults-file=/etc/my6215.cnf -uroot -p

Server version: 5.1.23-ndb-6.2.15-cluster-gpl MySQL Cluster Server (GPL)

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> show schemas;
+——————–+
| Database
+——————–+
| information_schema
| mysql
+——————–+
2 rows in set (0.00 sec)

Notre cluster est fonctionnel.

Pour l’arrêter, on utilise le Management Client :

ndb_mgm> SHUTDOWN
2 NDB Cluster node(s) have shutdown.
Disconnecting to allow management server to shutdown.

Pour stopper le serveur MySQL on peut utiliser mysqladmin :

/usr/local/ndb6215# ./bin/mysqladmin –defaults-file=/etc/my6215.cnf shutdown -uroot -p

N’hésitez pas à tester par vous-même les précédentes étapes, elles constituent le point de départ de futurs articles sur le sujet.

Fonctionnement du script

Rien de plus simple que d’aller fouiller dans les entrailles de mysql_secure_installation puisque c’est un script shell.
En quelques mots, le script ne supporte aucune option et construit son propre my.cnf temporaire qu’il va ensuite passer en paramètre au client mysql :

mysql --defaults-file=fichier_my.cnf_temporaire

Le script utilise donc le client mysql pour passer ses requêtes. Les seules lignes que comptent ce my.cnf temporaire sont les suivantes, elles sont inscrites dans le fichier dès lors que vous fournissez le mot de passe root :

# mysql_secure_installation config file
[mysql]
user=root
password=xxxxxxxx

C’est tout !

Dans un tel cas, le comportement de mysql par défaut sous unix est tout simplement de chercher à se connecter au port 3306 d’un serveur localhost au travers d’une socket. Impossible donc de demander à mysql_secure_installation de se connecter à un serveur distant ou de tenter la connexion sur un autre port…

Ce manque d’options disponibles ne date pas d’hier et a déjà fait l’objet d’une remontée de “bug“, transformée en “feature request” puisqu’en effet il s’agit plutôt de cela.

Un patch a été proposé par Daniel Fischer, en charge du “bug” chez MySQL, il permet de configurer le port et la socket.

A des fins de tests j’avais pour ma part simplement rajouté quelques lignes dans mysql_secure_installation. D’abord au tout début du script :

# Assigne l'ip et le port à partir des 1er et 2nd paramètres, ex :
# mysql_secure_installation 127.0.0.1 3307
cmd_line_ip="$1"
cmd_line_port=”$2″

Puis dans la fonction make_config() qui construit le my.cnf temporaire :

make_config() {
echo "# mysql_secure_installation config file" >$config
echo "[mysql]” >>$config
echo “user=root” >>$config
echo “password=$rootpass” >>$config
if [ $# == 2 ]; then
echo “host=$cmd_line_ip” >>$config
echo “port=$cmd_line_port” >>$config
fi
}

Une fois généré le my.cnf ressemble à ceci :

# mysql_secure_installation config file
[mysql]
user=root
password=xxxxxxxx
host = 127.0.0.1
port = 3307

Grâce à ces deux options supplémentaires, le client mysql se connecte par TCP et le port est pris en compte, j’ai donc pu faire “pointer” mysql_secure_installation vers mon serveur MySQL (3307).

Autre façon de faire, tout simplement taper manuellement les requêtes effectuées quasi automatiquement par mysql_secure_installation.

Les requêtes concernées

Voici les requêtes effectuées par mysql_secure_installation :

// Met à jour le password de l’utilisateur root :
UPDATE mysql.user SET Password=PASSWORD('xxxxxxxx') WHERE User='root';

// Supprime les utilisateurs anonymes
DELETE FROM mysql.user WHERE User='';

// Supprime la possibilité à un utilisateur root de se connecter à partir d’un serveur distant
DELETE FROM mysql.user WHERE User='root' AND Host!='localhost'

// Supprime la base de données test
DROP DATABASE test;

// Supprime les privilèges associés à la base test
DELETE FROM mysql.db WHERE Db=’test’ OR Db=’test_%’

// Applique les changements effectués précedemment concernant la gestion des droits
FLUSH PRIVILEGES

Il existe d’autres façons de faire, comme par exemple utiliser mysqladmin :

mysqladmin -u root password 'new-password'

De même, pour modifier le password d’un utilisateur, plutôt que de mettre à jour directement les tables systèmes de mysql, il est conseillé de passer par les commandes suivantes :

mysql> SET PASSWORD FOR 'jeffrey'@'%' = PASSWORD('biscuit');
ou
mysql> GRANT USAGE ON *.* TO 'jeffrey'@'%' IDENTIFIED BY 'biscuit';

La commande FLUSH PRIVILEGES est alors inutile.

On obtient :

Benchmark
Average number of seconds to run all queries: 1.121 seconds
Minimum number of seconds to run all queries: 1.015 seconds
Maximum number of seconds to run all queries: 1.265 seconds
Number of clients running queries: 200
Average number of queries per client: 5

Nous avons ici 200 clients concurrents dont on limite le nombre de requêtes à 1000 au total, ce qui nous donne environ 5 requêtes par client.

En rajoutant la clause –csv et une concurrence variable :

undercat@u200:/usr/local/mysql5125$ ./bin/mysqlslap --user=mysql –csv=/tmp/slap.csv –concurrency=1,10,50,100,200 –iterations=10 --query="USE world;SELECT SQL_NO_CACHE ci.name, co.name from City ci, Country co where ci.countrycode = co.code and ci.name like 'c%'"

J’utilise ici SQL_NO_CACHE afin de ne pas placer la requête dans le query cache, ce qui fausserait les tests.

L’option –csv couplé à openoffice / impress par exemple, permet de créer rapidement un graphique issu de nos tests. Ci-dessous le csv généré et le graphique  :

undercat@u200:/tmp$ cat slap.csv
,mixed,0.002,0.000,0.004,1,1
,mixed,0.015,0.011,0.027,10,1
,mixed,0.063,0.061,0.068,50,1
,mixed,0.133,0.122,0.205,100,1
,mixed,0.245,0.105,0.298,200,1



supersmack

Disponible sur http://vegan.net/tony/supersmack/, cet outil n’évolue plus depuis trois ans mais il reste intéressant ! Initialement développé par Sasha Pachev (un ancien de chez MySQL), puis retouché par plusieurs autre contributeurs dont Jéremy Zawodny, supersmack est moins intuitif que mysqlslap mais il se rattrape par ailleurs puisqu’il est plus largement disponible (pas seulement sur MySQL 5) et offre des réglages plus fins. Il est notamment possible de construire dynamiquement une requête à partir d’un “dictionnaire”… supersmack peut en effet “piocher” dans un fichier texte une liste d’identifiants par exemple, nous verrons comment.

Note : en plus des avantages suscités, supersmack peut également être interfacé avec PostgreSQL et Oracle.

Installation de supersmack

Le binaire n’étant pas distribué avec mysql, nos tests sous supersmack vont nécessiter quelques étapes supplémentaires.

Première étape, récupérer les sources :

wget http://vegan.net/tony/supersmack/super-smack-1.3.tar.gz

puis

./configure --with-mysql=/usr/local/mysql5125

A ce stade vous devriez voir s’afficher ceci :

Building with the following options:

MySQL Support………………… yes
PostgreSQL Support……………. no
Oracle Support……………….. no

Thanks for using super-smack!

Faites suivre d’un make, et make install : supersmack devait être opérationnel.

Si ça n’est pas le cas, veillez à avoir installé les paquets suivants (ubuntu) :

apt-get install libmysqlclient15-dev
apt-get install build-essential

supersmack : fonctionnement

Le répertoire /smacks contient deux exemples : select-key.smack et update-select.smack.
Prenons comme base le premier fichier et voyons comment le configurer.

Evoquée en introduction, supersmack dispose d’une fonctionnalité très pratique dans certains cas, il s’agit du “dictionnaire”. Ce dernier permet de construire des requêtes dynamiques, comme si votre requête était directement issue de votre script. Exemple :

SELECT Capital FROM Country WHERE Code = “$code_pays”

Difficile d’exécuter une telle requête avec mysqlslap… Il faudrait s’arranger pour récupérer le code pays via une jointure mais dans certains cas cette information n’est tout simplement pas disponible. Il se peut que vous souhaitiez exécuter une série de requête construites dynamiquement à partir d’informations contenues dans un fichier.

Construisons à titre d’exemple un tel dictionnaire à partir de l’une de nos tables (la fameuse base “world” est encore une fois mise à contribution).

mysql> select distinct(countrycode) into outfile '/tmp/code_pays_pop_under_2M.txt' from City where population < 2000000;

On a ainsi exporté dans /tmp/code_pays_under_2M.txt la liste des codes pays qui possèdent des villes inférieures à 2 000 000 d’habitants. Le fichier contient des lignes stockés sous la forme suivante :

AFG
NLD
ANT
…

Notre “dictionnaire” désormais construit, supersmack pourra y piocher les informations requises et construire dynamiquement nos requêtes.

Voyons maintenant à quoi ressemble un fichier .smack. Nous partons ici du fichier select-key.smack pour construire un dbnewz.smack allégé pour notre exemple :

//define a dictionary
dictionary “code_pays”
{
type “rand”; // autres valeurs possibles : “seq” ou “unique”
source_type “file”; // nous utiliserons le fichier contenant nos codes pays
source “/tmp/code_pays_pop_under_2M.txt”; // emplacement du fichier “dictionnaire”
delim “,”; // take the part of the line before ,
file_size_equiv “45000″; // if the file is greater than this
//divide the real file size by this value obtaining N and take every Nth
//line skipping others. This is needed to be able to target a wide key
// range without using up too much memory with test keys
} 

//define a query
query “find_capital”
{
query “SELECT SQL_NO_CACHE ci.Name, ci.Population
FROM City ci
INNER JOIN Country co ON ci.CountryCode = co.Code
WHERE co.Code = ‘$code_pays’”;
type “req_code_pays”; // libellé de votre requete, permet de s’y retrouver dans les resultats
has_result_set “y”; // On attend des resultats (a la difference d’un UPDATE par ex).
parsed “y”; // signale que supersmack doit construire dynamiquement la requete a partir du dictionnaire
}

// define database client type
client “dbnewz”
{
user “root”; // connect as this user
pass “XXXXXXX”; // use this password
host “localhost”; // connect to this host
db “world”; // switch to this database
#socket ” /var/run/mysqld/mysqld.sock”;  // j’utilise ici la valeur de SHOW VARIABLES LIKE ’socket’;
query_barrel “1 find_capital”; // Execute 1 fois la requete “find_capital” a chaque iteration.
}

main
{
dbnewz.init(); // initialize the client
dbnewz.set_num_rounds($2); // le 2eme argument recu par supersmack est le nombre d’iterations.
dbnewz.create_threads($1); // permet de definir combien de clients simultanés l’on souhaite.
dbnewz.connect();
dbnewz.unload_query_barrel(); // for each client fire the query barrel
dbnewz.collect_threads();
dbnewz.disconnect();
}

Il est également possible pour supersmack de créer automatiquement les tables dans lesquelles se dérouleront les tests, ouvrez le fichier select-key.smack pour davantage d’informations, il fournit la syntaxe relative à cette fonctionnalité.

Nous pouvons désormais lancer le test, ici 50 clients concurrents et 1000 itérations :

root@u200:/opt/super-smack-1.3/smacks# super-smack dbnewz.smack 50 1000

Query Barrel Report for client dbnewz
connect: max=888ms  min=7ms avg= 213ms from 50 clients
Query_type    num_queries    max_time    min_time    q_per_s
req_code_pays    50000    41    1    1327.08

Nous avons ici obtenu en moyenne 1327 requêtes / seconde pour cette requêtes et 50 clients concurrents entre le début et la fin de nos tests.

Connecté sur le serveur MySQL en question, on observe via un SHOW FULL PROCESSLIST des requêtes du type :

SELECT SQL_NO_CACHE ci.Name, ci.Population
FROM City ci
INNER JOIN Country co ON ci.CountryCode = co.Code
WHERE co.Code = ‘LKA’

Le code ‘LKA’ a été remplacé par supersmack lui-même, le dictionnaire a donc bien fonctionné.

Vous venez de faire connaissance avec ces deux outils de benchmark (si ça n’était pas déjà fait), pensez à les utiliser lors de vos prochaines évaluations de performance (serveur / requêtes). Il est en effet toujours appréciable de pouvoir qualifier la situation de départ afin de mesurer l’étendue des progrès effectués par la suite.

Quelle est la différence avec un forum? Nous retenons les meilleures questions et nous écrivons un article avec la dite question et sa réponse. Si vous ne voyez pas votre question, c’est que nous n’avons pas encore eu le temp d’y répondre…

A très bientôt!

PS: Cette adresse peut aussi être utilisée si vous constatez un problème sur le site…

Trois semaines d’attente, cela mérite un billet digne de ce nom, c’est parti.

Indexer, pourquoi ?

L’indexation peut avoir plusieurs buts :
- Accéder à ses données plus rapidement, les index sont en effet l’outil le plus puissant pour accélérer les temps d’exécution de vos requêtes jusqu’à parfois plusieurs centaines de % !
- Définir le degré d’unicité d’une colonne donnée : chaque champ doit-il être unique ? les doublons sont-ils autorisés ?

Principe de fonctionnement

Lorsque vous envoyez une requête à votre serveur MySQL, celle-ci est d’abord confiée au “parseur” SQL qui a pour but de vérifier si la syntaxe de votre demande est correcte. Cette étape franchie, la requête passe par “l’optimiseur”. Il s’agit ici de déterminer le plan d’exécution de la requête afin que celle-ci s’exécute le plus rapidement possible.

L’optimiseur détecte si d’éventuels index sont disponibles, si c’est le cas il décidera de s’en servir… ou pas : il est parfois plus rapide de ne pas se servir d’un index ! Nous verrons pourquoi au cours de cette série d’articles.

Une fois le plan d’exécution achevé, c’est le moteur de stockage qui prend le relais, celui-ci peut être vu comme un “module” de MySQL :

Pour schématiser, et dans un monde idéal, lorsqu’un index est disponible et “compatible” avec votre requête, l’optimiseur MySQL peut décider de l’utiliser afin d’éviter de parcourir l’ensemble des données des tables concernées.

Un exemple couramment employé pour illustrer ce propos consiste à imaginer la difficultée que nous aurions à retrouver quelqu’un dans l’annuaire si nous connaissions son nom mais pas l’alphabet (qui est notre index)… Transposé au monde informatique cela donne un serveur MySQL qui compare une à une les entrées du botin pour trouver toutes celles qui correspondent au nom recherché. Si au contraire ce nom est indexé, et si celui-ci commence par exemple par ‘T’, le serveur sait directement qu’il doit démarrer sa recherche à partir du ‘T’. Imaginez l’impact en terme de gain de temps lorsque plusieurs jointures sont concernées : deux tables de 10 000 lignes chacune forment un produit cartésien de 100 000 lignes environ à étudier…

Les index n’ont hélas pas que des avantages :
- Les opérations de mises à jour (INSERT, UPDATE, DELETE) sont en effet ralenties puisqu’en plus des données, les index doivent eux aussi être mis à jour lors de ces opérations, c’est le prix à payer… Ce prix peut néamoins se “négocier”, nous verrons cela plus tard.

Notre terrain de jeu, la base “world”

MySQL propose au téléchargement plusieurs bases d’exemple dont “world” et “sakila”. Elles épargnent le soin aux utilisateurs de MySQL souhaitant tester quelques requêtes de se constituer eux-mêmes une base de test, celles-ci sont prêtes à l’emploi.

Nous utiliserons pour nos tests la base “world”. Très simple puisque constituée uniquement de trois petites tables MyISAM (Country, CountryLanguage et City), elle permet de se concentrer uniquement sur les index sans perdre de temps à assimiler un schéma plus complexe.

Si vous souhaitez transformer le script de création SQL de la base “world” en une version graphique “presque” MCD (les relations entre les tables ne sont pas générées automatiquement pour cette base), le billet précédent est fait pour vous, les étapes d’installation et de génération du MCD par “reverse engineering” avec DBDesigner 4 y sont décrites.

Voici ce qu’on peut obtenir pour cette base à partir de DBDesigner :

Quel type d’index choisir : PRIMARY KEY, UNIQUE, ou INDEX ?

Choisissez le type de vos index avec soin :
- Une clé primaire (PRIMARY KEY) est strictement unique, les NULL ne sont pas autorisés.
- Un index de type UNIQUE est comparable à une clé primaire, mis à part pour les valeurs NULL puisque celles-ci sont autorisées (et potentiellement en plusieurs occurences).
- Un index de type INDEX ou KEY (c’est un alias) signifie simplement que l’on souhaite indexer une colonne susceptible de contenir des doublons.

Les index de type FULLTEXT et SPATIAL sont particuliers et méritent un épisode à eux seuls, ils seront donc évoqués ultérieurement.

Passons rapidement sur l’étape de déclaration d’un index, celle-ci s’effectue soit au moment de la création de la table, soit plus tard comme ici :

mysql> CREATE INDEX idx_district ON City (District);
Query OK, 4079 rows affected (0.04 sec)
Records: 4079  Duplicates: 0  Warnings: 0

Nous venons de créer un index de type INDEX (autorise les doublons) sur la colonne District de la table City.

Attention, si nous avions tenté la même chose avec un index de type UNIQUE…

mysql> CREATE UNIQUE INDEX idx_district ON City (District);
ERROR 1062 (23000): Duplicate entry ‘Zuid-Holland’ for key 2

… MySQL nous signale qu’il y’a déjà des doublons dans la colonne District, impossible donc de créer un index de type UNIQUE sur celle-ci.

Pour supprimer cet index :
mysql> DROP INDEX idx_district ON City;
Ou :
mysql> ALTER TABLE City DROP INDEX idx_district;

Pour visualiser les index d’une table :

mysql> SHOW INDEX FROM Country;

Attention aux doublons !

Inutile de rajouter un index de type “INDEX” ou encore “UNIQUE” sur un champ qui est déjà clé primaire par exemple… Vous dupliqueriez inutilement les index avec à la clé un gaspillage d’espace disque/mémoire, des ralentissements inutiles lors des mises à jour, davantage de travail pour l’optimiseur…

Quels types de champ indexer ?

INT, VARCHAR, BLOB… ? Quels sont les meilleurs candidats à l’indexation ?

Plus l’index est court, mieux c’est : un index est en permanence comparé à d’autres valeurs (celles recherchées), ces comparaisons sont plus rapides si la zone à comparer est plus courte. Des index concis occupent également moins de place sur disque, génèrent moins d’I/O (activité disque s’ils ne sont pas en mémoire) et peuvent ainsi être stockés en plus grand nombre dans une même quantité de RAM (pensez au key_buffer_size de MyISAM par exemple).

Bref, si vous désirez stocker une liste de noms de villes sous forme de chaînes de caractères, sachez qu’il est inutile de réserver un champ de type CHAR(255) : rares sont celles qui atteindront cette longueur, pensez plutôt au VARCHAR qui s’adaptera à la longueur de vos valeurs.
Plus malin encore, lors de la conception de votre base de données, intéressez-vous aux différentes formes de normalisation : 1NF, 2NF, 3NF, ces méthodes permettent d’obtenir un schéma qui permet de partir sur de bonnes bases.
En gardant cet exemple des villes, si vous stockez dans une table “inscrits” toutes les infos contextuelles à un utilisateur, dont sa ville, envisagez de stocker dans une table “ville”, toutes les infos qui s’y rapportent : nom, population, etc. Reliez ensuite votre table “inscrits” à la table “ville” par la valeur de la clé primaire de ville et vous supprimerez ainsi tous ces libellés de villes identiques au profit d’un ID bien plus rapide et économique.

Soyez radins !

Vos index seront d’autant plus efficaces s’ils sont apposés sur des champs bien adaptés à vos données. Ne gaspillez pas le capital “performance” de vos index en utilisant un INT pour stocker par exemple la vitesse légale sur autoroute en France (par temps sec) : 130 km/h…  Un TINY INT UNSIGNED suffira (permet de stocker les valeurs de 0 à 255). Un INT permet lui de stocker des valeurs comprises entre -2.147.483.648 2.147.483.647, et en rajoutant l'attribut UNSIGNED, on obtient un rayon d’action de 0 à plus de 4 milliards ! A quoi bon utiliser un INT dans cet exemple ? Quand on sait de plus qu’un INT occupe quatre fois plus de place qu’un TINY INT, l’impact sur les performances et la perte d’espace avec une table de plusieurs millions d’enregistrements est évident…

Prenez connaissance des caractéristiques des types de données que vous utilisez. Visualisez également la taille requise, c’est un élement qui peut s’avérer dissuasif.

Pour résumer, n’indexez pas une colonne en fonction de son type, mais prenez soin dans un premier temps de définir celles-ci avec le type de données qui leur convient le mieux, le plus économique. Prévoyez une marge néanmoins : n’utilisez pas un TINY INT même UNSIGNED pour un identifiant de clé primaire AUTO_INCREMENT concernant une newsletter d’un grand service commercial : si tout se passe bien vous devriez rapidement dépasser le seuil des 255 inscrits… Le type de données juste “au-dessus”, SMALLINT UNSIGNED, qui permet d’aller jusqu’à 65535, est sans doute plus confortable.

Le tips dbnewz : utilisez la commande PROCEDURE ANALYSE()

Cette commande analyse pour vous vos tables et vous propose le type idéal pour vos données… si vous en avez bien sûr, ça ne peut pas vous aider lors d’une création de table. En revanche, elle permet “d’auditer” vos enregistrements actuels, d’en tirer quelques statistiques et propose le type le plus adapté :

mysql> SELECT Name FROM Country PROCEDURE ANALYSE(10,256)\G
Field_name: world.Country.Name
Min_value: Afghanistan
Max_value: Zimbabwe
Min_length: 4
Max_length: 44
Empties_or_zeros: 0
Nulls: 0
Avg_value_or_avg_length: 10.0962
Std: NULL
Optimal_fieldtype: VARCHAR(44) NOT NULL
1 row in set (0.00 sec)

Vous pouvez bien sûr effectuer cette requête sur l’intégralité des champs de l’une de vos tables (SELECT *…)
Les paramètres fournis à PROCEDURE ANALYSE () sont à modifier en fonction de vos souhaits. Par défaut cette fonction a tendance à vouloir transformer toutes vos chaînes de caractères en champs ENUM (stockés sous forme numérique en interne), à vous de définir combien de champs ENUM vous êtes prêts à utiliser. Réservez-les pour les cas où le champ représente une courte liste “fermée”, ex “M” ou “F”, les jours de la semaine par exemple, etc.

Où placer ses index : quels sont les champs à indexer ?

Les champs concernés par une clause WHERE, ORDER BY, GROUP BY, MIN(), MAX(), ainsi que les champs qui permettent de relier des tables entre elles, sont de bons candidats à l’indexation, exemple :

SELECT ci.Name, ci.Population
FROM City ci INNER JOIN Country co ON ci.CountryCode = co.Code
WHERE ci.Population > 5000000
ORDER BY ci.District ASC LIMIT 3

- Le champ CountryCode de la table City ainsi que le champ Code de la table Country sont tous les deux à indexer. C’est d’ailleurs le cas ici puisque ces deux champs sont respectivement clés primaires de la table City et Country.
- Le champ Population est intéressant à indexer, il permet à MySQL de parcourir très rapidement les villes par leur population triée et évite de comparer l’intégralité des populations de chaque ville, une à une.
- Le champ District est également un candidat à l’indexation, il peut aider MySQL à trier les données plus rapidement.

A retenir : on indexe en priorité les champs impliqués dans les clauses évoqués ci-dessus (en gras), pas forcément ceux présents dans le SELECT.

Les index composés (ou multiples) et la règle du leftmost prefixing

“Faut-il préférer un index unique ou composé” était l’une des questions posées par l’un d’entre vous il y’a quelques semaines…

Un index composé doit se construire en fonction des requêtes que vous effectuez sur la table concernée.
Prenons pour exemple la table City et ses cinq champs (ID, Name, CountryCode, District, Population).

Si les seules requêtes que vous avez sur City sont du type :

SELECT ... FROM City WHERE Name = "..."

… Indexez Name et tout ira bien.

Si en revanche il vous arrive de trier non seulement sur “Name” mais également sur le code du pays :

SELECT ... FROM City WHERE Name = "..." AND CountryCode = "..."

Dans ce cas, plutôt que de laisser MySQL comparer tous les CountryCode de la table avec votre recherche (ex : “FRA”), indexez la colonne CountryCode… Oui mais pas toute seule !
Considérez en effet pour l’instant que MySQL n’utilise qu’un index par table, l’optimiseur MySQL choisit donc le plus restrictif afin que votre requête s’exécute le plus rapidement possible (nous verrons plus tard les cas particuliers où MySQL peut tirer parti de plusieurs index).
Conséquence, il vous faut trouver un index qui soit utilisable pour vos deux critères de recherche : “Name” et “CountryCode”. La solution : créez un index multiple sur ces deux champs.

Dès lors que vous utilisez un index multiple, la règle du leftmost prefixing rentre en jeu. Trop souvent méconnue, elle permet pourtant de créer ses index de façon efficace et d’éviter les doublons.

Afin d’illustrer cette règle, ajoutons cette fois à la table City un index multiple sur les champs Name, CountryCode, District et Population :

mysql> CREATE INDEX name_cc_dis_pop ON City (Name, CountryCode, District, Population);

Voici ce que l’on obtient avec le SHOW INDEX correspondant (la clé primaire existait déjà à la création de la table, ci-dessous une vue partielle des résultats réels) :

mysql> SHOW INDEX FROM City;


| Key_name | Seq_in_index | Column_name
+——-+————+—————–+

|name_cc_dis_pop |   1 |  Name

|name_cc_dis_pop |   2 | CountryCode

|name_cc_dis_pop |   3 | District

|name_cc_dis_pop |   4 | Population | 
+——-+————+—————–+

On remarque par rapport au SHOW INDEX précédent que cette fois-ci nous avons la colonne “Seq_in_index” qui s’incrémente pour chaque colonne qui compose notre index multiple. La position de chaque index dans cette séquence a une importance, c’est ce que nous allons voir maintenant.

Tel quel, cet index multiple sera potentiellement utilisé pour les requêtes de ce type :

SELECT ... FROM City WHERE Name = ... AND CountryCode = ... AND District = ... AND Population = ...
SELECT … FROM City WHERE Name = … AND CountryCode = … AND District = …
SELECT … FROM City WHERE Name = … AND CountryCode = …
SELECT … FROM City WHERE Name = …

Une fois cette “logique” acquise, on comprend qu’il est inutile de rajouter un index sur Name par exemple puisque cette colonne est déjà indexée grâce à cet index multiple. Idem pour notre exemple précédent  d’index multiple concernant les champs Name et CountryCode, là encore inutile de recréer un index sur ces deux champs puisque ces derniers sont déjà représentés dans notre dernier exemple.

En revanche, si l’ordre de vos champs ne respecte pas l’ordre de séquence de votre index, comme ici :

SELECT ... FROM City WHERE Name = ... AND Population = ..

Cette requête ne bénéficiera pas complètement de l’index multiple précedemment crée, cela dit l’optimiseur tirera sûrement parti de cet index pour la colonne Name, mais pas pour le second critère de recherche.

De même si votre requête est du type :

SELECT ... FROM City WHERE CountryCode = ...
SELECT … FROM City WHERE District = …
SELECT … FROM City WHERE Population = …
SELECT … FROM City WHERE CountryCode = … AND District = … AND Population = …

… et autres variations qui ne débutent pas avec “Name” et ne respectent pas ensuite l’ordre de séquence de l’index (Name, CountryCode, District, et Population), l’index ne sera pas utilisé.

En conséquence, il est donc tout à fait légitime d’indexer par ailleurs la colonne Population seule si vous avez des requêtes du type :

SELECT ... FROM City WHERE Population > ...

Mesurez l’efficacité des index avec EXPLAIN

Impossible d’évoquer les index sans parler de la commande EXPLAIN. Absolument fondamentale, elle affiche le plan d’exécution décidé par l’optimiseur MySQL et vous permet de mesurer si oui ou non vos index sont réellement utilisés.

Reprenons une des premières requêtes de ce billet et rajoutons-lui le mot clé EXPLAIN :
(on considère ici que la table City ne contient que sa clé primaire, pas les index rajoutés précedemment)

mysql> EXPLAIN SELECT ci.Name, ci.Population
FROM City ci INNER JOIN Country co ON ci.CountryCode = co.Code
WHERE ci.Population > 5000000
ORDER BY ci.District ASC LIMIT 3\G


*************************** 1. row *************
id: 1
select_type: SIMPLE
table: ci
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4079
Extra: Using where; Using filesort
*************************** 2. row *************
id: 1
select_type: SIMPLE
table: co
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 3
ref: world.ci.CountryCode
rows: 1
Extra: Using index
2 rows in set (0.00 sec)

La commande EXPLAIN sera étudiée plus précisemment dans un autre épisode, pour le moment contentons-nous de prêter attention aux champs en gras :

- Sur la première ligne le type ALL signale que MySQL doit effectuer un “full table scan” c’est à dire parcourir entièrement la table City qui compte 4079 enregistrements, ceci afin de repérer quelles sont les villes qui ont une population supérieure à 5M d’habitants. Aucun index/key n’a pu être utilisé (possible_keys : NULL) pour résoudre cette partie de la requête. La colonne “rows” indique le nombre approximatif d’enregistrements que MySQL pense devoir analyser pour mener à bien l’opération.

- La seconde ligne nous indique que cette fois MySQL a un candidat pour l’indexation, il s’agit de la clé primaire de la table Country, la jointure s’effectuant avec le champ “CountryCode” de la table City, qui est également une clé primaire. Résultat : MySQL effectue la correspondance très rapidement (rows : 1 et extra : Using index).

Ceci répond à une des questions posées précedemment par un lecteur : “Quand préférer le FULL TABLE SCAN à l’index ?” C’est en fait le travail de l’optimiseur, il doit déterminer si oui ou non un index vous fera gagner du temps. Il se peut qu’il se trompe (rarement), nous verrons comment orienter ses choix si besoin.

Rajoutons maintenant un index de type “INDEX” sur la colonne Population :

mysql> CREATE INDEX idx_pop ON City (Population);

Puis appliquons à nouveau la même commande EXPLAIN, on obtient cette fois :

*************************** 1. row ************
id: 1
select_type: SIMPLE
table: ci
type: range
possible_keys: idx_pop
key: idx_pop
key_len: 4
ref: NULL
rows: 25
Extra: Using where; Using filesort
*************************** 2. row ************
id: 1
select_type: SIMPLE
table: co
type: eq_ref
possible_keys: PRIMARY
key: PRIMARY
key_len: 3
ref: world.ci.CountryCode
rows: 1
Extra: Using index
2 rows in set (0.02 sec)

Notre index a permis à MySQL de lire 160 fois moins de lignes cette fois-ci par rapport à l’exemple précédent… Seules 25 lignes de la table City sont lues désormais (au lieu des 4079 lignes précedemment parcourues). C’est un gain très intéressant en termes de ressources serveur ! Amateurs de chiffres, des benchmarks sont prévus dans la suite de cette série.

Afin de patienter jusqu’aux prochains épisodes justement, vous pouvez commencer par appliquer les quelques conseils de ce billet tout en relisant pourquoi pas l’article concernant l’implémentation des index (BTREE ou HASH) selon le type de votre moteur de stockage (MyISAM, InnoDB ou MEMORY).

Il reste certaines de vos questions en suspens, elles ne sont pas oubliées et seront débattues ici très prochainement.

Si vous avez des questions ou des remarques concernant cette première étape, n’hésitez pas.

Cet outil n’est pas nouveau, son successeur officiel est même déjà connu, il s’agit de MySQL Workbench. Celui-ci n’étant pas encore disponible sous linux, nous utiliserons son ancêtre et plus particulièrement sa fonctionnalité de “reverse engineering” : une fois connecté à votre base, DBDesigner 4 va générer sous forme graphique vos tables, leurs descriptions, et si tout se passe bien, les relations entre vos tables.

Installation (fastidieuse) sous linux

L’installation de DBDesigner 4 sous linux (ubuntu 8.04 pour ma part) n’est pas de tout repos… J’ai rencontré toutes les erreurs potentielles croisées sur les différents tutoriels sur le sujet. Résultat des courses : il apparaît plus simple d’installer DBDesigner 4 en passant par wine, les problèmes de librairies manquantes disparaissent et les polices sont plus travaillées.
Si néanmoins vous souhaitez vous passer de wine, voici quelques pistes : http://wiki.splitbrain.org/dbdesigner et un how-to tiré des forums ubuntu. Des solutions sont proposées pour ces fameuses libraries manquantes, cela dit j’avais toujours des problèmes malgré ces manipulations.

Une fois wine installé (apt-get install wine), téléchargez simplement le fichier d’installation de DBDesigner 4 pour windows.

L’installation s’effectue simplement :

root@u200:/opt# wine DBDesigner4.0.5.6_Setup.exe

Si vous êtes sous MySQL 5, vous devez modifier le mot de passe de l’utilisateur à partir duquel vous vous connectez à DBDesigner de la façon suivante :

mysql> SET PASSWORD FOR 'dbdesign'@'localhost' = OLD_PASSWORD('dbdesign');

Depuis sa version 5, MySQL utilise en effet un mécanisme d’authentification qui est incompatible avec les versions précédentes (< 4.1). Afin d’assurer une rétro compatibilité, il est néanmoins possible avec MySQL 5 d’utiliser la commande “OLD_PASSWORD“, le format utilisé pour le mot de passe sera alors compatible avec MySQL 4 (short hash contre long hash pour MySQL 5).

Lancement de l’application:

root@u200:~/.wine/drive_c/Program Files/fabFORCE# wine DBDesigner4.exe

Obtenir le schéma de sa base

Pour générer votre MCD, et selon votre langue d’installation :

- Choisissez le menu “Database”, puis “Reverse Engineering”.

- Selectionnez une connexion à la base de données ou créez la vôtre : “Localhost 127.0.0.1″ par exemple, puis renseignez vos login/pwd et validez, n’oubliez pas la commande “OLD_PASSWORD” si besoin.

- La fenêtre “Reverse Engineering” affiche alors la liste des tables de la base, par défaut elles sont toutes cochées. Remarquez un peu plus bas l’option “Build Relations“, cochez-là puis indiquez “Build Relations based on primary keys”. C’est grâce à cette option que vous indiquez à DBDesigner de relier vos tables entre elles (si possible).

- Si tout s’est bien passé, l’étape suivante affiche vos tables, leurs champs, leurs clés…

Remarques :

- DBDesigner ne parvient pas à joindre les tables de la base “world” entre elles, les noms des clés primaires sont différents et les clés étrangères absentes de la définition des tables (MyISAM), vous pouvez néanmoins rajouter vos différentes relations à la main.

- En ce qui concerne la base “sakila” les relations entre les tables sont bien présentes :

Vous pouvez à présent d’un seul coup d’oeil construire vos requêtes, les jointures entre les tables sont ici évidentes.

- La console dans laquelle vous lancez DBDesigner va peut-être contenir quelques messages d’erreur du type:

QPixmap::operator=: Cannot assign to pixmap during painting
QPopupMenu: (unnamed) Popup has invalid menu item

Cela n’a pas bloqué le comportement de l’application lors de mes tests cependant DBDesigner a la facheuse tendance à ouvrir des boites de dialogues sous les fenêtres déjà existantes, n’hésitez pas notamment lors de votre connexion à la base, à déplacer vos fenêtres (la principale et celle consacrée au reverse engineering) pour faire apparaître la boîte de dialogue vous invitant à renseigner vos identifiants de connexion. A noter qu’il existe là aussi des solutions pour régler ce problème de pop-up, cf les tutoriels cités en début d’article.

Pour explorer les autres fonctionnalités de DBDesigner 4, ou bien encore tester (sous windows uniquement pour le moment) son successeur MySQL Workbench, rendez-vous sur fabforce.net, vous y trouverez les fichiers d’installation, des captures d’écran et de la documentation.

Si vous connaissez d’autres outils intéressants disposant d’un module de “reverse engineering”, partagez-les dans les commentaires, ils sont là pour ça.

Présentation

Si vous vous demandez à quoi elles peuvent bien servir, MySQL a dressé une liste pour vous :

Une certification est censée…
- Valider votre savoir-faire
- Diminuer les risques liés à la manipulation de MySQL
- Permettre d’offrir à son entreprise une plus grande qualité de service
- Augmenter la productivité
- Réduire les coûts de maintenance
- Offrir à son détenteur une augmentation de salaire

Au-delà de cette version légèrement idéaliste/marketing et en évitant par ailleurs l’aspect souvent “polémique” concernant les certifications (les “pour”, les “contre”), ne cédons pas à la tentation du troll et voyons ce que MySQL nous propose.

Il existe aujourd’hui 4 certifications : “Associate” (CMA), “Developer” (CMDEV), “DBA” (CMDBA) et “Cluster” (CMCDBA).
Chacune d’elles vise un public souvent différent et nécessite l’obtention de un ou deux examens composés de 70 questions (sauf la “Associate” qui en compte 50).
Chaque examen est un QCM de 90 minutes (excepté la “Associate” : 60 min) dont les questions appellent de 1 à 5 réponses en général. Le “passing score” se situe autour de 43-45 / 70 environ.

Pour réserver un examen, MySQL renvoie vers les centres de passage Pearson Vue, leur site internet vous permet de repérer les centres de passage près de chez vous. Attention, tous ne sont pas listés sur le site, il se peut qu’un centre proche de vous propose en fait la certification mais ne soit pas visible… Si vous ne trouvez pas votre bonheur, à vous de contacter les centres de formation locaux, ce sont souvent ces types d’organisme qui font passer les certifications.

Une fois certifié (champagne !), et si vous le souhaitez, votre nom peut apparaître dans la liste des certifiés par pays, procédé similaire aux “pages jaunes” de Zend que certains d’entre vous connaissent peut-être.

Contrairement aux certifications Php (en tout cas à ce jour), avec MySQL vous repartez du centre d’examen avec le score détaillé de votre examen. Vos pourcentages de réussite sont affichés par chapitre. Ce type de statistiques permet de repérer ses faiblesses et évite de se demander pourquoi on a réussi ou pas l’examen… Quelque soit votre résultat vous visualiserez où sont vos forces et éventuelles faiblesses, c’est très appréciable.

Le tableau étant dressé, voyons dans le détail à quoi ressemblent ces certifications.

Dans le détail

- La certification “Associate”
Première étape vers une “reconnaissance” liée à MySQL, la certification “Associate” a pour mission de tester les candidats sur MySQL dans ses grandes lignes.
Les candidats devront prouver qu’ils connaissent les commandes de base SQL qui permettent de décrire une table, la supprimer, la vider…
Ils seront également interrogés sur les types de caractères disponibles, les jointures : consultez la liste détaillée sur le site de MySQL.
Retenez que la certification “Associate” est un sous-ensemble de la certification “Developer”.
La certification “Associate” requiert un seul examen, se déroule sur 60 minutes, comporte 50 questions et le score minimal à obtenir est d’environ 37 points.
Je n’ai personnellement pas passé celle-ci mais si c’est votre cas n’hésitez pas à nous en faire part dans les commentaires pour partager votre expérience.

- La certification “Developer”
Destinée aux développeurs ayant un minimum d’expérience avec MySQL, cette certification comporte deux examens de 70 questions. Vous aurez 90 minutes maximum pour venir à bout d’un examen. Obtenez au moins 43 bonnes réponses si vous voulez éviter les problèmes…
Voici une sélection de quelques thèmes parmi les plus représentés lors de l’examen :

Examen I

Le “client” mysql (à ne pas confondre avec le serveur “mysqld”), les types de données (un thème pas forcément sexy au premier abord mais nécessaire : gain de place, rapidité…), les tables et les index, les requêtes SQL : expressions SQL, requêtes de mises à jour, GROUP BY, UNION, etc.

Examen II

Les jointures, les sous-requêtes, les vues, les procédures stockées, les metadatas (INFORMATION_SCHEMA) et un soupçon d’optimisation.

Comme son nom l’indique, cette certification est particulièrement destiné aux développeurs qui manipulent MySQL régulièrement. Vous ne réussirez pas l’examen sans le préparer si vous faites “simplement” une petite requête de temps en temps au sein de vos scripts php par exemple. Je la conseille à tous ceux qui apprécient les diverses fonctionnalités de MySQL et qui ont envie d’aller plus loin. Préparer ces deux examens renforcera vos connaissances et vous apprendra forcément quelque chose, vous en sortirez plus polyvalents, pas forcément expert en procédure stockées mais au moins vous aurez appris à en manipuler quelques-unes et si besoin, le jour J, vous serez capables de les mettre en place rapidement.

Pour ceux qui comme moi viennent du monde du développement web, la partie I sera la plus simple, la partie II nécessite davantage de travail. On peut en effet être développeur internet depuis plusieurs années sans avoir codé la moindre procédure stockée… La gestion du temps sera également plus importante pour cette seconde partie, les questions étant plus longues et nécessitant davantage de réflexions que lors de la partie I. Je ne peux pas trop vous en dire vu que chaque candidat s’engage à ne pas communiquer sur le contenu des questions, mais vous avez l’idée générale.
Mes conseils pour se préparer aux certifications se trouvent en fin de ce billet.

- La certification “DBA”

Bienvenue aux administrateurs, et pour les autres : au boulot !
A l’instar de la certification “Developer”, la “DBA” est du même type : deux examens de 90 min chacun, 70 questions, et un passing score d’environ 45/70.

Parmi les thèmes les plus représentés, on retrouve :
Examen I
Architecture de MySQL, configuration, démarrage et arrêt du serveur, la notion de verrouillage, les moteurs de stockage (une des parties les plus importantes, spécificités de MyISAM, InnoDB, Memory…), la maintenance des tables, les sauvegardes / restaurations.

Examen II
Gestion des utilisateurs (création, droits, etc), sécurité, optimisation de requêtes, optimisation de vos bases (selon vos moteurs de stockage), optimisation du serveur, montée en charge (étude de la réplication notamment…)

Comme vous le voyez les problématiques basculent pour la plupart dans un autre monde : celui de l’administrateur de bases de données. Cela dit, et ce fut une de mes motivations, il est également très intéressant lorsqu’on développe de connaître justement les différences entre les moteurs de stockage, comment jouer avec leurs forces et éviter leurs faiblesses dans un contexte donné par exemple.
On peut également considérer que l’optimisation des requêtes relève là encore du monde du développement mais c’est bien sûr un sujet qu’un DBA se doit de maîtriser.

Mon point de vue sur cette certification “DBA” : elle nécessite davantage de travail lorsqu’on vient du monde du développement, l’examen I notamment nécessite de se familiariser avec les (nombreux) outils existant sous MySQL pour effectuer des tâches de maintenance par exemple. Ces outils possèdent un bon nombre d’options, parfois spécifiques à un moteur de stockage et pour corser le tout plusieurs outils sont capables d’effectuer les mêmes traitements…

L’examen II est à mon sens beaucoup plus ludique, vous y trouverez moins d’outils à retenir mais quelques variables serveur notamment (tuning) sont à mémoriser. Ce second examen est vraiment tourné vers l’optimisation, je ne saurais trop vous conseiller de vous entraîner à manipuler un serveur MySQL en testant différentes configurations et d’observer par vous-même ce qui se trouve par exemple dans la documentation.

La certification Cluster

Au programme de celle-ci, un seul examen, 70 questions, 90 minutes et un passing score de 43/70 environ.
Complètement tournée vers le MySQL Cluster, cet examen ne sera validé que si vous êtes déjà certifié DBA. C’est logique après tout : difficile de se plonger au coeur du MySQL Cluster si l’on n’a pas une bonne connaissance du serveur MySQL “classique”.
MySQL conseille comme d’habitude d’avoir accumulé au moins un peu d’expérience en manipulant le cluster avant de se présenter à l’examen, (cf le paragraphe “Ma méthode”).

Parmi les principaux thèmes :
Architecture et organisation du cluster (vraiment spécifique par rapport à un serveur MySQL standard), le moteur de stockage NDB, les fichiers de configuration du cluster (config.ini, my.cnf, les options disponibles…), démarrage / arrêt / gestion du cluster, les sauvegardes / restauration, tuning, résolutions de problèmes.

Au vu des spécificités d’une installation cluster par rapport à une installation MySQL classique, il n’est pas possible de se reposer uniquement sur les connaissances MySQL évoquées lors des certifications précédentes pour s’en sortir lors de cet examen. Lire la documentation tout en testant systématiquement soi-même tout ce que vous lisez participera bien sûr à votre futur succès.

Comment se former ?

Il y’a différentes façons de faire, tout dépend de votre volonté, du temps dont vous disposez mais également de vos finances…

Les livres :

- Le “MySQL Certification Study Guide” couvre les certifications Associate, Developer et DBA, c’est celui que j’ai utilisé. Il comporte en fait deux grandes parties : “Developer” et “DBA”, rappelons que la “Associate” est un sous-ensemble de la “Developer”.
Moins aride que la documentation, tout est organisé pour vous faciliter la vie pour la certification, c’est un excellent ouvrage qui vous renseignera au-delà des examens, c’est une très bonne source d’informations concernant MySQL 5.
Un de ces grands avantages : les exercices disponibles. Chaque chapitre dispose de son lot d’exercices (avec corrigés). Vraiment bien étudiés pour la certification, ces derniers sont un peu plus difficiles que lors de l’examen (ce qui est une bonne chose). A noter que le livre contient un CD contenant les pdf des différents chapitres et exercices.
Pour 40 euros environ c’est un ouvrage que vous devez vous procurer si vous envisagez une de ces trois certifications. Il contient de plus un bon de réduction de 20% sur le prix de votre premier examen (à vérifier, il existe une date de validité, renseignez-vous).
Seul point qui peut s’avérer négatif pour certains : le livre est en anglais… Cela dit, à aujourd’hui les certifications MySQL sont disponibles en deux langues : anglais et japonais, le choix est vite fait

- Pour les amateurs de cluster le “MySQL 5.1 Cluster Certification Study Guide” est là encore une aide très précieuse, c’est celui-ci que j’ai utilisé.
En anglais lui aussi, il se lit plus facilement que la documentation, comporte des exercices mais cette fois ni CD ni pdf, dommage mais pas dramatique. C’est un ouvrage que j’ai parcouru plusieurs fois avant l’examen et qui encore aujourd’hui me sert très souvent, son utilité dépasse le cadre de la certification : vous pouvez l’acheter tout simplement en tant que source d’informations sur le MySQL Cluster.

- Les formations :

Délivrées par différents organismes de formation (MySQL dispose également de cursus dédiés), ces formations se déroulent souvent sur plusieurs jours (2 à 5). Comptez jusqu’à 2000 euros environ pour une semaine de formation… Vu le tarif pratiqué ce sont des formations accessibles via son entreprise notamment, et pourquoi pas dans le cadre d’un DIF (Droit Individuel à la Formation), renseignez-vous auprès de votre entreprise.
Attention tout de même, si vous partez d’un niveau disons “standard” en MySQL le lundi matin 8h, et même après 5 jours de formation intensives, il n’est pas garanti que vous réussissiez le vendredi à 17h les deux examens requis pour une “Developer” ou une “DBA”, il faut en effet du temps et de la pratique pour assimiler toutes les connaissances requises… Vous aurez évidemment gagné du temps dans cet apprentissage, sans aucun doute, mais le contenu est dense. Il est préférable de prendre son temps pour intégrer des connaissances plutôt que de se bourrer le crâne la veille de l’examen et en avoir oublié la moitié 48h après le jour J quelque soit le résultat.

N’ayant pas testé moi-même ces formations je ne peux vous en conseiller une en particulier, en revanche je vous encourage à partager vos impressions dans les commentaires si vous avez testé cette formule.

Ma méthode / Quelques chiffres

- Armé uniquement des livres cités ci-dessus (MySQL certification guide et Cluster certification guide), j’ai procédé par ordre. Je me suis tout naturellement intéressé d’abord à la “Developer” avant d’attaquer la “DBA” qui m’intéressait aussi (raisons citées plus haut) et enfin tout cela m’a donné envie de découvrir le cluster, que j’ai appris à connaître tout en préparant la certification.
- En ce qui concerne les examens “Dev” et “DBA” j’ai décidé de faire des fiches… Chaque partie fait en effet 300 pages, du coup j’ai pensé que résumer tout cela sur des fiches me permettrait de parcourir l’essentiel plus rapidement qu’avec un bloc 600 pages. C’est sans doute vrai mais la rédaction prend du temps, je dirais 50% du temps d’apprentissage d’un examen pour ma part.
- J’ai passé deux mois sur chaque examen de la “Dev”. Difficile de se faire une idée de ce que représentent vraiment deux mois, nous avons tous des plannings différents, des week-ends différents, mais cela donne un ordre d’idées, je n’avais pas de planning à tenir pour la “Dev” et la “DBA”, j’ai donc fait ça pendant mon temps libre, sans me fixer une date.
- L’entraînement aidant, j’ai réduit la durée de préparation à un mois pour DBA I et 6 semaines pour DBA II.
- Concernant la “Dev” et la “DBA”, j’ai d’abord étudié l’examen I, passé l’examen I, puis étudié l’examen II et passé l’examen II.
- Je n’ai pas fait de fiche pour la cluster, j’y ai consacré environ 2 mois.
- J’ai payé ma certification cluster 20$ au lieu de 200 euros lors de la conférence MySQL 2008 Les rabais sont importants lors de ce type d’évènements. Les certifications se déroulent alors sur papier, le score final n’est pas fourni, seul le résultat vous sera communiqué.
- Si vous avez choisi les livres cités plus haut : effectuez tous les exercices proposés, au moins une fois ou deux, ils vous préparent efficacement aux questions des examens.
- Testez, testez, testez ! Installez-vous un serveur MySQL, un cluster MySQL si besoin et testez par vous-même tout ce que l’on vous présente dans la documentation, vous ne devez pas tout connaître par coeur mais le minimum est de tout comprendre. Si vous êtes sous Windows passez pourquoi pas par Vmware pour vous installer des machines virtuelles hébergeant vos serveurs. Une fois la solution de Vmware installée, vous pouvez charger une Debian Etch par exemple et commencer vos installations / tests. Il est tout à fait possible à partir d’un seul pc de simuler plusieurs machines…

Impressions finales

- J’ai trouvé les examens Dev I et DBA II les plus simples, mon meilleur score fut d’ailleurs obtenu sur DBA II, le moins bon sur DBA I.
- Pour moi DBA I fut peut-être le moins drôle, pas mal d’outils/d’options à retenir, pour ceux qui ne sont pas déjà DBA MySQL il y’a du travail ici.
- Attention à la gestion du temps sur Dev II (cf le conseil de Giuseppe Maxia sur le jeu d’échecs dans les liens ci-dessous).
- J’ai adoré la partie DBA II (optimisations), c’est ludique, concret et sympa à apprendre, vous pouvez très rapidement appliquer ce que vous apprenez dans votre job.

Pour résumer mes impressions concernant ces certifications, elles m’ont beaucoup appris, elles vous “forcent” à parcourir de façon précise des domaines auxquels vous n’auriez peut-être pas été confronté pendant encore longtemps. Lorsque vous visez une certification, vous avez un objectif, on parcourt donc les documentations d’un autre oeil dans ces cas là…
Fort de ces nouvelles connaissances, vous aurez davantage de solutions à proposer face aux problèmes que vous rencontrerez.
Les certifications ne feront pas de vous des dieux vivants en MySQL mais des professionnels avertis, au fait des outils existant et capables de monter plus rapidement en compétence sur des sujets dont vous n’étiez pas forcément spécialistes.
Enfin, et c’est sans doute le plus important à mes yeux : les certifications aiguisent votre curiosité ! Lorsque j’ai démarré la certification “Developer”, je ne pensais pas forcément passer la DBA, et encore moins la Cluster lors d’une conférence MySQL à Santa Clara

J’espère que ce retour d’expérience vous sera utile, si vous aussi vous avez passé une de ces certifications, laissez vos impressions dans les commentaires et faites en profiter la communauté !

Bien sûr, n’hésitez pas à poser ici vos questions concernant les certifications, j’y répondrai avec plaisir.

Quelques liens pour aller plus loin :

- Testez-vous ! MySQL vous propose 10 questions pour chacune des certifications dont nous venons de parler, les questions m’ont l’air un peu plus simples que celles des examens mais elles valent le coup néanmoins.
- Lisez aussi les conseils de Giuseppe Maxia pour la certification, ainsi que ceux de Mark Schoonover qui valent le détour également. Enfin le blog de Dave Stokes, il travaille chez MySQL dans l’équipe de certification.