Quelles sont les raisons * pas * utiliser le moteur de stockage MEMORY MySQL?

Question

J'ai récemment découvert que MySQL a une « mémoire » moteur que je ne connaissais pas (la plupart de mon travail de base de données est pour les projets de passe-temps donc j'apprends ce que je dois que je vais). Il semble que cette option devrait me donner des performances considérablement améliorée, donc je me demande s'il y a des inconvénients qui vont avec. Les deux que je connais sont:

1. je dois avoir assez de RAM pour tenir la table (s) en question.
2. Les tables sont perdues si la machine se ferme vers le bas.

Je crois que # 1 ne devrait pas être un problème puisque je suis en utilisant AWS EC2 et peut se déplacer à un type d'instance avec plus de mémoire si nécessaire. Je crois que je peux atténuer # 2 par le dumping sur le disque au besoin.

Quels sont les autres problèmes sont là? le moteur de la mémoire ne peut jamais donner moins bonnes performances que ce soit MyISAM ou InnoDB? Je crois avoir lu quelque chose que les indices sont différents avec ce moteur; est-ce quelque chose que je dois vous soucier?

Answer 1

En regardant le http: / /dev.mysql.com/doc/refman/5.1/en/memory-storage-engine.html deux problèmes possibles sautent:

1. Aucune transaction ou soutien FK, ce qui signifie que vous devrez gérer l'intégrité des transactions et l'intégrité référentielle dans votre propre code étaient nécessaires (ce qui pourrait finir par être beaucoup moins efficace que de laisser la DB faire pour vous, même si cela dépend beaucoup sur les modèles de comportement attendus de votre application).
2. Tableau niveau de verrouillage seulement: cela pourrait être un obstacle important à l'évolutivité si votre application a besoin de plusieurs écrivains simultanés au même ensemble de tables ou dans les cas où vos opérations de lecture utilisent des verrous pour assurer la cohérence des données est lu - dans ce cas, un disque table à partir des supports qui granularité de verrouillage beaucoup plus fine fonctionnera beaucoup mieux si un nombre suffisant de son contenu est actuellement mis en mémoire cache dans la RAM.

