Bases de Datos Distribuidas

Marta Zorrilla - UC 1

Arquitecturas de los Sistemas de Bases de

Datos

Marta Zorrilla

-Universidad de Cantabria-


Paradigmas Arquitecturales en

BD

� Arquitectura Centralizada: los datos y las aplicaciones están en una única máquina.

� Arquitectura Cliente-Servidor: separación del servidor de BD de la aplicación cliente (interfaz y procesamiento). c/s de 2 y 3 niveles.

� BD Distribuidas: varios servidores de BD usados por la misma aplicación.

� BD Paralelas: varias unidades de almacenamiento de datos y procesadores operan en paralelo para incrementar el rendimiento.

� Almacenes de Datos: servidores especializados en la gestión de datos orientados al soporte a la decisión.


Bases de datos distribuidas

Marta Zorrilla

-Universidad de Cantabria-


Tabla de contenidos

� Introducción a los SGBDD• Definición• Ventajas e inconvenientes. Aplicaciones• Funciones adicionales de los SGBDD• Clasificación de SGBDD• 12 reglas de Date

� Diseño de BD distribuidas• Fragmentación• Replicación

� Catálogo global� Procesador de consultas global � Gestor de transacciones global

• Técnicas de control de concurrencia• Recuperación

� Gestores comerciales


Lecturas recomendadas

� Básica• M. Tamer Özsu and Patrick Valduriez. Principles of Distributed

Database Systems, 2ª Edition.1999. Prentice Hall • Cap. 25 Elmasri y Navathe (2007): Fundamentos de Sistemas de

Bases de Datos.• Cap. 22. Silberschatz, A, H. F. Korth. Fundamentos de bases de datos.

5ª ed.

� Complementaria• Cap. 22. Connolly y Begg (2005): Sistemas de Bases de Datos. • Mario Piattini, Oscar Díaz. Advanced database technology and design.

Artech House, cop. 2000.• M. E. Zorrilla, E. Mora, P. Corcuera, J. Fernández. Vertical Partitioning

Algorithms in Distributed Databases. Lecture Notes in Computer Science1798. Springer-Verlag. 2000


Introducción

� En la actualidad:• la mayoría de los sistemas de información se

encuentran en sistemas centralizados• las redes de comunicación son rápidas y con gran

capacidad• entorno globalizado, empresas distribuidas

geográficamente

• abren una nueva alternativa que permiten tener los datos allí donde se gestionan

• plantean dificultades en la gestión de transacciones y procesamiento de consultas


Definición

� Un sistema de base de datos distribuido consiste en un conjunto de bases de datos lógicamente relacionadas y distribuidas sobre una red de ordenadores.

� Un SGBD-D es el software que gestiona BDD y suministra mecanismos de acceso que hace la distribución transparente al usuario


Ventajas

� Integración NO centralización:• Los datos se almacenan donde se gestionan • Compartición de los datos pero con control local• Se refleja la organización de la empresa

� Mejora en la fiabilidad y disponibilidad.• Más vulnerables a los fallos, pero se evita fallo total aunque

baja el rendimiento � Rendimiento:

• Si una consulta comprende datos de varias sedes, puede ser posible dividir la consulta en varias subconsultas que se ejecuten en paralelo en distintas sedes.

� Facilidad de expansión.


Inconvenientes

� Solución más compleja:• Diseño del modelo de datos

• Coordinación entre sedes

• Políticas de seguridad

• Dependencia de más elementos

� Aumento de costes• Mantenimiento, red, licencias, etc.

� Falta de estándares

� Las empresas ya tienen sus BD centralizadas


Aplicaciones

� Aerolíneas

� Gestión de viajes

� Gestión financiera (sistemas interbanca)

� Manufactura

� Cadenas hoteleras

� Etc.


Funciones adicionales de los

SGBD-D

� Un SGBD Distribuidas (SGBDD) amplia la funcionalidad de un SGBD normal con:• Servicios de Comunicación Extendidos.

• Transmitir datos y consultas entre nodos.• Diccionario de Datos Extendido.

• Información del esquema relacional más información de control para ofrecer la independencia respecto a la localización, la fragmentación y la réplica.

• Procesamiento de Consultas Distribuido. • Decidir la estrategia de ejecutar cada “query” sobre la red de la forma más

eficiente.

• Control de Concurrencia y de Transacciones Extendido.• Acceso a datos de diferentes nodos y mantener la integridad.

• Servicios de Recuperación Extendidos.• Recuperarse ante caídas de un nodo local, fallo en la red, etc.

