MariaDB / El motor SPIDER

Bienvenidos sean a este post, hoy hablaremos sobre un motor parecido a los dos ultimos que vimos.

Este motor al igual que vimos en FEDERATEDX y CONNECT nos permite conectarnos remotamente a tablas como si fuera un servidor local, sin embargo este motor fue especificamente diseñado para la fragmentacion de los datos, su principal funcion es poder acceder a datos desde una multitud de servidores simplemente haciendo un query a una tabla local, esta fragmentacion de datos es implementada mediante el particionamiento de tablas, si una tabla SPIDER es particionada cada una de ellas puede ser enlazada a una tabla remota diferente, este motor es adecuado con los metodos de particionamiento RANGE y LIST e inclusive con los RANGE COLUMNS y LIST COLUMNS, este tambien soporta tanto las transaccion SQL comunes como las transacciones XA si las tablas remotas los soportan, si bien fue diseñado originalmente para mysql la version distribuida con mariadb esta ligeramente modificada para tomar ventaja de las caracteristicas especificas de mariadb.

Este motor esencialmente conecta el optimizador del servidor local por un lado con el servidor remoto por el otro, una vez que el optimizador eligio el plan de ejecucion para el query que involucra a las tablas SPIDER, el motor traduce este plan en llamadas a uno o mas servidores haciendo como un cliente de mariadb, cuando se le pregunta para la insercion de datos en mas de un servidor remoto internamente usa una transaccion con una confirmacion de dos fases, no se usa una confirmacion de una fase porque nos garantiza la integridad de los datos en un solo servidor remoto, cuando se solicitan las modificaciones la confirmacion los hace efectivos.

Ahora imaginemos que la modificacion involucra a dos servidores, enviamos los comandos a ambos servidores y no nos devuelve ningun error, luego enviamos una confirmacion al servidor1 y este funciona correctamente para despues enviar la confirmacion al servidor2, si esta confirmacion falla hemos creado una inconsistencia, de hecho los cambios solicitados en el servidor1 ya son efectivos y no se pueden volver para atras, por esta razon una confirmacion de una sola fase no se ajusta a la ejecucion de una transaccion entre multiples servidores.

En cambio la transaccion de confirmacion de dos fases es similar al usado a las transacciones XA, como dijimos antes se pueden enviar comandos XA por el usuario al SPIDER porque es completamente soportado por el motor, inclusive si usara una transaccion normal el motor hara una confirmacion de dos fases para hacer efectivo los cambios en los multiples servidores, gracias a esta tecnica cuando un servidor recibe una confirmacion no aplica los cambios inmediatamente, se le notifica que la transaccion esta finalizada pero espera por una segunda confirmacion, si cualquiera de los otros servidores devuelve un error o no se pudo alcanzar el motor vuelve atras la transaccion en cada servidor involucrado para evitar corrupcion de informacion y solo si la primera confirmacion fue exitosa en todos los servidores se procede a enviar la segunda confirmacion y este hace a los datos efectivos.

Si tenemos un query que involucra a multiples particiones de SPIDER o multiples tablas de SPIDER sin particionar se dividen en multiples threads donde cada thread es usada para cada servidor remoto que necesita ser accedido por el query, esto posibilita al DBA que pueda aumentar la paralelizacion agregando mas particiones que apuntan a un servidor remoto, los resultados de los queries son almacenados en buffers por SPIDER hasta que puedan ser enviados a los clientes, los conjuntos incompletos de resultados pueden ser almacenados tanto en el remoto como con el servidor local.

Para ir finalizando este motor mantiene estadisticas en memoria en tablas e indices remotos, estas estadisticas se actualizan a intervalos regulares de tiempo y como en otros motores almacenamiento, SPIDER envia estos valores al optimizador para que pueda usarlos para elegir el mejor plan para los queries.

En resumen, hoy hemos visto una breve introduccion sobre el motor de almacenamiento SPIDER, sus similitudes con FEDERATEDX y CONNECT, sus ventajas con respectos a estos, que otras caracteristicas poseen y como pueden beneficiarnos, espero les haya sido de utilidad 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.