FederatedX

FederatedX
Información general
Tipo de programa	Bases de datos
Desarrollador	Monty Program
Licencia	GPL v3
Idiomas	Inglés
Información técnica
Programado en	C, C++
Plataformas admitidas	Multiplataforma
Enlaces
Sitio web oficial

Es un Mecanismo de almacenamiento para MySQL/MariaDB. FederatedX proviene de una ramificación del Federated, el cual ha dejado de ser mantenido por Oracle. El propósito​ de FederatedX es continuar el desarrollo de nuevas características y corregir antiguos errores.

Descripción

El mecanismo de almacenamiento FederatedX Storage funciona tanto con MariaDB como con MySQL. Mientras que otros mecanismos están implementados al nivel de fichero, FederatedX usa libmysql para hablar con el almacén de datos, siendo esta fuente de datos un SGBDR remoto. De hecho, dado que FederatedX usa solo libmysql, solo puede comunicarse con otra MySQL. Está planeado desde luego que pueda ser capaz de comunicarse con otro SGBDR como fuente de datos. Existe el proyecto Federated ODBC que permite comunicarse con PostgreSQL como fuente de datos remota, functionalidad que será soportada por FederatedX en próximas versiones.

Historia

FederatedX continúa la historia de Federated. Cisco necesitaba un mecanismo de almacenamiento MySQL que les permitiera consolidar tablas remotas en un tipo de router, y ser capaces de interactuar con dichas tablas remotas como si fueran locales al dispositivo per localizadas en otro sitio, ya que el router no disponía de tanta capacidad. El primer prototipo del mecanismo Federated se desarrolló en base al interfaz HANDLER. El código y los requisitos de funcionamiento llegaron a Patrick Galbraith, que junto con Brian Aker y la supervisión de Monty consiguieron un mecanismo Federated con MySQL 5.0.

Cuando MySQL 5.1. pasó a producción, a Federated se le habían añadido nuevas características y mejoras, como:

• Nuevo SERVER Federated añadido a parser. Esto lo necesitaba Cisco para cambiar los parámetros de conexión de numerosas tablas de golpe sin necesidad de alterar o recrear las tablas Federated.
• Soporte transaccional básico, para soportar tablas remotas transaccinales
• Algunos errores a corregir desde MySQL 5.0.
• Funcionamiento como plugin

Funcionamiento

Todo mecanismo de almacenamiento ha de implementar métodos derivados de la clase del API del manejador estándar. La gran diferencia con FederatedX es que necesita implementar dichos métodos de modo que construyan sentencias SQL que se ejecuten en el servidor remoto y, si hay resultado que devolver, procesar ese resultado con el formato del manejador interno para devolverlo.

Detalles internos

Lo ficheros clásicos de una base de datos MySQL residen en el almacenamiento local: al crear una tabla llamada 'usuarios' se crea un fichero llamado 'usuarios.MYD'. Un manejador de ficheros lee, inserta, borra y actualiza los datos de este fichero. Los datos se guardan en un formato específico, por lo que al leer dichos datos deben formatearse en campos, y al escribir la información ha de grabarse en ese formato.

Con el mecanismo de almacenamiento FederatedX no habrá ficheros locales con los datos de la tabla (esos .MYD). Una base de datos externa almacenará los datos que estarían normalmente en esos ficheros. Para esto se necesita el uso de API del cliente MySQL para leer, borrar, actualizar e insertar los datos. Como ueremos recuperar los datos con una sentencia como "SELECT * FROM usuarios", debe recuperarse con la función MySQL mysql_fetch_row de fila en fila, para posteriormente convertirla al formato que el manejador espera.

La funcionalidad básica de FederatedX es:

• El usuario ejecuta sentencias SQL contra la tabla local de federatedX. Esta sentencia se procesa en un árbol de elementos.
• FederatedX usa el API del manejador MySQL para implementar los métodos requeridos para el mecanismo de almacenamiento. Tiene acceso al árbol de elementos así como a los campos de la tabla.
• Con esta información, FederatedX construye una sentencia SQL.
• La sentencia así construida se envía al almacén de datos externo usando el API del cliente libmysql.
• La base de datos externa lee la sentencia SQL y envía de vuelta el resultado vía el API del cliente mysql.
• Si la sentencia original SQL devuelve un resultado del almacén de datos externo, el mecanismo FederatedX itera sobre el resultado y convierte cada fila al formato del manejador interno.
• Si la sentencia original SQL solo devuelve en número de filas afectadas (affected_rows), ese número se añade a las estadísticas de la tabla, lo que resulta en que el peticionario obtiene el número de fials afectadas.

