Changement d'engine MyISAM -> InnoDB

Hello,
(je précise que je ne suis pas très expérimenté en base de donnée :))

Je reprend une application existante basée sur une structure de base de donnée dont les tables sont gérées à l'aide du moteur MyISAM.

Dans cette structure, il y a une table A qui contient des enregistrement uniques. Chaque enregistrement à un ID (la clé primaire de la table, A.id), et il y a tout une autre série de tables qui font référence à cet ID, mais indrectement car il n'y a pas de contrainte de clé étrangère.

Autrement dit, si on prend par exemple la table B dont la clé primaire est B.id, eh bien B.id correspond en fait a A.id, et lors d'un insert dans B, on indique donc cette valeur directement (pas d'auto_increment).

Bon le problème est que d'une part, j'ai l'impression que l'utilisation des clé étrangère est plus naturelle, et d'autre part, la supression d'une entrée dans A nécessite de supprimer les entrées dans B (et autres...) y faisant référence, et comment MyISAM ne sait pas faire (à ma connaissance), il faut gérer ca soi même.

Le problème étant posé, je me demande si je ne vais pas passer au moteur InnoDB qui notamment autorise la gestion de clé étrangère.

Mes questions sont donc multiples:
- Ce passage vous semble t-il naturel dans mon cas?
- Quels sont en pratique les inconvéniants de InnoDB par rapport à MyISAM? Sachant que mon application doit être en mesure de gérér plusieurs millions d'entrées. J'ai pu lire sur le site de MySQL que InnoDB était plus lent... Mais a quel point? Pour quel type de traitement? Enfin bref toute info est la bienvenue.
- Etant donné une BD existante, il faudrait alterer chaque table, changer le moteur, et introduire les contraintes de clé étrangères. Cela peut-il poser un problème particulier?

Merci d'avance de vos réponse et désolé si mes questions sont naïves.

Citation:

---

Envoyé par vinzzzz

- Ce passage vous semble t-il naturel dans mon cas?

---

Ça se tient. On peut vivre sans clefs étrangères, mais avoir des garanties sur l'intégrité n'est pas un mauvaise chose et justifie le (léger) impact que cela a sur les performances.

Citation:

---

Envoyé par vinzzzz

- Quels sont en pratique les inconvéniants de InnoDB par rapport à MyISAM? Sachant que mon application doit être en mesure de gérér plusieurs millions d'entrées. J'ai pu lire sur le site de MySQL que InnoDB était plus lent... Mais a quel point? Pour quel type de traitement? Enfin bref toute info est la bienvenue.

---

InnoDB est "réputé" plus lent, mais la question est complexe. En pratique beaucoup de choses influent (matériel, données, requêtes, charge, etc.) et il y a des cas où InnoDB sera plus performants. Notamment, pour des tables sur lesquelles les modifications (UPDATE, pas INSERT) sont fréquentes, le verrouillage plus fin d'InnoDB permet un bien meilleure concurrence.

Le principal défaut d'InnoDB serait peut-être qu'il prend vraiment plus de place sur le disque. Mais pour "seulement" quelques millions d'entrées ça ne devrait pas poser de problème aux machines actuelles.

Disons qu'il est "suffisamment" performant, et que le choix devrait plus se faire sur d'autres critères : besoin de transactions, de clefs étrangères... On peut aussi noter qu'InnoDB est bien plus résistant au crash et que la récupération est incomparablement plus courte (façon NTFS versus FAT et son checkdisk).

Citation:

---

Envoyé par vinzzzz

- Etant donné une BD existante, il faudrait alterer chaque table, changer le moteur, et introduire les contraintes de clé étrangères. Cela peut-il poser un problème particulier?

---

Le principal problème de mon point de vue est que ça peut prendre du temps, et une table est verrouillée pendant sa conversion. Il faut voir dans quelle mesure le service peut être interrompu. Si c'est un problème, la réplication permet éventuellement de faire la conversion sur un esclave avant de basculer.

Ensuite, le problème sera plutôt la gestion des transactions par l'application. Si c'était du MyIsam, il n'y en a probablement pas. L'autocommit permet d'obtenir le même comportement, mais c'est dommage, et très dommageable pour les performances.