¿Qué son las bases de datos federadas?
Las bases de datos federadas son una posible solución a los problemas de búsqueda de las bases de datos de sus clientes.
Una base de datos federada es un sistema en el que varias bases de datos parecen funcionar como una sola entidad. Cada componente de la base de datos en el sistema es completamente auto-sostenido y funcional. Cuando una aplicación consulta la base de datos federada, el sistema analiza cuál de los componentes de la base de datos contiene los datos que se solicitan y pasa la solicitud a la misma. Las bases de datos federadas pueden ser consideradas como la virtualización de bases de datos de la misma manera que la virtualización de almacenamiento hace que varias unidades de disco aparezcan como una sola.
Una base de datos federada puede estar compuesta de una colección heterogénea de bases de datos, en cuyo caso permite a las aplicaciones mirar los datos de una manera más unificada sin tener que duplicarla a través de bases de datos o hacer varias consultas y combinar manualmente los resultados. Si sus clientes están buscando este tipo de configuración, la información de IBM Integration puede ser un buen lugar para empezar.
En un entorno homogéneo, las bases de datos federadas pueden ayudar a distribuir la carga de grandes bases de datos (VLDBs). En esta configuración, cada componente de base de datos tiene un esquema idéntico, pero sólo un subconjunto de las filas totales. El sistema de base de datos federada distribuye consultas al componente apropiado de la base de datos; el objetivo del sistema es garantizar que una consulta típica utilizará sólo un componente, lo que reduce drásticamente el número de filas que deben ser buscados. Microsoft SQL Server ha apoyado este tipo de federación de bases de datos desde su edición de 2000.
Cuando se utiliza una base de datos federada para distribución de la carga, las filas se distribuyen a sus componentes con base en una clave primaria. Recoger esta clave no es trivial –puede hacer la diferencia entre una configuración exitosa y otra sin éxito. Idealmente, la mayoría o todas las consultas deberían terminar llegando a una solo componente de base de datos.
Por ejemplo, un banco puede utilizar una base de datos federada en la que las transacciones se dividen por año. Los usuarios a menudo sólo miran las transacciones en el último año y el sistema sólo tendrá que tocar uno o dos componentes de bases de datos. Por otra parte, al dividir las bases de datos por ID de cliente no es probable que funcione bien; un conjunto dado de transacciones implicará una distribución aleatoria de los identificadores de los clientes, lo que significa que la consulta será enviada a muchos, o potencialmente todos, los componentes de bases de datos. Esto elimina el beneficio de la base de datos federada –casi todas las filas terminan en la búsqueda– y esto sólo aumentará la latencia global de la consulta debido al re direccionamiento de las consultas.
Las bases de datos federadas tienen varios inconvenientes, según Hilary Cotter, un consultor de SQL Server y Microsoft MVP. Cada componente de base de datos es un punto potencial de fallo, y la latencia de cualquier servidor retrasará toda la llamada. Sus clientes tendrán que programar ya sea la base de datos federada o sus aplicaciones de llamada para manejar resultados potencialmente incompletos de la consulta, en caso de que uno o más componentes de las bases de datos se agoten. También tienen que gestionar cada componente de base de datos y mantenerlo al día, lo que aumenta los costos de mantenimiento.
En SQL Server 2005, la partición de tablas es a menudo una buena alternativa a la federación de bases de datos. Las particiones son similares a las bases de datos federadas homogéneas en que una gran base de datos se rompe en partes más pequeñas sobre la base de una clave principal, pero la partición de tablas maneja esto buscando varios segmentos de una sola base de datos en lugar de hacerlo en la totalidad de varias bases de datos. Debido a que este servidor necesita manejar toda la base de datos, la actualización se conoce como "escalamiento ascendente", en contraste con el modelo de "escalamiento horizontal" de las bases de datos federadas. El escalamiento ascendente es a menudo un mejor enfoque que el horizontal, pero tiene sus limitaciones –un servidor sólo puede ser reforzado cierta cantidad– y puede requerir que sus clientes inviertan en hardware de gama alta comparativamente caro, en vez de adquirir servidores sin rack (off-the-shelf).