• Servicios de Seguridad Extendidos.• Seguridad de acceso a los datos según privilegios


Clasificación de SGBDD

BD distribuidasBD distribuidas

No federadas

(homogéneos)

No federadas

(homogéneos)

Federadas

(heterogéneos)

Federadas

(heterogéneos)

Fuertemente acoplados

Fuertemente acoplados

Ligeramente acoplados

Ligeramente acoplados

Esquema simple

Esquema simple

Esquema múltiple

Esquema múltiple


Clasificación de SGBDD (y 2)

� En la coordinación participan varios gestores iguales (homogéneos) o diferentes (herogéneos o federados).

� En los homogéneos un solo gestor puede ser el administrador de la coordinación (donde se guarda la información, cómo y quién puede acceder a ella...)

� En los heterogéneos, la administración se comparte entre los diferentes DBA locales, indicando cada uno de ellos quéinformación es accesible globalmente y cómo. Si existe un esquema global se dice que está fuertemente acoplados sino débilmente, por lo que cada sede es responsable de mostrar los esquemas externos de su información.


Modelo para SGBD federados

arquitectura ANSI/SPARC

Externalschema

Componentschema

Componentschema

Componentschema

Externalschema

Externalschema

Exportschema

Exportschema

Exportschema

Exportschema

Local schema

Local schema

Local schema

....

Global schema

Global schema

....

....

....

No en DBMS homogéneos

Sólo uno en single-DBMS


Arquitectura ANSI/SPARC

� Local Schema: Esquema conceptual local, continua operando de forma autónoma y está bajo el control de su admón. de BD local. Este podrátener sus vistas externas pero no se consideran para la federación

� Component schema. Cada esquema local tiene su correspondiente componente, es decir, su traducción a un modelo de datos común ya que los modelos involucrados puede ser de distinto tipo (relacional, OO, etc...)

� Export schemas: son los esquemas que los admón. locales ponen disponibles a la federación, es decir, lo que se comparte. Define la información que puede ser accedida por consultas y transacciones globales

� Global Schema: uno o varios recogen el modelo del conjunto. A veces se requieren varios porque no es fácil recoger toda la heterogeneidad semántica de los esquemas.

� External schemas: vista sobre esquema global que contiene la información que un usuario necesita para una aplicación específica


Bases de Datos Distribuidas

Reglas de Date

� Principio fundamental:• Para el usuario un sistema distribuido (SD) debe funcionar igual

que si no fuera distribuido.1. Autonomía local: los sitios de un SD deben ser autónomos en el

mayor grado posible.2. No dependencia de un sitio central: Todos los sitios deben ser

tratados como iguales.3. Operación continua: El SD debe aumentar la confiabilidad y la

fiabilidad. No deberían requerirse paradas planificadas.4. Independencia de localización: para el usuario la localización física

de los datos debe ser transparente.5. Independencia de fragmentación: los usuarios no necesitan

conocer los fragmentos físicos en que está dividida cada colección lógica de datos.

6. Independencia de replicación: a nivel lógico los usuarios no necesitan tener en cuenta si los datos tienen réplicas o no.


Bases de Datos Distribuidas

Reglas de Date

7. Procesamiento de consultas distribuidas: el SD debe disponer de mecanismos para optimizar las consultas y en el especial para reducir la carga de tráfico necesaria.

8. Gestión de transacciones distribuidas: el SD debe disponer de mecanismos (protocolos) adecuados para el control de concurrencia y la recuperación de transacciones distribuidas.

9. Independencia del hardware: poder ejecutar el mismo SGBD en sitios con diferentes plataformas hardware.

10. Independencia del sistema operativo: poder ejecutar el mismo SGBD en sitios con diferentes sistemas operativos.

11. Independencia de la red: el SD debe poder operar con diferentes redes de comunicaciones.

12. Independencia del SGBD: Debe permitirse la heterogeneidad, es decir, que cada sitio puede funcionar con un SGBD diferente, incluso basado en un modelo de datos diferente, siempre y cuando compartan un interfaz común.


Diseño de BD distribuidas

� Hay que decidir en qué nodos deben residir los datos y las aplicaciones que trabajan con los datos• Si existen ya las bases de

datos, hay que integrarlaspara obtener el esquema global

• Si no existen, hay que definir el esquema conceptual global y fragmentar y asignar a los nodos

Análisis de requisitos

Requisitos del Sistema

Diseñoconceptual

Diseñovistas

EsquemaConceptual global

Información de acceso

Definición esquemas externos

