7
votes

Conversion Myisam en InnoDB. Bénéfique? Conséquences?

Nous exécutons un site de réseautage social qui enregistre l'action de chaque membre (y compris la visite des pages d'autres membres); Cela implique beaucoup d'écritures à la DB. Ces actions sont stockées dans une table myisam et, étant donné que quelque chose commence à taxer la CPU, ma première pensée était que c'est le verrouillage de la table de Myisam qui provoque ce stress sur la CPU.

  • Il n'y a que des lectures et des écrites, pas de mises à jour de cette table. Je pense que l'équilibre entre les lectures et écrires est d'environ 50/50 pour cette table, serait donc une meilleure option?
  • Si je veux changer la table en InnoDB et que nous n'utilisons pas de contraintes de clés étrangères, de transactions ou d'index FullText - Dois-je m'inquiéter de quoi que ce soit?

3 commentaires

Stackoverflow.com/Questions/20148/myisam-versus-innodb


Ce n'est pas un duplicata de ce qui précède, car il s'agit de la migration plutôt que des avantages en soi.


Vous pouvez également utiliser un mélange de tables, garder Myisam pour des tables lisibles et innodb pour les journaux. Cependant, je n'utiliserais personnellement pas Myisam pour quelque chose de beaucoup aujourd'hui (seule la perquisition de la recherche complète du texte complet).


4 Réponses :


2
votes

Je pense qu'il est tout à fait possible que le passage à InnoDB améliorerait les performances, mais dans mon expérience, vous ne pouvez pas vraiment être sûr avant de l'essayer. Si j'étais vous, je configurerais un environnement de test sur le même serveur, convertit en InnoDB et exécuter une référence.


0 commentaires

7
votes

Nonobstant tout avantage / inconvénients de son utilisation, qui sont discutés dans d'autres threads ( myisam versus innodb ), la migration est un processus non trivial.

considérer

  • tester fonctionnellement tous les composants qui parlent à la base de données si possible - les moteurs de différence ont une sémantique différente
  • courir autant de tests de performance que vous pouvez - certaines choses peuvent s'améliorer, d'autres peuvent être bien pires. Un exemple bien connu est de sélectionner (*) sur une grande table.
  • Vérifiez que tout votre code gérera gracieusement - vous pouvez les obtenir sans utiliser explicite des transactions
  • Estimez la quantité d'utilisation de l'espace que vous obtiendrez en convertissant - testez cela dans un environnement de non-production.

    Vous devrez sans doute changer de choses dans une grande plate-forme logicielle; C'est bon, mais voyant que vous (espérons-le) avoir beaucoup de couverture de test automatique, le changement devrait être acceptable.

    PS: Si "quelque chose commence à taxer la CPU", vous devriez alors trouver ce que, dans un environnement de non-production, b) Essayez diverses options pour la réduire, dans un environnement de non-production. Vous ne devez pas commencer aveuglément à faire des choses majeures telles que changer de moteurs de base de données lorsque vous n'avez pas complètement analysé le problème.

    Tous les tests de performance doivent être effectués dans un environnement de non-production, avec des données semblables à la production et sur du matériel de production de production. Sinon, il est difficile d'interpréter les résultats correctement.


1 commentaires

Merci beaucoup pour cette information. Pourriez-vous élaborer sur la "sémantique différente"?



4
votes

En ce qui concerne les autres problèmes de migration potentiels:

1) Espace - Les tables InnoDB nécessitent souvent plus d'espace disque, bien que le format de fichier Barracuda pour les nouvelles versions d'Innodb a réduit la différence. Vous pouvez avoir un sens pour cela en convertissant une sauvegarde récente des tables et en comparant la taille. Utilisez "Afficher l'état de la table" pour comparer la longueur de données.

2) Recherche en texte intégral - uniquement sur Myisam

3) DataTypes SIG / spatiaux - uniquement sur Myisam

sur la performance, comme les autres réponses et la réponse référencée indiquent, cela dépend de votre charge de travail. Myisam est beaucoup plus rapide pour les analyses de la table complète. InnoDB a tendance à être beaucoup plus rapide pour un accès hautement concourais. InnoDB peut également être beaucoup plus rapide si vos recherches sont basées sur la clé primaire.

Un autre problème de performance est que Myisam peut toujours garder un nombre de rangée, car il ne fait que le verrouillage du niveau de table. Donc, si vous essayez souvent d'obtenir le nombre de rangées pour une très grande table, il peut être beaucoup plus lent avec InnoDB. Recherchez sur Internet si vous avez besoin d'une solution de contournement pour cela, comme je l'ai vu plusieurs proposé.

Selon la taille de la table (s), vous devrez peut-être également mettre à jour votre fichier de configuration MySQL. À tout le moins, vous voudrez peut-être déplacer des octets de Key_Buffer vers Innodb_Buffer_Pool_Size. Vous n'obtiendrez pas une comparaison équitable si vous quittez la base de données comme optimisée pour MyISAM. Lisez sur toutes les propriétés de configuration Innodb_ *.


0 commentaires

0
votes

De mon expérience, les tables MyISAM ne sont utiles que pour l'indexation de texte où vous avez besoin de bonnes performances avec des recherches sur le gros texte, mais vous n'avez toujours pas besoin d'un moteur de recherche complet comme Solr ou ElasticseSearch.

Si vous souhaitez passer à InnoDB mais que vous voulez continuer à indexer votre texte dans une table myisam, je vous suggère de jeter un coup d'œil à ceci: http://blog.lavoie.sl/2013/05/converting-myisam-a-innodb-fortltext.html

Aussi: InnoDB prend en charge des sauvegardes atomiques en direct avec Innobackupex de Percona. Ceci est divinité lorsqu'il s'agit de serveurs de production.


0 commentaires