Disipando el mito
En este artículo se presenta una comparación entre los motores MyISAM e InnoDB para MySQL. InnoDB es comúnmente considerado un peor desempeño que MyISAM, pero este artículo tiene como objetivo disipar este mito con la descripción de las diferencias entre estos motores y lo que hace que InnoDB una buena opción para las necesidades de base de datos de muchos.
¿Por qué utilizar InnoDB?InnoDB es comúnmente visto como cualquier cosa menos performante, especialmente en comparación con MyISAM. De hecho, muchos lo llaman lento. Esta opinión es apoyada por la mayoría de edad y los hechos información errónea. En realidad, sería muy duro para encontrar un curso, con calidad de producción del motor de base de datos MySQL con la eficiencia de la CPU de InnoDB. Tiene sus rarezas rendimiento y definitivamente hay carga de trabajo para el cual no es óptimo, pero para el estándar de OLTP (procesamiento de transacciones en línea) las cargas, es difícil encontrar una forma mejor, más segura.
Rendimiento Las demandas de rendimiento de InnoDB no están ociosos, hay números que lo respalden y puntos de referencia a cargo de algunas de las más respetadas empresas de consultoría de MySQL en la existencia. Por ejemplo, la gente detrás de mysqlperformanceblog.com, un líder de optimización de MySQL y el sitio de optimización a cargo de Percona [ 1 ], corrió un punto de referencia la comparación de Falcón, MyISAM y InnoDB. El índice de referencia se supone que realmente se destaca Falcón, excepto que era InnoDB que ganó el día, superando tanto a Falcón y MyISAM en las consultas por segundo en casi todas las pruebas: http://www.mysqlperformanceblog.com/2007/01/08/innodb -vs-myisam-vs-falco ...
Hay tendencias interesantes en estos gráficos. InnoDB utiliza los índices de "conglomerados". Esto significa que los datos de la tabla se almacena en las "hojas" del índice de clave principal, por lo tanto no hay necesidad de buscar la información de la fila por separado. Esta es también una de las razones de reputación InnoDB de tener una gran capacidad de memoria. Cuando usted está usando MyISAM, el key_buffer se carga con sólo el índice de la tabla. Por el contrario, cuando InnoDB amortigua su índice está implícitamente búfer de los datos de la tabla, así como los topes innodb_buffer_pool en el nivel de página de memoria. [ 8 ] Como se pueden imaginar, esto puede conducir a un excelente rendimiento y requisitos de memoria de gran tamaño.
Esta técnica de cluster claves primarias es una de las razones para el margen bastante grande en los puntos de referencia entre MyISAM e InnoDB, cuando la consulta en cuestión utiliza la clave principal de un rango. ¿Qué es un tanto sorprendente, sin embargo, es que InnoDB todavía gana en los ensayos que utilizan un índice secundario. Esto es reconfortante, ya que muestra que el rendimiento del motor no es sólo sobre la base de la agrupación clave, un aumento de rendimiento que es muy dependiente de consulta.
InnoDB emplea algunos trucos con otros índices también. Se pueden construir índices de adaptación "hash" para las consultas frecuentes y lo hace cuando una tabla entera se acerca a colocar en la memoria. [ 5 ] Estos índices hash son un poco más rápido que el estándar de índice de BTree (cuando la mesa está en la memoria). De nuevo, esta es otra mejora significativa del rendimiento a expensas de uso de la memoria.
Volviendo a la referencia más arriba, también podemos ver que InnoDB todavía tiene algunos problemas de escala cuando llegue a los números de hilo de alta (causada por muchas conexiones concurrentes o peticiones). Se trata de un problema conocido y al mismo tiempo que mejora con la mayoría de las versiones principales, es bueno tener en cuenta. Incluso con este tema, InnoDB se utiliza a menudo de forma explícita para permitir la concurrencia.
Concurrencia La ironía es que mientras que InnoDB tiene algunos problemas de bloqueo de exclusión mutua en un alto nivel de concurrencia, se tiende a utilizar para permitir a la concurrencia en absoluto. Un problema importante con MyISAM es la falta de bloqueo a nivel. Esto significa que Drupal utiliza bloqueos explícitos de mesa en algunas rutas críticas y las tablas que están implícitamente bloqueada en muchos que no son críticos caminos, aquellos que implican cambios o insertos en medio de una tabla no optimizado (que engloba a la mayoría de las inserciones y actualizaciones). El bloqueo de filas significa que estos bloqueos implícitos por lo general no ocurren. Drupal se puede conectar a eliminar muchos de los bloqueos de tabla de rutas críticas, ya que ya no son necesarios. Bloqueo de la cordura está garantizada en el nivel de motor, y permite muchas más operaciones simultáneas, por lo que muchos más en el hecho de que usted puede tener que limitar el número de temas que entran en el núcleo de InnoDB para evitar que el servidor de base de datos de paliza. Este es un problema mucho mejor tener a un límite de rendimiento artificial a partir de los bloqueos de tabla, pero es un problema, no obstante.
Un buen ejemplo de ejecución de distancia de concurrencia se produjo con el servidor de base de datos de drupal.org a principios de 2007. Nos habían convertido sólo para InnoDB y aplicar parches a Drupal para quitar bloqueo de las rutas críticas. En ese momento, estábamos usando una versión de MySQL que por defecto tiene un número ilimitado de hilos del núcleo InnoDB. Fue más o menos una hora antes de chocar con los picos de uso del suelo y del servidor a su fin. En cuanto a la lista de procesos MySQL y salida de vmstat, es fácil ver lo que estaba pasando. Hemos tenido tantos procesos simultáneos que el cambio entre ellos (y la inherente a los techos de los que) fue impedir que algunos de ellos de avanzar a un ritmo razonable. Esto es lo que hay que tener en cuenta y por qué de los límites del núcleo InnoDB hilos son útiles.
Confiabilidad Cualquier administrador de base de datos se asegura de tener la misma pesadilla, llamar a un cliente para decirles que sus datos están dañados o se han ido solo plano-hacia fuera. MyISAM no ayuda a estas preocupaciones, ya que garantiza casi no la integridad de datos. Los fallos de hardware, las paradas no cancelados y las operaciones son sólo algunos de los eventos que pueden conducir a la corrupción MyISAM. Hay excelentes herramientas para recuperarse de esto, pero no se garantiza que el trabajo y su uso requiere tiempo de inactividad a veces, una amplia mesa para los controles y reparaciones.
Por otro lado, InnoDB es un motor de gran parte ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad), construido para garantizar la consistencia y durabilidad. Lo hace a través de un registro de transacciones (con la opción de una confirmación en dos fases, si usted tiene el registro binario activado), un doble buffer de escritura y la suma de comprobación automática y la validación de suma de comprobación de páginas de base de datos. Estas medidas de seguridad no sólo para prevenir la corrupción en el "duro" durante los paros, sino que incluso puede detectar un fallo de hardware (como la insuficiencia de memoria / corrupción) y evitar daños a sus datos.
Drupal.org ha hecho uso de esta característica de InnoDB también. La base de datos en cuestión contiene una gran cantidad de usuarios está contenido, mensajes, historial de cvs cvs, mensajes en foros, comentarios y, más críticamente, las colas de emisión para todo el proyecto de Drupal. Esto no es un dato donde la corrupción es una opción. En 2007, el servidor de base de datos principal para el proyecto se fue abajo. Después de examinar los registros, se hizo evidente que no se había estrellado, como tal, pero InnoDB había leído una suma de comprobación de disco que no se corresponde con la suma que tenía en la memoria. En este caso, la suma de comprobación de miss-partido fue un claro signo de corrupción de memoria. No sólo detectar esto, pero mató al demonio de MySQL para prevenir la corrupción de datos. De hecho, no dejar que el demonio de MySQL una duración de hora y media más que una en el servidor sin matarlo después de encontrar una suma de comprobación de miss-igualar. Cuando el dato es de suma importancia, este es un comportamiento muy reconfortante.
Seguridad de Datos En un tema relacionado, la naturaleza transaccional de InnoDB permite copias de seguridad sencillas y en línea. Un problema importante con MyISAM es que cualquier estrategia de copia de seguridad diseñado para sacar copias de seguridad garantizados, de conformidad requerirá bloqueos de tabla y cualquier estrategia que involucra a un punto en el tiempo de recuperación de registros binarios requiere un bloqueo de base de datos completa. Esto es totalmente inaceptable para una gran producción de calidad web. La única forma real de evitar esto es tener un servidor de base de datos de esclavos y sacar copias de seguridad de esa máquina.
InnoDB, por el contrario, puede ejecutar una tarea de copia de seguridad en una sola transacción y tire consistentes y amplias bases de datos de copias de seguridad con sólo un bloqueo corto al comienzo del trabajo. La facilidad de sacar estas copias de seguridad rápidamente se convierte en adicción y hace que sea mucho más fácil seguir los procedimientos de seguridad de copia de seguridad.
¿Por qué utilizar MyISAM? Sencillez Hasta ahora, este ha leído algo así como un anuncio pagado para InnoDB. Sin embargo, MyISAM tiene algunas ventajas muy reales. Una de ellas es la simplicidad del motor, se entiende muy bien y es fácil escribir herramientas de terceros para interactuar con él. Hay muy alta calidad, herramientas gratuitas, tales como mysqlhotcopy para MyISAM. Es mucho más difícil de escribir herramientas para un motor tan complicado como InnoDB, y esto puede ser visto fácilmente en el número de ellos disponibles. Además, esta simplicidad permite una facilidad de administración que no está allí con InnoDB.
Optimización Otra ventaja principal MyISAM es el tiempo que ha existido. Hay muchos sistemas, Drupal por ejemplo, que están muy optimizadas para que el motor en particular. Esto no quiere decir que funcionan mal en InnoDB, pero no están optimizados para ello. Por ejemplo, mientras que muchas de las preguntas básicas de Drupal están bien indexados y utilizar la clave principal (beneficiándose así de la agrupación primaria clave de InnoDB), algunos de ellos podrían ser mejorados. La tabla de nodo tiene una clave principal en (NID, vid). Tener este índice es una buena idea, pero es un índice de dos enteros y hay once índices secundarios sobre la base de la misma. Esto no significa mucho cuando se utiliza MyISAM, InnoDB, pero en virtud de que significa cada uno de los índices secundarios tiene dos hojas de tamaño entero que identifica la clave primaria.
Otro hecho, es que hay algunas cargas de trabajo MyISAM está mejor preparado. Por ejemplo, una función de Drupal funcionalidad de búsqueda realiza horriblemente en InnoDB por muy grandes conjuntos de datos, por ejemplo 100k + filas. Estas tablas están mejor dejar MyISAM. Afortunadamente, MySQL permite a los motores de mezcla de este tipo.
Uso de recursos Es fácilmente aceptado en ciencias de la computación que a menudo existe un trade-off entre velocidad y consumo de memoria. Hemos visto a través de los puntos de referencia sobre el que InnoDB tiene algunos algoritmos rápidos, sin embargo, esto tiene un precio. No sólo InnoDB utilizan más memoria que MyISAM, pero los archivos de datos reales son a menudo un poco más grande. Añadir a esto el hecho de que InnoDB tiene al menos un archivo de registro bastante grande y tiene un aumento significativo en el uso de recursos. Esto hace que MyISAM una buena opción para un servidor con recursos limitados. Sin embargo, si usted está preocupado en absoluto con los altos niveles de concurrencia, es probable que usted tenga los fondos para comprar un servidor que puede manejar estas demandas de recursos mayores.
Estado de los motores de MySQL con DrupalEn resumen, muchas de las preocupaciones históricas y los rumores de la lentitud de InnoDB son simplemente falsas. En la mayoría de los casos, InnoDB es la elección correcta para un sitio de Drupal. Proporciona una mayor simultaneidad, rendimiento mejorado y la integridad de los datos mucho más que nunca puede MyISAM. Sin embargo, la naturaleza de los motores de MySQL conectable permite al usuario "mezclar y combinar" los motores de tabla dentro de una sola base de datos. Esto nos permite considerar las cargas de trabajo cuya tablas MyISAM caben más de lo que InnoDB. Los principales candidatos a MyISAM InnoDB en un todo centrada en la base de datos son las tablas de búsqueda. Un diseño de base de datos con la mayoría de las tablas InnoDB es (para el rendimiento y la seguridad de los datos) y las tablas de búsqueda de ser MyISAM (para el rendimiento en la carga de trabajo en particular y reconociendo el hecho de que, en caso de que los datos se corrompió, que podría ser fácilmente reconstruida) es un excelente .
Determinación de los requisitos de recursos de InnoDBEs todo muy bien para agitar las manos y decir: "InnoDB claramente requiere mucha más memoria por estas razones," pero se pone un poco difícil de precisar con exactitud cuánto más memoria. Esto es cierto por varias razones:
1. ¿Cómo se carga la base de datos?
Tamaño de la tabla InnoDB no es una constante. Si usted tomó un volcado SQL recta a partir de una tabla MyISAM y lo insertaron en una tabla InnoDB, es probable más grande de lo que realmente debe ser. Esto es debido a que los datos se han cargado fuera de orden clave principal y el índice no está apretada por eso. Si usted tomó el vertedero con el argumento - por fin primordial de mysqldump, lo más probable es tener una tabla mucho más pequeña y se necesita menos memoria para amortiguar.
2. ¿Qué es exactamente el tamaño de su mesa?
Esta es una pregunta fácil de responder con MyISAM: que la información es directamente en la salida de "SHOW TABLE STATUS". Sin embargo, los números de la misma fuente para InnoDB se sabe que son sólo estimaciones [ 7 ]. Los tamaños de muestra son los tamaños físicos reservados para las mesas y no tienen nada que ver con el tamaño real de los datos en ese punto. Incluso el número de filas es una mejor estimación.
3. ¿Qué tan grande es su clave primaria?
Se mencionó anteriormente que los grupos de InnoDB los datos de una tabla en torno a la clave principal. Esto significa que las hojas de índices secundarios deben contener la clave principal de los datos que "apuntan a". Por lo tanto, si usted tiene tablas con una clave principal de gran tamaño, se necesita más memoria para amortiguar un índice secundario y más espacio en disco para mantenerlos. Esta es una de las razones por las que algunas personas argumentan en favor de cortos "artificiales" las claves principales para tablas InnoDB cuando no hay un "natural" la clave principal.
En resumen, no existe un método conjunto que funcione para todo el mundo para predecir los recursos necesarios. Peor que eso, los recursos necesarios va a cambiar con el tiempo a medida que más se inserta en la tabla de aumentar su tamaño y el fragmento del embalaje de la BTree. El mejor consejo que se ofrece es utilizar la herramienta mysqlreport disponible aquí ( http://hackmysql.com/mysqlreport ) para supervisar su innodb_buffer_pool disponibles y ajuste, el parámetro optimizable InnoDB más importante en consecuencia. Es importante que no funcionan al 100% el uso del buffer de InnoDB, ya que esto significa es probable que usted no está buffer ya todo lo que podía para lecturas, y que se está muriendo de hambre a su buffer de escritura, que también vive en la misma innodb_buffer mundial .
