MariaDB / Motores de almacenamiento

Bienvenidos sean a este post, hoy hablaremos sobre los distintos de tipos de engine que disponemos.

Podemos decir que un motor de almacenamiento o Storage Engine son los encargados de manipular la informacion a nivel fisico, dado que manejan los archivos de datos, los datos y los caches de indices o todo lo que sea necesario para manejar la informacion de manera satisfactoria, la excepcion son los archivos .frm porque por cada tabla existente tendra un archivo de esta extension dado que posee toda la informacion de la misma y es manejada por el servidor, tenemos dos formas de poder ver los engines o motores que soporta la base de datos, uno es:

SHOW ENGINES

El cual nos devolvera toda la informacion de los mismos, les dejo un ejemplo de que nos puede devolver:

      Engine: MRG_MyISAM
     Support: YES
     Comment: Collection of identical MyISAM tables
Transactions: NO
          XA: NO
  Savepoints: NO

Pero tambien podemos usar un query por medio de SELECT para obtenerlo de forma mas reducida:

select engine, support from information_schema.engines;

Este nos devolvera el nombre del engine y si lo soporta o no, veamos su salida:

MariaDB [(none)]> select engine, support from information_schema.engines;
+--------------------+---------+
| engine             | support |
+--------------------+---------+
| MRG_MyISAM         | YES     |
| CSV                | YES     |
| MEMORY             | YES     |
| MyISAM             | YES     |
| Aria               | YES     |
| InnoDB             | DEFAULT |
| PERFORMANCE_SCHEMA | YES     |
| SEQUENCE           | YES     |
+--------------------+---------+
8 rows in set (0.001 sec)

MariaDB [(none)]>

MariaDB [(none)]> select engine from information_schema.tables
    -> where table_schema='curso' and table_name='alumnos';

En este caso pedimos obtener la columna engine de la tabla que comentamos anteriormente pero usamos un condicional deonde le especificamos la base (table_schema) y la tabla (table_name) que debe buscar, su salida es la siguiente:

MariaDB [(none)]> select engine from information_schema.tables
    -> where table_schema='curso' and table_name='alumnos';
+--------+
| engine |
+--------+
| InnoDB |
+--------+
1 row in set (0.002 sec)

MariaDB [(none)]>

Con esto ya tenemos una forma de como podemos obtener la informacion de cual engine maneja nuestras tablas y/o bases pero ahora veremos una breve descripcion de cada una de ellas.

XtraDB e InnoDB

Como pudimos ver anteriormente InnoDB se convirtio en el engine predeterminado tanto para mysql como para mariadb, pero Perconna mantiene una variante de InnoDB llamada XtraDB la cual trabaja de la misma forma pero con unos cuantos bugs arreglados y algunas caracteristicas unicas, aqui vamos a contradecir lo anterior dado que XtraDB es el engine predeterminado para mariadb pero para mantener una cierta compatibilidad especialmente con mysql se lo sigue llamando InnoDB, aunque podemos modificar esta conducta simplemente volviendo a compilar el codigo pero haciendo que el engine predeterminado sea InnoDB aunque esto no es recomendable porque tendremos algunos inconvenientes relacionados a este.

Si bien InnoDB es un motor de almacenamiento de multiproposito y alta performance, que a su vez soporta transacciones con puntos de salvado, transacciones XA (protocolo de confirmación de dos fases) y claves extranjeras (foreign keys). Cuando hablamos de transacciones con puntos de salvado nos referimos que mientras se realiza la transaccion el motor ira salvando distintos puntos de la misma y en caso de falla podemos volver todo para atras o por lo menos hasta el punto que funciono correctamente, XA es un protocolo especial diseñado para transacciones con multiples recursos (no necesariamente bases SQL), y como dijimos por un tema de simplicidad y compatibilidad en los campos donde coinicidan InnoDB y XtraDB se nos informara que el tipo de engine es InnoDB pero en los que sea una caracteristica exclusiva de XtraDB se nos indicara este nombre, por ultimo mencionaremos que las transacciones estan realizadas por medio de un sistema complejo de locks y logs de Undo, la fila o filas que involucran a cada lock se almacenan en indices y los logs de undo se usan para las transacciones de vuelta atras o rollback y estan pueden ser almacenadas en tables o cualquier otro medio.

