MyISAM et InnoDB

Question

Je travaille sur des projets qui nécessitent beaucoup d'écritures de base de données, je dirais (70% des inserts et 30% de lectures). Ce ratio serait également inclure des mises à jour qui me semble être une lecture et d'une écriture. Le lit peut-être sale (par exemple, je n'ai pas besoin de 100% de l'information exacte au moment de la lecture).
La tâche en question va faire plus de 1 million de transactions de base de données d'une heure.

J'ai lu un tas de trucs sur le web sur les différences entre les MyISAM et InnoDB et MyISAM semble être le choix évident pour moi pour le particulier de la base de données/tables que je vais utiliser pour cette tâche. À partir de ce que je semble être la lecture, InnoDB est bonne, si les transactions sont nécessaires puisque le verrouillage de niveau ligne est pris en charge.

Quelqu'un at-il une expérience avec ce type de charge (ou plus)? Est MyISAM le chemin à parcourir?

Answer 1

J'ai brièvement discuter de cette question par la table de sorte que vous pouvez conclure de ce qui doit être choisi soit innodb ou MyISAM. http://developer99.blogspot.com/2011/07/mysql-innodb-vs-myisam.html

Voici un petit aperçu de quel type que vous devez utiliser dans une situation donnée:

                                             My ISAM    InnoDB
Required full text Search                      Yes       5.6+
Require Transactions                                     Yes
frequent select queries                        Yes      
frequent insert,update,delete                            Yes
Row Locking (multi processing on single table)           Yes
Relational base design                                   Yes

Pour résumer:

Frequent reading, almost no writing   => MyISAM
Full text search in MySQL <= 5.5      => MyISAM

Dans tous les autres cas, InnoDB est généralement la meilleure façon d'aller.

Answer 2

Je ne suis pas un expert base de données, et je ne parle pas de l'expérience. Cependant:

Les tables MyISAM utilisation au niveau de la table de verrouillage. Basé sur vos prévisions de trafic, vous avez près de 200 écrit par seconde. Avec MyISAM, un seul de ces pourrait être en cours à tout moment. Vous devez vous assurer que votre matériel peut répondre à ces transactions pour éviter d'être envahi, c'est à dire, une seule requête peut pas prendre plus de 5ms.

Qui me donne à penser que vous auriez besoin d'un moteur de stockage qui prend en charge le verrouillage de ligne, c'est à dire, InnoDB.

D'autre part, il devrait être assez trivial à écrire quelques scripts simples pour simuler la charge avec chaque moteur de stockage, puis de comparer les résultats.

Answer 3

Les gens parlent souvent de performances, de lectures vs écrit, les clés étrangères, etc. mais il y a une autre caractéristique incontournable pour un moteur de stockage, à mon avis: les mises à jour atomiques.

Essayez ceci:

1. Question d'une mise à JOUR sur votre table MyISAM qui prend 5 secondes.
2. Alors que la mise à JOUR est en cours, dire 2,5 secondes, appuyez sur Ctrl-C pour interrompre.
3. Observer les effets sur la table. Combien de lignes ont été mises à jour? Combien n'ont pas été mis à jour? Le tableau de même lisible, ou était-il endommagé lorsque vous appuyez sur Ctrl-C?
4. Essayez la même expérience avec la mise à JOUR contre une table InnoDB, interrompant la requête en cours.
5. Observer la table InnoDB. Zéro lignes ont été mises à jour. InnoDB a assuré que vous avez les mises à jour atomiques, et si la mise à jour complète ne pourrait être engagée, elle restaure l'ensemble du changement. Aussi, le tableau n'est pas corrompu. Cela fonctionne même si vous utilisez killall -9 mysqld pour simuler un accident.

La Performance est souhaitable, bien sûr, mais ne pas perdre de données devrait l'emporter.

Answer 4

J'ai travaillé sur un système à débit élevé de l'utilisation de MySQL et j'ai essayé les deux MyISAM et InnoDB.

J'ai trouvé que le niveau de la table de verrouillage en MyISAM causé de sérieux problèmes de performances de notre charge de travail qui semble similaire à la vôtre. Malheureusement, j'ai aussi trouvé que les performances sous InnoDB a été aussi pire que je l'avais espéré.

Au final, j'ai résolu le conflit problème en fragmentant les données telles que des inserts suis allé dans une "chaude" de la table et sélectionne jamais interrogé la table chauffante.

Cela a également permis supprime (les données ont été sensibles au temps et nous ne conserver que X jours) de se produire sur les "vicié" tables de nouveau n'était pas touché par les requêtes select. InnoDB semble avoir de mauvaises performances en vrac supprime donc, si vous avez l'intention de la purge des données que vous pourriez voulez structurer d'une façon telle que les anciennes données est dans un état table qui peut simplement être supprimé au lieu de courir supprime.

Bien sûr, je n'ai aucune idée de ce que votre demande est mais j'espère que cela vous donne un aperçu de certaines des questions avec MyISAM et InnoDB.

Answer 5

Pour une charge avec plus d'écritures et de lectures, vous aurez l'avantage de InnoDB. Parce que InnoDB offre de verrouillage de ligne plutôt que de verrouillage des tables, votre SELECTs peuvent être simultanées, et pas seulement les uns avec les autres mais aussi avec de nombreux INSERTs. Toutefois, sauf si vous avez l'intention d'utiliser transactions SQL, définir la InnoDB commettre rincer à 2 (innodb_flush_log_at_trx_commit). Cela vous donne beaucoup de retour de performances brutes qui vous ferait perdre lors du déplacement de tables de MyISAM pour InnoDB.

Aussi, pensez à ajouter de la réplication. Cela vous donne un peu de lecture mise à l'échelle et puisque vous avez déclaré votre lit n'avez pas à être à jour, vous pouvez laisser la réplication de l'automne derrière un peu. Juste être sûr que l'on peut rattraper en vertu de quelque chose, mais le plus lourd de la circulation ou il sera toujours derrière et ne sera jamais le rattraper. Si vous allez de cette façon, cependant, j'ai fortement recommander de vous isoler de la lecture par les esclaves et le retard de réplication de gestion de votre base de données gestionnaire. C'est tellement plus simple si le code de l'application ne savez pas à ce sujet.

Enfin, soyez conscient des différents tableau des charges. Vous n'aurez pas le même ratio de lecture/écriture sur tous les tableaux. Quelques petites tables avec près de 100% les lectures peuvent se permettre de rester MyISAM. De même, si vous avez quelques tables qui sont proches de 100% écrire, vous pouvez bénéficier d' INSERT DELAYED, mais c'est uniquement pris en charge en MyISAM ( DELAYED clause est ignoré pour une table InnoDB).

Mais point de repère sûr.