Llamada a procedimientos

Se puede ver cómo funciona el mecanismo FederatedX compilando una versión debug de MariaDB y activando la traza de errores. Usando una tabla de dos columnas, con una fila, se pueden observar los métodos invocados.

"SELECT * FROM foo", mostrará:

ha_federatedx::info
ha_federatedx::scan_time:
ha_federatedx::rnd_init: share->select_query SELECT * FROM foo
ha_federatedx::extra

y para cada fila de datos recuperada de la base de datos remota:

ha_federatedx::rnd_next
ha_federatedx::convert_row_to_internal_format
ha_federatedx::rnd_next

una vez que todas las filas han sido recuperadas se verá:

ha_federatedx::rnd_end
ha_federatedx::extra
ha_federatedx::reset

Uso de FederatedX

El uso resulta muy sencillo. Debemos contar con dos bases de datos, en el mismo servidor o en diferentes.

En el servidor que se conectará al remoto (el cliente) creamos la tabla como tal:

CREATE TABLE tabla_test (
 id     int(20) NOT NULL auto_increment,
 nombre varchar(32) NOT NULL default ,
 otro   int(20) NOT NULL default '0',
 PRIMARY KEY  (id),
 KEY nombre (nombre),
 KEY otra_clave (otro))
ENGINE="FEDERATED"
DEFAULT CHARSET=latin1
CONNECTION='mysql://usuario:clave@192.168.0.11:9306/base_de_datos/tabla_test';

El campo "ENGINE" ha de contener "FEDERATED" y el campo "CONNECTION" -específico de este mecanismo- ha de contener la información del servidor externo, que hará las veces de fuente de datos a la que el 'cliente' se conectará y de la que extraerá los datos. En esta configuración la base de datos externa está escuchando en el puerto 9306, por lo que la base de datos federatedx tendrá que escuchar en otro.

Luego, en la base de datos externa (llamada "base_de_datos"):

CREATE TABLE tabla_test (
 id     int(20) NOT NULL auto_increment,
 nombre   varchar(32) NOT NULL default ,
 otro   int(20) NOT NULL default '0',
 PRIMARY KEY  (id),
 KEY nombre (nombre),
 KEY otra_clave (otro))
ENGINE="<NAME>" <-- cualquiera, o sin especificar
DEFAULT CHARSET=latin1 ;

Esta tabla es exactametne la misma (y debe serlo), excepto que no usa el manejador federatedx y no necesita la URL.

Capacidades y límites

• Las tablas deben ser creadas primero en el servidor remoto para que sea posible actuar sobre ellas mediante el manejador.
• Hay que asegurarse de que si la tabla remota a la que conectamos es de tipo FederatedX, no apunte de nuevo a la original; se producirían "oscilaciones".
• No hay modo de que el manejador sepa si la tabla remota ha cambiado. El mecanismo supone que no se ha de acceder a la tabla salvo con FederatedX. La integridad de la tabla local se perderá si se cambia algo de la base de datos remota.
• Soporta SELECT, INSERT, UPDATE , DELETE e índices.
• No se pueden ejecutar comandos DDL como ALTER TABLE o DROP TABLE.

Diferencias con el antiguo Federated

Desde el punto de vista del usuario FederatedX no cambia. Lo que le diferencia con Federated se resume a continuación:

• Se ha reescrito el código de Federated pasando de un único fichero ha_federated.cc a tres componentes principales:
  • ha_federatedx.cc - Núcleo de FederatedX
  • federated_io.cc - Clase padre con las conexiones para ser reemplazadas por clases derivadas para cada librería SGBDR/cliente
  • federatated_io_<driver>.cc - Clase federated_io derivada para un SGBDR dado
  • federated_txn.cc - Soporte para el uso de mecanismos transaccionales en el servidor remoto
• Corrección de varios errores (se buscaron antiguos errores en Federated)

Referencias

• Datos: Q5857465