Diseño de la distribución

Esquemas conceptuales locales

Diseño físico

Esquema físico

Intervención del usuario

Integración de vistas

Intervención del usuario

Monitorización y ajustes


Diseño de BD distribuidas

� Fragmentación • Vertical, Horizontal, Mixta

• Ventaja: mayor nivel de concurrencia• Inconv.:menos eficiencia en gestión de

transacciones al trabajar con varios frag.

� Replicación Total, Parcial• Ventaja: disponibilidad, rapidez en consultas• Inconv.: tiempo extra en actualizaciones


Ejemplo (frag. Horizontal)

TABLA EMPLEADO

EMP_ID NOMBRE DEPT SALARIO

E1 SANDRA D1 5000000

E2 ALFREDO D1 4000000

E3 GUILLERMO D2 8000000

E4 JUAN D3 9000000

FRAGMENTO 1 DE LA TABLA EMPLEADO


E1 SANDRA D1 5000000

E2 ALFREDO D1 4000000



E3 GUILLERMO D2 8000000



E4 JUAN D3 9000000

FRAG_1 = σ DEPT=D1 ( EMP_TABLE)FRAG_2 = σ DEPT=D2 ( EMP_TABLE)FRAG_3 = σ DEPT=D3 ( EMP_TABLE)


Ejemplo (frag. vertical)

TABLA EMPLEADO EMP_ID NOMBRE DEPT SALARIO EXP

E1 SANDRA D1 5000000 PROGRAMADOR

E2 ALFREDO D1 4000000 ANALISTA

E3 GUILLERMO D2 8000000 DISEÑADOR

E4 JUAN D3 9000000 PEON

FRAGMENTO 1 DE LA TABLA EMPLEADO EMP_ID NOMBRE DEPT EXP

E1 SANDRA D1 PROGRAMADOR

E2 ALFREDO D1 ANALISTA

E3 GUILLERMO D2 DISEÑADOR

E4 JUAN D3 PEON

FRAGMENTO 2 DE LA TABLA EMPLEADO EMP_ID EXP

E1 PROGRAMADOR

E2 ANALISTA

E3 DISEÑADOR

E4 PEON

FRAG_1 = π EMP_ID, DEPT, NOMBRE, EXP ( EMP_TABLE)

FRAG_2 = π EMP_ID, SALARIO ( EMP_TABLE)


Fragmentación ¿por qué?

� Ventajas:• Utilización. Generalmente las aplicaciones trabajan con vistas

en vez de con relaciones completas• Eficiencia. Los datos se almacenan dónde más se utilizan.• Paralelismo. Las transacciones pueden dividirse en

subconsultas que operan con fragmentos.• Seguridad. Los datos no necesarios localmente no se

almacenan y se evita su uso por los usuarios no autorizados

� Inconveniente: • Consultas más lentas al tener que buscar datos de diferentes

fragmentos en distintas sedes.• Aumenta la complejidad para garantizar la integridad, consistencia

y recuperabilidad.


Reglas para la fragmentación

� Integridad• Si una relación R es descompuesta en fragmentos R1, R2, … Rn cada dato

que pueda ser encontrado en R también debe ser encontrado en una o más relaciones Ri’s.

� Reconstrucción• Si una relación R es descompuesta en fragmentos R1, …,Rn, debe ser

posible definir el operador relacional ∂ tal que:R = ∂ Ri, ∀ Ri ∈ Fr

El operador ∂ diferirá según el tipo de fragmentación realizada.

� Desacoplamiento• Si R es descompuesta verticalmente, su PK debe estar en todos los

fragmentos.• Si R es decompuesta horizontalmente en fragmentos R1, R2, …, Rn y el

dato di está en Rj, no debe haber otro fragmento Rk (k≠j) que lo contenga

No pérdida de información

Preservar dependencias


Fragmentación y Asignación

� Con el fin de realizar una fragmentación adecuada es necesario trabajar con la siguiente información:• Sobre el significado de los datos• Sobre las aplicaciones que los usan• Acerca de la red de comunicaciones

� La elección de los sitios y el grado de repetición de los datos dependerá:• del rendimiento que se quiera obtener del sistema• del grado de disponibilidad de los datos que se desee y• del tipo y frecuencia de las transacciones en cada nodo.


Métodos para fragmentación

� Navathe (80’s)• Método de fragmentación vertical cuyo fin es crear fragmentos

minimizando el número de operaciones de unión que han de realizarse.

• Ventajas de este método:• simplicidad• no requiere gran cantidad de variables de entrada.

