Una de las nuevas funcionalidades que estarán disponibles en SQL Azure para finales de 2011 es la característica de federación.
Uno de los grandes beneficios de la plataforma Windows Azure es la capacidad que ofrece a la hora de escalar aplicaciones. De manera muy sencilla y dinámica un usuario puede modificar el número de instancias de una aplicación.
Hablando de instancias de Windows Azure este punto es cierto, pero la base de datos podría convertirse en un cuello de botella, ya que ésta no tiene la capacidad de escalado que tienen las instancias de Azure. El usuario no dispone de la posibilidad de realizar un escalado horizontal y aumentar o disminuir las bases de datos SQL Azure en función de las necesidades de la aplicación.
Por ejemplo, este es un escenario típico en aplicaciones multi-tenant, dónde con un mismo despliegue se quiere ofrece el servicio a diferentes clientes.
Al implementar soluciones de este tipo la primera aproximación es usar una única base de datos capaz de contener la información de todos los clientes.
Esta solución es perfectamente viable, pero en algunos escenarios surgen problemas de escalabilidad en caso de que la aplicación crezca en el número de clientes.
Otra de las soluciones aportadas, buscando un alto grado de escalabilidad ha sido utilizar múltiples base de datos, en lugar de una única que contenga todos los datos de la aplicación.
La aplicación es capaz de gestionar múltiples clientes diferentes, cada uno con su información, pero a nivel de base de datos cada uno tiene su base de datos propia.
Este escenario es perfectamente viable, pero implica que si existen 1000 clientes existirán 1000 base de datos, lo que aumente la complejidad de administración de la aplicación y claro está, los costes de despliegue.
SQL Azure Federation viene a cubrir este tipo de escenario, ya que esta característica simplificará enormemente el escalado horizontal, posibilitando que el usuario pueda aumentar o disminuir las bases de datos de la aplicación de forma dinámica y sin que este hecho provoque una parada del servicio.
Es el usuario quién decide los miembros de la federación, es quién decide cuándo añadir o disminuir miembros y es quién decide en base a qué criterio debe realizarse la partición de la información (en la primera versión sólo soportará la partición por rangos, por ejemplo, por cierto valor de un determinado campo).
La sintaxis de la sentencia para crear una federación es la siguiente:
|
CREATE FEDERATION federation_name { <federation_distribution_scheme> } <federation_distribution_scheme> ::= <federation_distribution> <federation_distribution> ::= (distribution_name <data_type> <distribution_type>) <data_type> ::= [ system_type_name . ] type_name |
Dentro de la federación existe un elemento que se conoce como “Federation Root”. Este elemento representa el nombre lógica de la base de datos y es quién conoce todos los miembros de la federación y qué información tiene cada uno de ellos.
Las aplicaciones siempre debe conectarse al “root”, y éste quién dirige las peticiones a la base de datos correspondiente.
