7 funciones de MySQL y MariaDB que no querrá perderse

0
268

En los últimos años, los sistemas de gestión de bases de datos relacionales de código abierto, MySQL y MariaDB, han sufrido cambios tremendos: funciones nuevas y mejoradas, correcciones para problemas persistentes, así como un mejor desempeño en todos los ámbitos.

Con todo lo que ha cambiado, es fácil perderse algunas de las mejores funciones que MySQL y MariaDB han agregado en ese momento. En este artículo, veremos siete de las mayores capacidades nuevas que se han agregado a MySQL, MariaDB o ambas -y por qué querría usarlas.

Soporte de JSON
Cuando aparecieron las bases de datos NoSQL, con sus promesas de facilidad para el desarrollador y escalabilidad elástica, muchos se preguntaban si las bases de datos relacionales estaban desapareciendo. Respuesta corta: para nada. Los sistemas NoSQL son prácticos y flexibles, pero los esquemas y las tablas siempre tendrán su lugar.

Además, muchas bases de datos relacionales de la vieja escuela, MySQL y MariaDB entre ellas, tomaron una página del libro de NoSQL y agregaron soporte de JSON como una función estándar. El efecto neto es contar con NoSQL cuando lo necesite, junto con SQL convencional en la misma base de datos.

El soporte de JSON en MySQL y MariaDB le permite insertar documentos JSON en una columna de tabla especialmente designada. Los datos JSON insertados se pueden validar automáticamente utilizando el mismo tipo de restricciones que se utilizan para otras columnas de datos. Puede recuperar los datos como documentos JSON o como escalas simples, y puede usar columnas generadas o virtuales para producir un efecto similar en los índices JSON.

Vale la pena tener en cuenta dos puntos importantes aquí. Primero, aunque los conjuntos de funciones de procesamiento JSON en MySQL y MariaDB son similares, no son reemplazos directos entre sí. En segundo lugar, también difieren las implementaciones de MySQL y MariaDB del tipo de datos de la columna JSON nativa. Esto genera pequeñas incompatibilidades que necesitará monitorear si está migrando o sincronizando datos entre las dos bases de datos.

Grupos de recursos (únicamente en MySQL)
Todos los trabajos de la base de datos son importantes, pero algunos son más urgentes que otros. Por ejemplo, es posible que desee ejecutar trabajos como archivar o trabajos por lotes programados en segundo plano, y simultáneamente asegurarse de que el trabajo crítico para la empresa se ejecute de la manera más rápida posible. Los grupos de recursos de MySQL que esto sea posible.

Con los grupos de recursos, puede designar un tipo («sistema” o «usuario”), una afinidad con las CPU y una prioridad de subproceso para todos los trabajos de base de datos asignados al grupo. Puede seleccionar un grupo de recursos para una sesión, o seleccionar uno para una sola declaración usando una sugerencia del optimizador.

Tenga en cuenta que los grupos de recursos se implementan de manera diferente en las plataformas MySQL, y que no puede usar grupos de recursos junto con el plug-in de grupo de subprocesos empresariales. Además, si bien existe una solicitud de función para implementar una función similar en MariaDB, aún no hay planes para implementarla.

Motor de almacenamiento OQGRAPH (únicamente en MariaDB)
Las bases de datos gráficas le permiten almacenar y explorar las relaciones entre los datos de manera mucho más eficiente que con una base de datos relacional. Mientras que las bases de datos gráficas dedicadas, como Neo4j o Amazon Neptune, se enfocan exclusivamente en el almacenamiento y procesamiento de gráficos, MariaDB le permite realizar un procesamiento de gráficos al lado de consultas de SQL convencionales mediante el motor de almacenamiento OQGRAPH.

La mayoría de las bases de datos gráficas utilizan su propio lenguaje de consulta personalizado. Con OQGRAPH, carga datos y construye consultas gráficas utilizando una SQL convencional. Los resultados se devuelven en el formato de consulta convencional de MariaDB, por lo que se pueden unir o combinar con los resultados de las consultas de tablas de SQL convencionales.

Funciones de compatibilidad de Oracle (únicamente con MariaDB)
Los productos de la base de datos de Oracle siguen siendo los más utilizados en todas las áreas de TI, pero sus costos de licencia y restricciones contractuales hacen que muchos usuarios vean una estrategia de salida. Además, muchas aplicaciones basadas en Oracle hacen un uso intensivo de funciones exclusivas de Oracle PL/SQL y su sintaxis.

