En este artículo presentamos la segunda del parte sobre “Motores de Almacenamiento de DBMS derivados de MySQL” que tiene que ver con los otros motores de almacenamiento de terceros y una guía rápida para elegir la mejor opción.
¿Cómo podemos aprovechar este desarrollo de terceros en nuestro DBMS?
Los motores de almacenamiento nos permiten extender las capacidades de nuestro servidor de bases de datos.
Pueden se motores de propósito general o específicos para nuestras tablas. Por ejemplo, XtraDB de Percona: se puede aplicar a todas nuestras tablas casi en cualquier sistema de base de datos que trabajemos, en áreas tales como: producción, comercio, servicios médicos, ferretería, universidades, transporte, etc. Por otra parte, OQGraph es sólo aconsejable para aquellas tablas recursivas o que representen jerarquías de árbol.
¿Es posible instalar motores de terceros?
La arquitectura de todos los productos derivados de MySQL, ofrece una API para motores de almacenamiento enchufables (Pluggable Storage Engine API).
Esto se refiere a la posibilidad de habilitar los motores de almacenamiento para que sean cargados dentro o descargados desde un servidor basado en MySQL que esté en ejecución.
Lista de Motores de almacenamiento de terceros.
Mencionaremos solamente las más relevantes en la siguiente clasificación:
- Para el procesamiento de transacciones en línea.
- Cuyo almacenamiento es orientado a columnas.
- Otros que pertenecen a la comunidad de software abierto.
Motores de almacenamiento para el procesamiento de transacciones en línea
XtraDB
El motor de almacenamiento XtraDB de Percona, incluido con Percona Server y también con MariaDB, es un fork de InnoDB.
Sus mejoras se enfocan en el desempeño, flexibilidad operativa para trabajar con más procesadores, optimizar el consumo de memoria y manejo de más métricas. También es capaz de leer y escribir en tablas InnoDB para conservar la compatibilidad con éstas.
PBXT
Incluido en MariaDB, también soporta transacciones y concurrencia MVCC. Lo distingue su soporte para replicación a nivel de motores, manejo de restricciones de clave foránea y una compleja arquitectura que lo posiciona para almacenamiento y manejo eficiente de tipos de datos grandes tales como BLOBs.
TokuDB
Fue diseñado inicialmente como un motor de almacenamiento para bases de datos muy grandes, ya que manejan una tasa de compresión alta y pueden soportar muchos índices sobre grandes volúmenes de datos.
TokuDB usa una estructura de índices denominada árbol fractal, estos no se ralentizan en la medida que los índices se vuelven más grandes que el espacio de memoria que ocupan, ni tampoco envejecen o fragmentan.
“Los índices de árbol fractal superan en rendimiento a los de cluster de MySQL, en caso de bases de datos muy grandes superiores a 10 terabytes”
Motores de almacenamiento orientados a columnas
Para bases de datos grandes cabe un enfoque distinto de particionamiento para almacenar las tablas, aquel orientado por columnas que puede ser más apropiado.
Se puede comprimir más la información de una columna, ya que sus valores generalmente se repiten. También por rendimiento y seguridad es más acertado hacer consultas que incluyan solamente los campos necesarios.
Infobright
El motor de almacenamiento orientado a columnas que está en la delantera es Infobright, que trabaja bien en bases de datos grandes de decenas de Terabytes. Está diseñado para aplicaciones de minería y análisis de datos.
Funciona almacenando los datos en bloques, los cuales están comprimidos altamente. Mantiene un conjunto de metadatos por cada bloque, lo cuál le permite avanzar a otros bloques o completar consultas simplemente al comparar con estos metadatos. Esta es la estrategia por la cual no emplea índices.
El uso de índices en bases de datos de almacenes de datos, de minería, o análisis de datos no es tan requerido, porque los datos se guardan directamente de una forma ya ordenada para favorecer los requerimientos de la aplicación.
Por ejemplo, los registros que aparecen en algún informe de ventas pueden ser almacenados en el almacén de datos tal como se muestran en el informe, permitiendo la redundancia necesaria y en una sola tabla. Es decir, se desnormalizan un poco para obtener un mejor desempeño de las aplicaciones.
Por lo antes expuesto, la estructura de bloques de Infobright es prácticamente equivalente a un índice.
Algunas consultas no puedan ser ejecutadas en modo columna, causando que el servidor emule el modo orientado a filas, lo cual lo hace más lento.
Infobright está solamente disponible como software comercial.
ColumnStore
Otro motor orientado a columnas es ColumnStore, está disponible en MariaDB. Ofrece la capacidad de distribuir las consultas a través de grupos de máquinas. ColumnStore es un fork de InfiniDB que cesó sus operaciones en el año 2014.
Otros motores de almacenamiento que también pertenecen a la comunidad de software abierto
La gran mayoría está limitada a mercados de ámbito restringido y suelen requerir de cierta especialización, esto causa que sean desconocidos y usados por muy pocas personas. Revisaremos aquí algunos de los más usados.
Aria
Es el sucesor para MyISAM y está disponible en MariaDB. Supera la rapidez de MyISAM en cláusulas como GROUP BY y DISTINCT. Quizá se describe mejor como una versión de MyISAM que no se corrompe tan fácilmente, con otras mejoras.
Groonga
Es un motor para búsquedas de texto completo (full-text search), orientado a columnas. Con características que ofrecen más seguridad y alta velocidad en ciertos escenarios de minería y análisis de datos. Está basado en índices invertidos que permite hacer búsquedas de documentos mientras se está actualizando la colección de documentos. Se encuentra disponible como motor independiente en MariaDB con el nombre de Moongra.
OQGraph
El motor Open Query Graph permite manejar jerarquías, pero también estructuras de grafos más complejas.
Un ejemplo muy común de estas jerarquías son las tablas maestras que guardan clasificaciones de algo, tales como cuentas contables, clases de artículos, clases de servicios, etc. Una fila dentro de esta tabla se caracteriza por tener dos apuntadores: uno al nodo padre y otro al nodo hijo. Como un padre puede tener varios hijos, estos son representados por varias filas con el mismo padre.
Las búsquedas son complejas ya que pueden aparecer más niveles en la jerarquía, ni hablar de lo que pasa con las eliminaciones y actualizaciones.
Es obvio que las bases de datos relacionales no son apropiadas para el manejo del tipo de problemas del modelo adyacente, los cuales no encajan bien con estructuras normalizadas.
SphinxSE
Este es un motor caracterizado como de búsqueda de texto completo pero en realidad es mucho más que eso. Fue diseñado para integrarse bien con manejadores de bases de datos.
Soporta búsquedas distribuidas, ofrece un manejo eficiente de memoria y de operaciones de entrada/salida de disco. Acelera una variedad de consultas, operaciones de agrupamiento y ordenamiento. Es verdaderamente útil en arquitecturas de propósito general que no son optimizadas para grandes bases de datos, extendiendo su funcionalidad y desempeño.
Spider
Este motor distribuye los datos en varias particiones horizontales denominadas “shards”. Es capaz de ejecutar consultas distribuidas a traves de varios nodos, los cuales pueden estar localizados en distintos servidores y también soporta transacciones distribuidas.
VPForMySQL
Este motor es también similar al anterior porque distribuye los datos pero usando particionamiento vertical u orientado a columnas.
¿Que motor de almacenamiento deberías usar?
La decisión de cual motor deberías usar podría ser resumida diciendo, “Usa InnoDB a menos que necesites una característica que éste no proporcione, y para el cual tampoco haya un buen enfoque alternativo si aún así decidieramos usarlo”.
“Es mejor no mezclar distintos motores a menos que sea absolutamente necesario.”
Las interacciones entre el DBMS y el motor de almacenamiento pueden llegar a ser suficientemente complejas sin necesidad de añadir múltiples motores a la mezcla. Por ejemplo, el empleo de varios motores vuelve difícil la ejecución de respaldos consistentes.
Factores a considerar cuando eliges un motor
Transacciones
Si tu aplicación requiere transacciones InnoDB es el más estable y ya está integrado.
Respaldos
Si puedes detener los servicios del servidor de modo tal que puedas hacer los respaldos, entonces no hay ningún problema con esto para ningún motor.
Generalmente, sucede que debemos tener nuestro servidor dedicado las 24 horas, entonces la mejor alternativa aquí son los respaldos en línea de InnoDB.
Recuperación
Si tienes muchos datos, entonces deberías considerar seriamente el tiempo que necesitarás invertir para que de los datos sean consistentes ante cualquier desastre. MyISAM presenta limitaciones y esta es la razón primordial por la cuál la gente prefiere InnoDB por sobre MyISAM, aún cuando no necesiten transacciones.
Algunas características especiales
Si un motor reúne uno o varios requisitos que sean críticos, pero otros no, probablemente necesitarás comprometer un poco tu diseño de base de datos para alcanzar el beneficio que brinda. También, podrías obtener lo que necesitas de un motor que aparentemente no soporta tus requerimientos.
Casos prácticos en contextos reales
Vamos a considerar una variedad de tablas en un contexto real de base de datos y determinar cual motor se ajusta mejor a tus necesidades.
Loggin
Imagina que estás trabajando con una aplicación para registrar las visitas de un sitio web en tiempo real, y que el volúmen de estás es muy grande. En tales aplicaciones la rápidez es el principal objetivo. Los motores MyISAM y Archive trabajarían muy bien porque tienen baja carga de cpu y pueden insertar miles de registros por segundo.
Catálogo
Las tablas que son usadas para construir grandes catálogos, reciben mucho más operaciones de lectura que de escritura. Pareciera que la respuesta obvia debería ser MyISAM nuevamente, pero por la necesidad de recuperación de desastres la respuesta es InnoDB.
Procesamiento de Pedidos
Las transacciones son de uso vital, y son todo lo que requieres. Otra importante consideración es si el motor necesita soportar restricciones de claves foráneas. InnoDB se ajusta mejor con esta clase de aplicaciones.
Boletínes de noticias y foros
La mayoría de sistemas de discusiones conectados por hilos, son escritos con la eficiencia de la base de datos en mente, tienden a ejecutar muchas consultas para cada solicitud que reciben.
Algunos usan una solución distinta al manejo de base de datos, otros guardan información en una sola tabla que se convierten luego en enormes cuellos de botella cuando crecen significativamente.
La solución obvia para estas tablas es cambiar de motor que manejen un alto volumen de lectura/escritura. Lo interesante es saber porqué cuando hacen esto obtienen peores resultados que antes.
Lo que no se imaginan es que cuando los usuarios calculan sus estadísticas, hacen uso de intrucciones como la siguiente:
MySQL > select count(*) from tabla;
El problema es que no todos los motores pueden ejecutar esto eficientemente. MyISAM puede pero otros motores no.
Grandes volúmenes de datos
El problema es: ¿Cómo consideramos que una base de datos es verdaderamente grande?
Probablemente ya has trabajado con bases de datos InnoDB en un rango de tres a cinco terabytes que residan en uno solo o se distribuyan en varios servidores.
Es perfectamente posible que aunque hayas elegido correctamente tu hardware, tu diseño físico y considerado el rendimiento de entradas/salidas, en estos tamaños es cuando MyISAM se convierte en una pesadilla cuando se presentan caídas del sistema.
Si estas trabajando con este tipo de base de datos, probablemente estás construyendo un almacén de base de datos (datawarehouse). En este caso, Infobright es el que tiene el mayor éxito para tus tablas.
Ya que Infobright es software privativo, ColumnStore es la alternativa de código abierto en MariaDB.
En el hipotético caso que tu base de datos verdaderamente grande no corresponde a un almacén de datos, entonces la alternativa para tus tablas grandes es TokuDB.
Espero que te haya gustado este artículo, te recomiendo unirte a nuestro listado de emails y seguirnos en Twitter para mantenerte al día:
Regístrate hoy en Styde y obtén acceso a todo nuestro contenido.