TokuDB

Este motor fue desarrollado por Tokutek y se incluye en mariadb desde la version 5.5, aunque se debe instalar y activar de forma separada, al igual que el anterior tambien soporta transacciones con puntos de salvado y transacciones XA pero no soporta claves foraneas (foreigns) pero su mayor particularidad es su forma de manejar los indices dado que lo realiza por medio de arboles fractales (fractal trees), estos son muy similares a lo llamado B-trees pero cada nodo tiene un buffer, estos nodos almacenan los cambios que se deben aplicar en los nodos mas profundos, y al igual que en cualquier buffer una vez que se completo aplica todos los cambios juntos, especialmente util para cuando necesitamos escribirlo en un disco, otra importante caracteristica es su comprension de datos, la cual estara sujeta al conjunto de datos que utilicemos pero en general es mucho mejor a cualquiera de los otros motores, tambien esta activado siempre de manera predeterminada y no se puede desactivar, debido a sus dos caracteristicas principales, arboles fractales y comprension, esta pensado para cuando debemos manejar grandes cantidades de informacion que no caben en memoria pero en terminos generales no trabaja mejor que los demas.

MyISAM y Aria

MyISAM fue el motor predeterminado de mysql y mariadb hasta antes de la version 5.5, al ser un engine relativamente simple se especializa en leer cargas de datos pesadas donde hay pocas o nulas escritos, por lo tanto es realmente bueno para recuperar la informacion pero no para administrarla, este siempre trabaja con dos archivos, en uno tendremos los datos y en otro los indices, con la particularidad de que en caso de corrupcion del segundo podemos restaurarlo sin inconvenientes, este dispone de tres tipos de formato de datos:

• FIXED, asigna un tamaño fijo al ancho de las columnas
• DYNAMIC, este se ajusta a la necesidad permitiendo ahorrar espacio
• COMPRESSED, es usado para crear pequeñas tablas de solo lectura

Obviamente entre los dos primeros tendremos sutiles diferencias, la primera esta pensada para cuando necesitamos performance y el espacio no es preocupante, en cambio la segunda es todo lo contrario dado que prioriza al espacio por sobre la performance.

Aria es tecnicamente la sucesora de MyISAM, trabaja de forma similar pero incorpora archivos logs que permiten su recuperacion despues de un inconveniente, los cambios de datos son atomicos, en lugar de usar los anteriores utiliza un formato denominado PAGE, que en general es mucho mas rapido y no se fragmenta demasiado, pero permite trabajar con FIXED y DYNAMIC para mantener una compatibilidad pero la tabla no sera crash-safe, ambos no soportan transacciones y claves foraneas pero cada declaracion en una tabla de Aria se puede considerar una transaccion, por ultimo tenemos a MRG MyISAM que tambien se puede denominar MERGE, la cual nos permite trabajar con multiples tablas identicas de MyISAM para trabajar alrededor de los limites de tamaño de los archivos en los sistemas operativos.

Estos son los mas generales pero a su vez existen otros motores:

• OQGRAPH, desarrollado por OpenQuery y se penso para manejar arboles y estructuras de datos graficos
• BLACKHOLE, heredado de mysql y siempre posee tablas vacias que no son afectadas por las modificaciones
• SPIDER, desarrollado por Kentoku Shiba, lee y escribe datos dentro de otras instancias de mariadb
• CONNECT, esta pensado especificamente para permitir leer y escribir datos desde y hacia recursos externos
• ARCHIVE, se encarga de manejar tablas comprimidas
• CassandraSE, nos permite conectarnos al servidor Apache Cassandra NoSQL para escribir y leer datos
• SphinxSE, se usa para permitir que mariadb pueda acceder a una tabla que este almacenada en un servidor Sphinx
• mroonga, se diseño especificamente para busquedas de texto completas
• SEQUENCE, no puede ser usado para crear tablas fisicas pero si virtuales
• performance_schema, es usado solamente para las tablas en las bases de datos de performance_schema

En resumen, hoy hemos visto sobre los motores de almacenamiento, que son, como trabajan, como los utilizamos, los disponibles, una breve descripcion de los mas comunes y algunos otros que existen para tareas mas especificas, espero les haya sido util sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.