¿Cuáles son las razones * * No utilizar el motor de almacenamiento de memoria en MySQL?

Question

Recientemente he descubierto que MySQL tiene un motor de "memoria" que no estaba al tanto de (la mayor parte de mi trabajo es la base de datos de proyectos de hobby, así que aprender lo que necesito como voy). Parece que esta opción debe dame drásticamente mejor rendimiento, por lo que estoy preguntando si hay algún inconveniente que van con él. Los dos que yo sepa son:

1. Es necesario disponer de suficiente memoria RAM para mantener la tabla (s) en cuestión.
2. Las tablas se pierden si se cierra la inactividad de la máquina.

Creo # 1 no debería ser un problema ya que estoy usando AWS EC2 y pueda desplazarse a un tipo de instancia con más memoria si es necesario. Creo que puedo mitigar # 2 por vertimiento de vuelta al disco, según sea necesario.

¿Qué otros problemas hay? ¿Puede el motor de la memoria nunca dará un peor rendimiento que cualquiera MyISAM o InnoDB? Creo que leí algo que los índices son diferentes con este motor; esto es algo que hay que preocuparse por?

Answer 1

En cuanto a la lista de disponibilidad de funciones en http: / /dev.mysql.com/doc/refman/5.1/en/memory-storage-engine.html dos posibles problemas saltan a:

1. No hay ninguna transacción o soporte FK, lo que significa que tendrá que gestionar la integridad de las transacciones e integridad referencial en su propio código eran necesarios (que podría llegar a ser mucho menos eficiente que dejar que el DB hacer esto para usted, sin embargo, que depende en gran medida en los patrones de comportamiento que se espera de su aplicación).
2. Nivel de tabla de bloqueo solamente: esto podría ser un obstáculo importante para la escalabilidad si su aplicación necesita varios escritores concurrentes para el mismo conjunto de tablas o en los casos en sus operaciones de lectura utilizan bloqueos para asegurar que se lee de datos consistente - en estos casos un disco tabla en función de que la granularidad de bloqueo soportes mucho más fina llevará a cabo mucho mejor si lo suficiente de su contenido se almacena en caché actualmente en la memoria RAM.

Aparte de eso, suponiendo que tiene suficiente memoria RAM, una tabla basada memoria debe ser más rápido que una basada en disco. Obviamente se necesita un factor en la toma de instantáneas en el disco para abordar la cuestión de lo que sucede cuando la instancia del servidor se pone a cero, que es probable que negar por completo la ventaja de rendimiento en general, si las necesidades de datos de captura de frecuencia (si se puede vivir con la pérdida de un día de datos en tal caso sólo podría tener una copia de seguridad una vez al día, pero en la mayoría de los casos que no serían aceptables).

Una alternativa podría ser:

1. Uso de disco tablas basadas, pero asegúrese de que tiene más que suficiente memoria RAM para contener a todos en la memoria RAM en un momento dado (y "suficiente memoria RAM" podría ser más de lo que cree que necesita tener en cuenta a cualquier otro proceso en el máquina, tampones OS IO / cache y así sucesivamente)
2. Analiza el contenido completo (todos los datos y páginas de índice) de la tabla en cada inicio para precargar el contenido en la memoria con SELECT * FROM <table> ORDER BY <pkey fields> para cada tabla seguido por SELECT <indexed fields> FROM <table> ORDER BY <index fields> para cada índice

De esta manera todos los datos están en la memoria RAM, sólo tiene que preocuparse por el rendimiento de E / S para operaciones de escritura. Si conjunto común de trabajo de su aplicación es mucho más pequeño que todo el PP (que suele ser el caso - en la mayoría de las aplicaciones de la mayoría de los usuarios sólo se busca en los datos más recientes más si el tiempo) que podría ser mejor de ser más selectivos acerca de cuánto escanea a precarga en la memoria, permitiendo que el resto se va a cargar desde el disco bajo demanda.

Answer 2