En las últimas versiones, MariaDB ha lanzado una serie de nuevas funciones diseñadas para emular el comportamiento de las bases de datos Oracle, especialmente el lenguaje PL/SQL de Oracle. Esto teóricamente permite que, en MariaDB, gran parte del código PL/SQL existente se ejecute como está, o con solo algunas modificaciones menores. El equipo de MariaDB estima que se puede ejecutar aproximadamente el 80% del Oracle PL/SQL previo tal como es, utilizando las funciones de compatibilidad.

Tenga en cuenta que el comando de MariaDB para usar el modo Oracle PL/SQL entra en vigor a nivel de cada cliente. No necesita cambiar los comportamientos de MariaDB globalmente para usar esta función.

Tablas versionadas del sistema (MariaDB)
La versión del 2011 del estándar SQL agregó tablas versionadas, la capacidad de una base de datos para rastrear versiones de filas de tablas. MariaDB agregó tablas versionadas del sistema como una función nativa en la versión 10.3.4.

Con las tablas versionadas del sistema de MariaDB, puede ejecutar una consulta usando un rango temporal dado, y los resultados producidos aparecerán como eran durante ese período de tiempo. También puede modificar o eliminar filas que se encuentran dentro de un rango de fechas, agregar o eliminar períodos de tiempo para rastrear, y usar períodos de tiempo especificados a nivel de las aplicaciones, a nivel del sistema o ambos. En teoría, podría hacer esto con cualquier base de datos que admita valores de tiempo, pero es difícil hacerlo usted mismo; MariaDB lo hace por debajo.

Aunque MariaDB admite las tablas con versión del sistema para cualquier motor de base de datos, algunas de las funciones como el historial de transacciones precisas, por ejemplo, que muestra los registros en medio de una transacción determinada, solo están disponibles con el motor InnoDB.

Motor de almacenamiento ColumnStore/InfiniDB (MariaDB)
La tecnología del motor de almacenamiento conectable en MariaDB y MySQL permite que ambas bases de datos amplíen en gran medida su funcionalidad nativa. Uno de estos motores de almacenamiento, ColumnStore, convierte a MariaDB en una base de datos de almacenamiento en columnas. (ColumnStore no está disponible para MySQL, pero el proyecto del cual ColumnStore se derivó, InfiniDB, usa MySQL para ejecutar consultas).

El almacenamiento de columnas es ideal para consultas de alta velocidad de grandes volúmenes de datos. Los sistemas OLAP usan almacenamiento de columnas, por lo que ColumnStore funciona como una forma de proporcionar una funcionalidad estilo OLAP dentro de MariaDB, sin depender de un producto externo (y, generalmente, comercial) como Teradata o Greenplum. ColumnStore no proporciona la gama completa de funciones de analítica de datos o de cálculo de datos que vienen con esos productos, pero puede proporcionar la capa de datos para una solución de análisis interna.

Motor de almacenamiento Spider
Cuanto más poderosa es la función, más difícil es implementarla en producción. Una de estas funciones es la fragmentación de la base de datos, o la división de una base de datos en varios servidores para mejorar el rendimiento, lo cual generalmente requiere muchos retoques y modificaciones.

MariaDB 10.3.4 (y versiones posteriores) suaviza el camino con Spider, un motor de almacenamiento con funciones integradas de fragmentación y partición de datos. Spider admite varios modos diferentes: federación simple, alta disponibilidad, fragmentación y fragmentación con alta disponibilidad añadida.

Spider tiene algunas funciones que se superponen con MaxScale, el sistema de MariaDB para balanceo de carga, proxyingfail-over y alta disponibilidad. MaxScale cubre un conjunto más amplio y ambicioso de casos de uso que Spider, pero Spider es útil si quiere aprovechar las ventajas de fragmentación en implementaciones más modestas.

Spider fue desarrollado originalmente como un complemento de MySQL, y aún está disponible en esa forma para usuarios de MySQL. La gran mayoría de las funciones en ambas versiones son las mismas, con algunas excepciones.

Serdar Yegulalp, InfoWorld.com – Traducción CiOperu.pe