Jan/098
MyISAM ou InnoDB ?
Un ami me demandait aujourd’hui si une application qu’il utilise à son travail pourrait être plus performante si les tables étaient Innodb plutôt que MyISAM ? Oui. Non. Peut-être. Il n’y a pas de réponse à cette question; il y beaucoup trop de facteurs à considérer.
Peter Zaitsev a publié hier un article sur le sujet. Comme il indique, il faut d’abord s’interroger pour savoir “pourquoi” les tables sont MyISAM à la base. Le sont-ils pour une raison particulière ou parce qu’elles utilisent le storage engine par défaut de MySQL ?
Les 2 storages engines possèdent des avantages différents qui les rendent aussi performant l’un que l’autre, dépendamment de l’utilisation qu’on en fait. Pour répondre adéquatement à mon ami, il aurait fallu que je connaisse quel genre de requêtes son application fait, à quelle fréquence, combien de connexions simultanées utilisent la base de données, etc.. À défaut de connaître toutes ces informations, voici quelques différences qui peuvent vous faire opter pour InnoDB plutôt que MyISAM.
En fait, il faut savoir que de manière générale, là où MyISAM brille, InnoDB est hors compétition, et vice versa. MyISAM est reconnu pour sa vitesse d’écriture, sa faible consommation de mémoire et d’espace disque, sa rapidité à retourner un count(*) et les fulltext index.
InnoDB lui consomme plus de mémoire et d’espace disque, les requêtes d’écritures sont moins rapides que MyISAM, les count(*) sont excessivement lents et il ne supporte pas les fulltext index. Il requiert de modifier la configuration par défaut pour être performant alors que MyISAM performe bien avec la configuration par défaut. À son avantage, il possède du row-level locking, des transactions (acid compliant), des clustered primary key index et son implémentation permet une meilleure “concurrency” (plusieurs opérations simultanées). Lorsque configuré adéquatement, il devient très performant.
Lorsque la concurrence devient un enjeu, qu’il y a beaucoup de requêtes d’écriture et de lecture, InnoDB est le meilleur choix. Plusieurs personnes affirment qu’il devrait être le storage engine par défaut; il est vrai qu’il offre beaucoup plus d’avantages que MyISAM et qu’il offre de meilleures performances en générale (c’est mon avis). Par contre, il ne faut pas négliger les autres storages engines, car ils peuvent être beaucoup plus efficace dans certains cas. Dans le cours de Performance Tunning, on nous enseigne à savoir où, quand, comment et pourquoi un storage engine sera meilleur qu’un autre.
Apr/080
Locking et MyISAM
Avec MySQL, il existe deux types de locking : le Shared Lock et le Exclusive Lock. Un client peut demander explicitement un lock sur une ou plusieurs tables pour manipuler les données sans qu’un autre client interfère sur ces données. Il doit ensuite être relâché par le client qui l’a demandé lorsqu’il a terminé ses manipulations.
Il est possible de demander un Read Lock, un Write Lock ou un Read Local Lock et la manière de locker les tables diffère d’un engine à l’autre. Il faut aussi savoir que les Read Lock et Read Local Lock sont des Shared locks, ce qui signifie que la table demeure accessible en lecture pour tous les clients. Les Write Lock eux sont exclusifs, ce qui a pour effet que seul le client qui demande le lock peut lire et écrire dans la table.
Pour MyISAM, les tables entières doivent être lockées pour un lock exclusif. Évidemment, il y a des avantages et des inconvénients. L’un des avantages majeurs de locker une table au complet est qu’il est impossible de créer un deadlock car un lock exclusif appartient qu’à un seul client à la fois. De plus, ce genre de lock demande très très peu de mémoire et de temps CPU.
Étant donné que la table entière est lockée, les autres clients doivent attendre que le lock soit libéré pour pouvoir lire ou écrire dans la table. C’est un inconvénient majeur. Supposons que 1000 clients soient connectés au serveur et que ces 1000 clients tentent de lire une table qui a été lockée par un des 1000 clients, ils doivent tous attendre. Si pour une situation imprévue, la table demeure lockée pour 30 secondes, vous pouvez imaginer les problèmes que ça peut engendrer.
Dans certains cas, ce problème peut cependant être évité en utilisant un Read Local. Ce type de locking est exclusif à MyISAM. On pourrait comparer un lock Read Local avec une transaction dans le sens où lorsqu’un Read Local est demandé, le serveur crée une espèce de copie de l’état actuel de la table sans empêcher les autres utilisateurs de lire et écrire dedans. La table demeure virtuellement inchangée pour le client qui a demandé le lock jusqu’à ce qu’il le libère.
Soyez prudent avec les Locks, surtout avec MyISAM !