Si estás trabajando o tienes pensado trabajar en algún proyecto que requiera MySQL o MariaDB, o incluso cualquier producto basado en MySQL, es ideal que entiendas la gran variedad de “motores de almacenamiento” (aproximadamente 20 o más) para que puedas seleccionar correctamente el más conveniente para tu proyecto.
¿Qué son los motores de almacenamiento?
Los motores de almacenamiento son un grupo de funciones de DBMS estrechamente relacionadas con el nivel físico o la base de datos almacenada.
Un motor de almacenamiento (mecanismo de almacenamiento o Storage Engine en Inglés) es similar a un componente de software básico, oculto entre las capas más bajas de un DBMS y se usa para crear, leer, actualizar y eliminar datos. El término “motor de almacenamiento” a menudo es utilizado de forma intercambiable con el de “DBMS” y el de “Servidor de Bases de Datos”.
Los “Motores de almacenamiento” son una parte esencial en la arquitectura de cualquier Sistema Manejador de Base de Datos. A veces su importancia es ignorada, si consideramos otras características del DBMS tales como: soporte para vistas, transacciones, concurrencia, bloqueos, replicación, seguridad, etc.
¿Dónde se ubican las funciones de los motores de almacenamiento?
Considerando como referencia la arquitectura de MySQL que se compone de 3 capas:
- La primera es la capa donde residen los servicios de conexión, autenticación, seguridad, etc.
- La segunda capa es ocupada por componentes tales como: análisis de consultas, caché, optimización, funciones integradas para procesamiento de fechas, horas, cálculos, encriptación, etc. Aquí también se localizan las funciones que aportan los motores de almacenamiento como: vistas, disparadores, procedimientos almacenados, etc.
- La última capa contiene los diferentes motores de almacenamiento.
Cada motor de almacenamiento tiene sus propios beneficios pero también sus desventajas. El servidor se comunica con ellos a través de la API del DBMS, esta es la encargada de ocultar las diferencias existentes entre los diferentes motores de modo tal que su uso sea transparente en la capa del segundo nivel.
¿En que sistemas podemos encontrar la diversidad de motores?
Son de amplio uso tanto en MySQL como en cualquiera de los forks existentes: Percona, MariaDB, Dizzle, versiones MySQL modificadas de Google, Facebook, eBay, Amazon, RedHat, Ubuntu, Debian, las comunidades Open Source relacionadas e incluso desarrollos de terceros cuyos motores son de aplicación muy específica. Un ejemplo de esto último es TokuDB, reservado para escalar en bases de datos verdaderamente grandes que sobrepasan los 10 TeraBytes.
De ahora en adelante, en este artículo usaré el término “motores de almacenamiento” para referirme a los motores de almacenamiento derivados de la arquitectura de MySQL que son el caso de estudio.
¿Cómo se manipula la información de las tablas?
El DBMS almacena la base de datos, usando para ello el sistema de archivos del sistema operativo, como un subdirectorio con el nombre que especifiquemos al momento de su creación y bajo el directorio de datos que indicamos al momento de la instalación del producto. Luego cuando creamos una tabla, el DBMS crea un archivo .frm, que contiene la definición de la tabla nada más.
Sin embargo, los datos de las tablas e índices son manipulados por el motor de almacenamiento y esto se hace de una manera muy diferente a la del sistema de archivos. En todo caso, el DBMS maneja la definición de la tabla y se comunica con el motor de almacenamiento a través de la API para manipular sus datos, no puede hacerlo directamente.
Cada tabla tiene asociado un motor de almacenamiento e hipotéticamente podríamos usar muchos dentro de una misma base de datos, aunque esto no es recomendable como veremos más adelante. Para ver el tipo de motor que usa una tabla solo tenemos que ejecutar el siguiente comando en el prompt del DBMS:
MariaDB> SHOW TABLES STATUS LIKE 'nombreTabla' \G;
Esto devuelve como resultado una fila donde podremos observar el nombre del motor que está usando la tabla, en el campo Tipo o Engine.
Listado de Motores de Almacenamientos
Entre los motores más importantes que estudiaremos hoy se encuentran:
- InnoDB,
- MyISAM,
- Un grupo de motores integrados, entre ellos: Archive, Blackhole, CSV, Federated, Memory, Merge, NDB Cluster.
- Otro grupo de motores de terceros, entre ellos: motores orientados a transacciones en línea, orientados al almacenamiento por columnas y algunos de la comunidad.
InnoDB
Es el tipo de motor predeterminado en MySQL y en MariaDB a partir de la versión 10.2; es el más importante y utilizado entre todos los motores mencionados. Fue diseñado para el procesamiento de muchas transacciones de vida corta, aquellas que finalizan en commit con rollbacks poco frecuentes.
¿Por qué es tan importante InnoDB?
Una transacción se define como una unidad lógica de trabajo que se caracteriza por encapsular una sección de código donde se llevan a cabo la manipulación de la base de datos. Por lo general, involucra la consistencia de los datos en una o varias tablas.
Las transacciones ofrecen la ventaja que mantienen el estado de una base de datos de forma consistente. Su desempeño así como la recuperación de fallos hace que sea también preferible a los motores que no soportan transacciones.
El soporte para transacciones así como la concurrencia está profundamente arraigado en los fundamentos de bases de datos relacionales o de cualquier otro tipo desde sus inicios y es ahí donde InnoDB demuestra su mayor fortaleza, y la razón por la cual Oracle como propietario de dicha tecnología basó su estrategia de negocios años atrás hasta la adquisición de MySQL en el 2010.
¿Son las transacciones una unidad de recuperación?
Definitivamente sí, las transacciones hacen posible la recuperación de los datos a un estado correcto, cuando ocurran fallos, los cuales son inevitables, tales como:
- Fallas locales: que afecta únicamente a la transacción que se está ejecutando en una máquina; por ejemplo un error de división por cero en el código dentro de una transacción puede hacer que la ejecución del programa se interrumpa, dejando la base de datos en un estado inconsistente.
- Fallos globales: que afectan a un grupo de transacciones que estén en progreso. Por ejemplo una falla de electricidad que podría alcanzar a muchos equipos simultáneamente en una empresa.
- Fallos del medio de almacenamiento: como por ejemplo cuando se daña el disco duro donde se almacena la base de datos y no se cuenta con un respaldo actualizado.
¡Créanlo, son problemas que sí suceden!
¿Pueden ser consideradas las transacciones como unidad de concurrencia?
¡Completamente! El concepto de transacciones está estrechamente relacionado al de concurrencia. Esto se refiere a que los DBMS permiten que muchas transacciones accedan a una misma base de datos o porción al mismo tiempo. Debido a esto, se necesita un tipo de mecanismo para que las transacciones no interfieran entre sí, dejando a la base de datos en un estado inconsistente; y esta es la razón por la cual han surgido con el tiempo diferentes mecanismos, tales como los bloqueos, cuya principal amenaza es el “bloqueo mortal” (deadlock), seriabilidad, niveles de aislamiento, bloqueos por aproximación y muchos más.
No todos los sistemas detectan los bloqueos mortales, sino que algunos usan un mecanismo de tiempo y asumen que una transacción que no ha realizado cierto trabajo durante un período dado, está bloqueada mortalmente. InnoDB basa su fortaleza a que implementa Control de Concurrencia Multiversión mejor conocido como MVCC, poniéndose a la par de Oracle, PostgreSQL y otros sistemas que también lo usan.
¿Qué otras ventajas ofrece InnoDB?
Es muy recomendable, para lograr un buen desempeño de InnoDB, el uso de claves primarias pequeñas de modo que las claves secundarias también lo sean cuando tienes muchos índices en una tabla. InnoDB tiene una buena variedad de optimizaciones internas como la lectura predictiva para recuperar datos del disco, índices hash en memoria para hacer las búsquedas más rápidas y buffers de inserts para acelerar las inserciones.
InnoDB también soporta respaldos en línea mientras que otros motores no son capaces de hacerlo muy bien. Además puedes usar tanto herramientas propietarias de Oracle en el caso de “MySQL Enterprise Backup” y Open Source como “Percona Xtra Backup”.
Estas ventajas para el desarrollo de sistemas de base de datos relacionales, hacen que no deberías dudar a la hora de elegir a InnoDB para todas tus tablas. A menos que tengas pensada una necesidad muy diferente que justifique la elección de otro motor.
MyISAM
Es la versión predeterminada de MySQL 5.1 y una de las más antiguas; proporcionando características como indexado de texto (full-text indexing), compresión y funciones espaciales GIS. No soporta transacciones, en su lugar usa el bloqueo a nivel de archivo que es mucho más limitado. En consecuencia no es seguro ante fallas de modo que el sistema no puede recuperar una base de datos automáticamente. Sin embargo, existen casos donde necesites trabajar con datos de solo-lectura o de tablas que no sean tan grandes que no importe repararlas; y donde las características de eficiencia de MyISAM sean de mucha ayuda. Vale la pena recordar que la característica para indexamiento de texto fue incorporada recientemente a InnoDB en la versión 5.6 de MySQL; y MariaDB en sus tres motores Aria, MyISAM e InnoDB.
Algunas tablas casi nunca cambian, una vez que son creadas y rellenas con datos, como por ejemplo las tablas de definiciones o maestras. Podrían ajustarse muy bien a las tablas MyISAM que están comprimidas. Las filas de una tabla son comprimidas individualmente, así que el DBMS no necesita descomprimir el archivo completo si hay una consulta que recoja una o pocas filas.
Su ligero diseño supone un almacenamiento de datos compacto y su baja sobrecarga de procesamiento supone una buena alternativa de desempeño para algunos usuarios. Aunque su punto más débil continúe siendo el bloqueo de tablas y por consiguiente si te encuentras en una situación de consultas que estén tardando mucho puede ser sin lugar a dudas debido a esto.
¿Qué otros motores integrados hay?
Existe una variedad de motores de propósito general que vienen integrados con el DBMS, muchos de los cuales han sido desplazados en versiones más nuevas. Algunos de estos aún están disponibles, pero deben ser habilitados especialmente.
Archive
Soporta sólo comandos INSERT y SELECT, pero no soporta índices. Proporciona un mejor desempeño que MyISAM, en cuanto a operaciones de Entrada/Salida; guarda en buffer la escritura de datos y comprime cada fila en la medida que son insertadas. Las operaciones SELECT requieren una búsqueda completa en toda la tabla (porque no hay índices). Así su aplicación “calza” más con tablas usadas para registro (logging) y adquisición de datos, donde los análisis tienden a hacer búsquedas de tabla completa o donde se requiere insertar rápidamente con muchos registros.
Posee características que la confunden con motores transaccionales; pero en realidad no lo es. Simplemente es un motor optimizado para la inserción de alta velocidad y almacenamiento comprimido.
Blackhole
No es un motor, descarta cada INSERT en vez de almacenarlo. Sin embargo el servidor lleva un registro log cada vez que se hace uso de una tabla de este tipo. Así, esta información de los logs puede ser replicada o simplemente mantenida allí. Esto hace que sea aplicable de cierta manera para el proceso de replicación y auditoría; aunque los comandos UPDATE y DELETE no disparan los triggers sobre este tipo de tablas, así que es recomendable tomar previsiones.
CSV
Puede tratar archivos CSV (archivos de texto que contienen valores separados por comas) como tablas, pero no soporta índices sobre estos. Pueden ser útiles como un formato de intercambio de archivos. Permite que se copien dentro y fuera de la base de datos mientras el servidor está ejecutándose. Por ejemplo, si exportamos una hoja de cálculo como CSV y lo guardamos en el directorio de datos del servidor, puede ser leído inmediatamente por el DBMS; y viceversa si tenemos datos en una tabla CSV, un programa externo puede leerla inmediatamente.
Memory
Antíguamente denominadas tablas HEAP, son útiles cuando se necesita rápido acceso a datos que nunca cambian o no necesitan persistir después de un reinicio del DBMS. Son más rápidas que las tablas MyISAM, cuando ocurre un reinicio la estructura sobrevive pero los datos no.
Algunas aplicaciones son: mapeo de códigos, resultados intermedios cuando analizamos datos, almacenamiento temporal de resultados de cálculos de resumen sobre columnas de datos y ejecución de pruebas automatizadas. Estas tablas no pueden soportar tipos de datos de longitud variable como TEXT, BLOB, y VARCHAR.
Merge
Es la combinación de varias tablas idénticas MyISAM, cuya estructura es la misma incluso en cuantos a índices y posición de los campos, en una sola tabla virtual MyISAM. Puede ser útil cuando se usan aplicaciones de registro (logging) y minería de datos (data warehousing); pero ha sido desplazado a favor de motores de particionamiento.
Federated
Es una especie de Proxy a otros servidores. Este abre una conexión de cliente en un servidor remoto y ejecuta las consultas en contra de una tabla que está almacenada allá; obteniendo y enviando filas como sea necesario. Ya que ha sido una fuente de muchos problemas está desactivada por defecto. Un sucesor está disponible en MariaDB como FederatedX. Una aplicación puede ser un servidor MySQL/MariaDB que se comunica con otro servidor remoto que también debe ser MySQL/MariaDB para obtener datos actualizados de alguna tabla de algún tipo compatible con Federated como son MyISAM, CSV e InnoDB. Actualmente se hacen esfuerzos para lograr que se comunique con un servidor remoto diferente como por ejemplo PostgreSQL.
NDB Cluster
Es una interface entre el SQL usado en MySQL y el protocolo NDB nativo. La combinación de MySQL, NDB Cluster Engine y la base de datos distribuida de NDB es lo que se conoce como MySQL Cluster. Este motor es tan interesante que sería preferible tratarlo como un artículo por sí mismo.
En nuestro próximo artículo presentaremos la segunda parte de este interesante tema que tiene que ver con los motores de almacenamiento de terceros y una guía para elegir la mejor alternativa. Únete a nuestro listado de emails y síguenos en Twitter para mantenerte al día:
Regístrate hoy en Styde y obtén acceso a todo nuestro contenido.
