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.
Enjoy this article?
Leave a comment
No trackbacks yet.
12:32 pm on January 14th, 2009
Très bon résumé. Je vais suggérer ton article à mes amis qui utilise MySQL sans trop savoir comment ça fonctionne.
Je crois que la majorité des personnes qui utilisent MySQL ne savent pas vraiment si leur BD à plus de requête en READ ou en WRITE. C’est donc pas facile à partir de là de pouvoir les aider à choisir leur “engine”. Puisque MyISAM est meilleur pour fonctionner “Out of the Box”, j’ai l’impression que c’est la meilleur solution par défaut. Peut-être que lorsqu’une personne se demande quel serait le meilleur “engine” à utiliser, c’est un signe pour qu’il utilise InnoDB.
10:38 pm on January 14th, 2009
Les développeurs doivent connaître le flow de données de leurs applications. On s’attend, par exemple, à ce qu’une application de logging fasse beaucoup plus de WRITE que de READ.
La beauté de la chose, c’est que MySQL nous permet de faire du cas par cas. Lorsqu’on connaît bien ce qu’on le fait, on peut mettre certaines tables MyISAM et d’autre InnoDB pour tirer avantage des 2 engines. De plus, il n’y a quasi aucune pénalité à mixer des tables de types différents dans la même requête.
6:34 am on January 16th, 2009
Le fait que InnoDB soit relationnel, à l’inverse de MyISAM, est aussi un argument de poids.
11:56 am on January 16th, 2009
@romualb: Tout à fait. Du moment où on souhaite avoir des foreign key pour renforcer l’intégrité, ou des transactions, la question ne se pose même plus.
12:46 pm on January 19th, 2009
Allo !
Une petite question à vous, expert InnoDB // MyISAM.
J’ai une base de donnée tout en InnoDb, sauf quelques tables temporaires en MyISAM.
Je veux ajouter toute un fichier CSV dans ma BD. Avant toute insertion dans les tables adéquates, je passe par une table temporaire pour m’assurer du format des données, de toutes les conditions souhaitées (doublons, invalides, already exist, et autres conditions dépendante de notre structure).
Une fois que je suis sure que mes données parsées sont impeccable, je lance une nouvelle procédure qui a pour objectif d’insérer les données aux bonnes places.
Mon problème est que l’insertion est très longue, du au fait qu’il valide à nouveau toutes les clés.
Je ne veux pas mettre ma BD en MyISAM. Mais connaissez-vous un moyen de passer outre les clés à un moment donné ? de les désactiver ?
Ou peut être y aurait-il un autre moyen d’optimiser ?
Merci !
7:32 pm on January 19th, 2009
@Amélie: Si la table temporaire permet d’assurer qu’il n’y aura pas de doublon (ou autre problème d’intégrité), il est possible de désactiver les contraintes de foreign key avec “SET foreign_key_checks = 0″.
Cependant, ceci ne désactive pas les contraintes d’unicité (unique index). Il est possible de le faire avec un “ALTER TABLE DISABLE KEYS” mais cette solution est probablement peu enviable.
Comment insérez-vous vos données dans la “vraie” table ? Un “INSERT INTO tableName (field1,field2,field3) SELECT f1,f2,f3 FROM myTmpTable;” est habituellement très rapide.
Il y a d’autre petit truc à essayé aussi.Avez-vous aussi essayer de mettre la table temporaire MEMORY plutôt que MyISAM? Ça pourrait “peut-être” aider.
4:55 pm on May 29th, 2009
J’aimerais avoir des notes necessaires pour bien commencer avec mysql 5.1
5:19 am on December 4th, 2009
Je déterre cet article… Mais Myisam n’est pas (vraiment) plus rapide que innodb en insert.
Innodb est certe un peut plus lent sur l’insertion de blocks, mais il a l’avantage de locker uniquement la ligne en écriture, et non toute la table comme le fait myisam.
Sur un benchmark où on fait “INSERT INTO table SELECT * FROM table” avec un table de 100 000 ligne, on verra nettement que MyIsam est plus rapide que Innodb. Mais ce cas de figure n’existe que très rarement dans nos applications. Généralement, on à plutôt 100 000 utilisateurs qui font des insert d’une ligne du type “INSERT INTO table () VALUES()” et sur ce points, c’est innodb qui prend l’avantage.