Autre que cela, en supposant que vous avez suffisamment de RAM, une table à base de mémoire devrait être plus rapide que un sur disque. Il est évident que vous devez facteur dans la prise des clichés sur le disque pour aborder la question de ce qui se passe lorsque l'instance du serveur est remis à zéro, ce qui est susceptible de nier complètement l'avantage de la performance globale si les besoins de capture des données souvent (si vous pouvez vivre avec la perte d'un jour de données dans un tel cas vous pourriez juste faire une sauvegarde une fois par jour, mais dans la plupart des cas qui ne seraient pas acceptables).

Une alternative pourrait consister à:

1. Utiliser des tables sur disque, mais assurez-vous que vous avez plus qu'assez de RAM pour les contenir tous dans la RAM à un moment donné (et « assez de RAM » peut-être plus que vous pensez que vous avez besoin de tenir compte des autres processus du Machine à laver, des tampons OS IO / cache et ainsi de suite)
2. Analyser le contenu (toutes les données et les pages d'index) de la table à chaque démarrage de pré-charger le contenu en mémoire avec SELECT * FROM <table> ORDER BY <pkey fields> pour chaque table, suivi de SELECT <indexed fields> FROM <table> ORDER BY <index fields> pour chaque indice

De cette façon, toutes vos données dans la RAM, vous avez seulement à vous soucier des performances d'E / S pour les opérations d'écriture. Si votre jeu de travail commun de l'application est beaucoup plus petite que l'ensemble DB (ce qui généralement le cas - dans la plupart des applications la plupart des utilisateurs ne regarderont les données les plus récentes les plus si le temps) vous pourriez être mieux d'être plus sélectif sur la quantité vous numérisez de précharger en mémoire, ce qui permet le reste à charger à partir du disque sur demande.

Answer 2

Il y a beaucoup de cas ne pas utiliser le moteur de stockage de mémoire - et quand InnoDB sera plus rapide. Vous avez juste besoin de penser à et non triviales concurrency simples essais filetés.

Si vous avez une assez grande pool de mémoire tampon, puis InnoDB deviendra entièrement résident de mémoire pour les opérations de lecture ainsi. Bases de données disposant pas de caches . Ils se réchauffent!

En outre - ne sous-estimez pas la valeur de verrouillage de ligne et MVCC (lecteurs ne bloquent pas les auteurs). Il peut être « plus lent » lorsque les écritures doivent persister sur le disque. Mais au moins vous ne serez pas bloque pendant cette opération d'écriture comme vous seriez sur une table de mémoire (pas MVCC, niveau de la table de verrouillage).

Answer 3

Pour l'enregistrement. Je l'ai testé tables Mysql en mémoire pour stocker des informations. Et je APC testé (UCPA) de PHP pour stocker les mêmes informations.

Pour 58000 registres. (Varchar + nombre entier + date).

1. Original information 24Mo au format texte (format csv).
2. APC PHP utilise 44.7mb de RAM.
3. Table Mysql utilise 575mb de RAM.

Le tableau ne comporte qu'un seul indice, donc je ne pense pas que ce soit le principal facteur.

Conclusion:

Tableau de mémoire est pas une option pour les tables "grandes" parce qu'il utilise trop de mémoire.

Answer 4

L'autre inconvénient des tables en mémoire est qu'ils ne peuvent pas être renvoyés plusieurs fois dans la même requête. Au moins que le comportement a été trouvé jusqu'à ce que la v5.4. Comment avec (depuis CTEs 8.x) il n'y a pas besoin d'utiliser des tables intermédiaires à base de mem-pour les procédures complexes.

Answer 5

tables de mémoire ne sont pas destinés à un stockage persistant, en particulier des grands sous-ensembles de données ou quoi que ce soit où la rétention est critique. Leur meilleur but de mon expérience est à la maison des enregistrements de transitoires lors de la création et de la population des tables temporaires au cours des procédures complexes, qui se classent beaucoup plus vite que la plupart des autres types de table à cet effet à condition que votre seuil clé de mémoire tampon pour le moteur est suffisamment élevé pour ne pas encourir une écriture sur le disque. Cela peut fonctionner un ordre de grandeur plus rapide que MyISAM ou InnoDB à cet effet car il n'y a pas de disque d'E / S, et dans le cas d'une table qui est encapsulé dans une procédure spécifique, l'indexation et les relations ne portent pas autant d'importance qu'ils Would où la persistance est attendue.

Answer 6

Selon les manuels MySQL et MariaDB, et blob CLOB (divers types de texte) ne sont pas pris en charge par le stockage MEMORY. Pour nos propres fins, cela fait le moteur de stockage MEMORY presque inutile.

http://dev.mysql.com /doc/refman/5.7/en/memory-storage-engine.html

  

tables de mémoire ne peut pas contenir des colonnes BLOB ou TEXT.

https://mariadb.com/kb/en/mariadb/ La mémoire de stockage de moteur /

  

types de longueur variable comme VARCHAR peuvent être utilisés dans des tables de mémoire. colonnes BLOB ou TEXT ne sont pas pris en charge pour les tables de mémoire.

Lorsque vous essayez de convertir une partie seulement de la base de données dans la mémoire à, je trouve que le moteur entre le stockage des clés étrangères ne sont pas pris en charge. Ainsi, toutes les tables, qui devraient avoir des références clés étrangères aux tables, contenant blob / CLOB devrait également être dans les types de stockage non-mémoire (au moins, cela affecte les tables enfants InnoDB).

Answer 7

En plus des réponses précédentes. tout droit du manuel 5.7 MySQL:

« performances de la mémoire est limitée par affirmation résultant de l'exécution monothread et les frais généraux de verrouillage de la table lors du traitement des mises à jour. Cette évolutivité des limites lorsque la charge augmente, en particulier pour les mélanges de déclaration qui comprennent les écritures. »

... et ceci est une limitation très réelle. Par exemple: lorsque vous avez plusieurs sessions en essayant de créer de belles tables temporaires de la mémoire rapide simple filetage peut provoquer un sérieux goulot d'étranglement de performance

.