• 1. Definir la matriz de uso de atributos (procesos que utilizan esos atributos desde cada sede).

• 2. Construir la matriz de afinidad de cluster.(frecuencia de estos procesos en cada sede)

• 3. Se eligen los atributos que se usan frecuentemente juntos para realizar la fragmentación

• Inconvenientes:• No considera el efecto del índice (PK), se añade al final• No considera la red (fiabilidad, velocidad, coste, etc.)• No permite obtener un esquema fragmentado y replicado


Métodos para fragmentación

� FURD (Fragmentación, Ubicación y Reubicación Dinámica de Datos) (2005)

• Minimizar la función objetivo :

� Otras propuestas por Agrawal, Zilio, etc.... Pero no hay nada estándar

mim

m

i

i

jmimi

j m i

ji

mijik

m i

kj

k j

kjjmijikm

m i

kj

k j

kj

xbACwdc

xclqfwclqfz

∑∑∑∑∑

∑∑∑∑∑∑∑∑

++

+=

'

'''min

almacenamientocoste de replicación

coste actualizacióncoste escritura


Método FURD

� fkj = frecuencia de acceso de la consulta k desde el nodo j

� qkm = parámetro que indica con 1 si la consulta k usa el atributo m, y con 0 en caso contrario

� lkm = número de paquetes de comunicación requeridos para transportar el atributo m requerido por la consulta k

� cjt = costo de comunicación entre el nodo j y el nodo t� xmt = variable de decisión igual a 1 si el atributo m se

almacena en el nodo t, y 0 en caso contrario� amj = parámetro que indica con 1 si el atributo m se

encuentra almacenada actualmente en el nodo j� dm = número de paquetes de comunicación necesarios

para cambiar a otro nodo la ubicación del atributo m


¿Donde almacenar el catálogo

global?

� Centralizado. En un único nodo

� Totalmente repetido. En cada nodo

� Distribuido. En cada nodo se almacena la información necesaria para el nodo.

• En general, combinación de a y c.


Procesador global de consultas

(GQP)

� El objetivo es procesar las consultas globales para lo cual debe elegir a qué sede solicita las subconsultas y recoger los datos devueltos por todas las fuentes.

� El LQP es el responsable de ejecutar las subconsultasindicadas por GQP

� El álgebra relacional no es suficiente para expresar la ejecución de estrategias. Debe ser completada con operaciones para intercambio de datos entre nodos diferentes.


Procesador global de consultas

(GQP) (y 2)

� Crear planes de ejecución:• Traducir la consulta global a los esquemas exportados y de

ahí al lenguaje propio del gestor• Coste de ejecución en cada sede (estadísticas)• Coste de transferencia (volumen de datos/BW)• Coste de la combinación de resultados

� Seleccionar el de menor coste• Objetivo más extendido: Minimizar los costos de

comunicación. • Regla: Seleccionar el nodo que envía la mayor cantidad de

datos al nodo de operación como lugar para ejecutar la misma


Gestor de transacciones global

� Su papel es:• Mantener la consistencia en múltiples

réplicas• Recuperarse ante fallos propios (de la sede)

o debidos a la red. Sincronización.• Gestionar transacciones distribuidas


Transacciones distribuidas� Cada sede tiene:

• Gestor de transacciones. Administra la ejecución de las transacciones ( o subtransacciones) que acceden a datos de esa sede (puede ser una localo parte de una global)

• Coordinador de transacciones. Coordina la ejecución de las diferentestransacciones iniciadas en esa sede (locales o globales)

� El Gestor de transacciones se encarga de:• Mantener un “log” para la recuperación• Participar en un esquema de control de concurrencia apropiado para

coordinar la ejecución concurrente de las transacciones que se ejecuten en esa sede

� El coordinador de transacciones debe:• Iniciar la ejecución de la transacción• Dividir la transacción para enviar a las sedes correspondientes para su ejecución (subtransacciones)• Coordinar el fin de la transacción, ya sea que quedeejecutada o se aborte.


Técnicas control de

concurrencia distribuido

� Control de concurrencia distribuido basado en una copia distinguida de cada elemento deinformación• Existe una copia de cada elemento de información como

copia distinguida en una sola sede (generalmente el coordinador de transacciones) y este se encarga delbloqueo y desbloqueo. Extensión del modelo centralizado.

� Confirmación distribuida (distributed commit)• Se solicita bloqueo a todas las sedes con réplica del

elemento y cada sede realiza el bloqueo y decide si da permiso o no. Si la mayoría bloquea se informa al resto y prosigue.

• Protocolos: two-phase commit y three –phase commit


Protocolo en dos fases


Protocolo en dos fases (y 2)

� FASE 1(VOTACION)• El coordinador de transacciones del nodo Ci envía un

mensaje a todos los nodos donde se ejecuta T. Al recibir ese mensaje, el gestor de transacciones de cada nodo determina si está dispuesto a comprometer su parte de T (no hace el COMMIT). Puede enviar ABORTAR o COMMIT. Anota en el fichero de log <T PREPARE>

� FASE 2 (DECISION)• Cuando Ci recibe la respuesta de todos los nodos, o

cuando ha transcurrido un intervalo de tiempo predeterminado desde su envío, Ci determina si puede hacer COMMIT o ABORTAR la transacción T. COMMIT si recibe COMMIT de todos los nodos, sino ROLLBACK. Una vez tomada la decisión Ci envía un mensaje a todos los nodos participantes para que ejecuten el COMMIT o el ROLLBACK. Se anota la situación en log de cada sede.


Problemas en 2PC (y 3)

� Funciona bien si no falla ningún servidor ni hay problemas de red (pérdida de mensajes).

� La información en las sedes puede quedar bloqueada si se inicia en el proceso y luego el Gestor de Transacciones falla. Se sueleresolver con un time-out o esperando a que se recupere.

� Pueden ocurrir bloqueos entre varios nodos. La construcción de grafos de precedencia en cada nodo no basta, se ha de crear uno global.

� Exitosamente implementado en Oracle y Sybase

� 3 phase commit resuelve el problema del bloqueo porque añade una fase intermedia en la que se obtiene y distribuye el resultado del voto antes de enviar el comando COMMIT. Más coste y peor rendimiento.


Three phase commit




� Control de Concurrencia Distribuido basado en Votación• No existe copia distinguida• Cada copia mantiene su propia reserva y puede

conceder o rechazar la solicitud. Si la mayoría de las copias otorgan una reserva a la transacción que lo solicita, ésta poseerá la reserva e informará a todas las copias que le ha sido concedido. Si una transacción no recibe la mayoría de los votos de concesión de la reserva durante un cierto periodo de tiempo predefinido, cancelará su solicitud e informará de ello a todos los sitios.

• Trafico alto de mensajes




� Marcas temporales• Idea en los sistemas centralizados: se da a cada

transacción una marca temporal única que el sistema utiliza para decidir el orden de secuenciación.

• Para generalizar a un entorno distribuido hay que desarrollar un esquema para generar marcas temporales únicas.• Esquema centralizado: se escoge un único nodo para

distribuir las marcas temporales• Esquema distribuido: cada nodo genera una marca

temporal local única. La marca temporal global única se obtiene concatenando la marca temporal local única con el identificador de nodo, que también debe ser único


Recuperación distribuida

� Proceso complejo, es difícil determinar si un nodo está caído, si se ha producido pérdida de mensajes, etc.

� En cada sede, el gestor de transacciones deberá ser capaz de recuperarse ante fallos leyendo los ficheros de log.

� La gestión de la recuperación se dificulta con los protocolos distribuidos como 2PC y 3PC ya que deberán ser capaces de conectarse a otras sedes para saber qué acciones se tomaron en transacciones en las que ellos fallaron.


Mercado comercial

� No hay fragmentación real, más bien replicación. Las consultas y actualizaciones se hace mediante vistas, procedimientos almacenados y disparadores apoyándose en interfaz OLE-DB.

� SQL Server 2005 y 2008• Réplicas “publicador-suscriptor-distribuidor” (snapshot, transaccional, mezcla). • Permite las consultas distribuidas por medio del uso de servidores vinculados (OLE-

DB). • Dispone de Servidor de transacciones distribuidas (versión empresarial).

� Oracle• Réplica (“instantáneas” con actualización síncronas o asíncronas) • Consultas distribuidas mediante Dblinks.• Transacciones distribuidas con compromiso en 2 fases.

� DB2• DB2 Replication (gestión de réplicas).• DB2 Information Integrator que proporciona soporte para la federación, réplica y

búsqueda. Integra tablas db2 remotas o tablas de otros gestores en un esquema global distribuido.

• La edición federada proporciona una optimización de consultas basada en costes entre los sitios.

• Proporciona soporte completo a transacciones distribuidas con compromiso en 2 fases. Puede actuar como coordinador y como participante.

Bases de Datos Distribuidas

Documents

Transcript of Bases de Datos Distribuidas