Hay un montón de casos de no utilizar el motor de almacenamiento de memoria - y cuando InnoDB será más rápido. Sólo tiene que pensar en la concurrencia y las pruebas de un solo subproceso no triviales.

Si usted tiene un grupo de búfer suficientemente grande, entonces InnoDB se convertirá en su totalidad residente en memoria para operaciones de lectura también. Bases de datos Tienes cachés . Se calientan a sí mismos!

También - no hay que subestimar el valor de nivel de fila de bloqueo y MVCC (lectores no bloquean los escritores). Puede ser "más lento", cuando las escrituras tienen que persistir en el disco. Pero al menos no se le bloqueando durante esa operación de escritura como lo haría estar en una tabla de memoria (sin MVCC; nivel de tabla de bloqueo).

Answer 3

Para el registro. Probé las tablas de MySQL en la memoria para almacenar información. Y he probado APC de PHP (UCPA) para almacenar la misma información.

Para 58000 registros. (Varchar + número entero + fecha).

1. Información original de 24 MB en formato de texto (formato csv).
2. APC PHP usa 44.7mb de RAM.
3. Tabla de MySQL usa 575mb de RAM.

La tabla sólo tiene un único índice, así que no creo que es el factor principal.

Conclusión:

tabla de memoria es no es una opción para las tablas "grandes" , ya que utiliza demasiada memoria.

Answer 4

La otra desventaja de las tablas en memoria es que no se puede hacer referencia varias veces en la misma consulta. Al menos se ha encontrado que el comportamiento hasta la v5.4. Como con las CTE (desde v8.x) no hay necesidad de utilizar mem-basada mesas intermedios para procedimientos complejos.

Answer 5

Las tablas MEMORY no están destinados para el almacenamiento persistente, sobre todo de grandes subconjuntos de datos o cualquier cosa que la retención es crítica. Su mejor fin de mi experiencia es que los registros de la casa transitorios durante la creación y la población de las tablas temporales en procedimientos complejos, que lleva a cabo mucho más rápido que la mayoría de los otros tipos de tabla a este efecto siempre que su umbral de búfer clave para el motor se encuentre lo suficientemente alto como para no incurrir una escritura en disco. Esto puede operar un orden de magnitud más rápido que MyISAM o InnoDB para este propósito ya que no hay disco I / O, y en el caso de una tabla que está encapsulado dentro de un determinado procedimiento, la indexación y las relaciones no soporto tanta importancia, ya que Would donde se espera que la persistencia.

Answer 6

Según MySQL y MariaDB manuales, BLOB y CLOB (diversos tipos de texto) no están soportados por almacenamiento de memoria. Para nuestros propósitos, esto hizo que el motor de almacenamiento MEMORY casi inútil.

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

Las tablas MEMORY no puede contener BLOB o TEXT columnas.

https://mariadb.com/kb/en/mariadb/ memoria de almacenamiento-motor /

tipos de longitud variable como VARCHAR se pueden utilizar en las tablas MEMORY. BLOB o TEXT columnas no son compatibles con las tablas de memoria.

Cuando se trata de convertir sólo una parte de la base de datos en la memoria de almacenamiento, he encontrado que las claves externas del motor entre el almacenamiento no son compatibles. Por lo tanto, todas las mesas, que deben tener referencias de claves externas con las tablas, que contienen BLOB / CLOB también debe estar en tipos de almacenamiento no de memoria (por lo menos, esto afecta a los niños mesas InnoDB).

Answer 7

Además de las respuestas anteriores. directamente desde el MySQL 5.7 Manual:

"rendimiento de la memoria está limitado por la contención resultante de la ejecución de un solo hilo y la sobrecarga de bloqueo de tabla al procesar actualizaciones. Esto limita la escalabilidad cuando aumenta la carga, en particular para mezclas de los estados que incluyen escribe."

... y esto es una limitación muy real. Por ejemplo: cuando tiene múltiples sesiones que tratan de crear buenas tablas temporales de memoria rápida el single-threading puede causar un cuello de botella graves

.