2010-01-05 13 views
5

Estamos ejecutando un sitio de red social que registra la acción de cada miembro (incluida la visita a las páginas de otros miembros); esto implica muchas escrituras en el db. Estas acciones se almacenan en una tabla MyISAM y como algo está empezando a afectar a la CPU, mi primer pensamiento fue que es el bloqueo de la tabla de MyISAM lo que está causando este estrés en la CPU.Convirtiendo MyISAM a InnoDB. ¿Beneficioso? ¿Consecuencias?

  • Solo hay lecturas y escrituras, no hay actualizaciones en esta tabla. Creo que el equilibrio entre las lecturas y las escrituras es de aproximadamente 50/50 para esta tabla, ¿sería por lo tanto InnoDB una mejor opción?
  • Si quiero cambiar la tabla a InnoDB y no utilizamos restricciones de clave externa, transacciones o índices de texto completo, ¿tengo que preocuparme por algo?
+0

http://stackoverflow.com/questions/20148/myisam-versus-innodb – Bozho

+0

Esto no es un duplicado de lo anterior, ya que se trata de la migración en lugar de los beneficios per se. – MarkR

+0

También puede usar una combinación de tablas, manteniendo MyISAM para tablas de lectura pesada e InnoDB para los registros. Sin embargo, yo personalmente no usaría MyISAM para nada mucho hoy (solo texto completo). – bobince

Respuesta

7

A pesar de los beneficios/inconvenientes de su uso, que se analizan en otros hilos (MyISAM versus InnoDB), la migración es un proceso no trivial.

Considere

  • Funcionalmente pruebas de todos los componentes que hablan con la base de datos si es posible - los motores de diferencia tienen una semántica diferente
  • Operando tanto las pruebas de rendimiento como se puede - algunas cosas pueden mejorar, otros pueden ser mucho peor . Un ejemplo conocido es SELECT COUNT (*) en una tabla grande.
  • Comprobando que todo su código manejará correctamente los interbloqueos: puede obtenerlos sin el uso explícito de las transacciones
  • Calcule cuánto espacio de espacio obtendrá al convertir: pruebe esto en un entorno que no sea de producción.

Sin duda tendrá que cambiar las cosas en una plataforma de software grande; esto está bien, pero dado que usted (con suerte) tiene mucha cobertura de autoprueba, el cambio debería ser aceptable.

PD: Si "Algo está empezando a gravar la CPU", entonces debe a) Averiguar qué, en un entorno que no es de producción, b) Pruebe varias opciones para reducirlo, en un entorno que no sea de producción. No debe comenzar ciegamente a hacer cosas importantes como cambiar los motores de base de datos cuando no haya analizado por completo el problema.

Todas las pruebas de rendimiento se deben realizar en un entorno que no sea de producción, con datos similares a la producción y en hardware de grado de producción. De lo contrario, es difícil interpretar los resultados correctamente.

+1

Muchas gracias por esta información. ¿Podrías profundizar en las "diferentes semánticas"? – stef

2

Creo que es muy posible que cambiar a InnoDB mejore el rendimiento, pero en mi experiencia, no puedes estar seguro hasta que lo pruebes. Si yo fuera usted, establecería un entorno de prueba en el mismo servidor, convertiría a InnoDB y ejecutaría un punto de referencia.

4

Con respecto a otros posibles problemas de migración:

1) Espacio - tablas InnoDB a menudo requieren más espacio en disco, aunque el formato de archivo Barracuda para las nuevas versiones de InnoDB han reducido la diferencia. Puede hacerse una idea de esto al convertir una copia de seguridad reciente de las tablas y comparar el tamaño. Use "mostrar el estado de la tabla" para comparar la longitud de los datos.

2) la búsqueda de texto completo - sólo en MyISAM

3) SIG/tipos de datos espaciales - sólo en MyISAM

en el rendimiento, como las otras respuestas y la respuesta que se hace referencia indican, que depende de su carga de trabajo. MyISAM es mucho más rápido para escaneos completos de tablas. InnoDB tiende a ser mucho más rápido para un acceso altamente concurrente. InnoDB también puede ser mucho más rápido si sus búsquedas se basan en la clave principal.

Otro problema de rendimiento es que MyISAM siempre puede mantener un recuento de filas, ya que solo bloquea el nivel de la tabla. Por lo tanto, si con frecuencia intenta obtener el recuento de filas para una tabla muy grande, puede ser mucho más lento con InnoDB. Busque en Internet si necesita una solución para esto, ya que he visto varios propuestos.

Dependiendo del tamaño de la (s) mesa (s), es posible que también deba actualizar su archivo de configuración de MySQL. Por lo menos, es posible que desee cambiar los bytes de key_buffer a innodb_buffer_pool_size. No obtendrá una comparación justa si deja la base de datos optimizada para MyISAM. Lea todas las propiedades de configuración de innodb_ *.

0

Desde mi experiencia, las tablas MyISAM solo son útiles para la indexación de texto donde necesita un buen rendimiento con búsquedas en texto grande, pero aún no necesita un motor de búsqueda completo como Solr o ElasticSearch.

Si desea cambiar a InnoDB, pero desea mantener la indexación de su texto en una tabla MyISAM, le sugiero que tome un vistazo a esto: http://blog.lavoie.sl/2013/05/converting-myisam-to-innodb-keeping-fulltext.html

también: InnoDB soporta copias de seguridad atómicas en vivo utilizando innobackupex de Percona. Esto es divino cuando se trata de servidores de producción.

Cuestiones relacionadas