Post on 24-Jun-2015
Marta Zorrilla - UC 1
Arquitecturas de los Sistemas de Bases de
Datos
Marta Zorrilla
-Universidad de Cantabria-
Marta Zorrilla - UC 2
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.
Marta Zorrilla - UC 3
Bases de datos distribuidas
Marta Zorrilla
-Universidad de Cantabria-
Marta Zorrilla - UC 4
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
Marta Zorrilla - UC 5
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
Marta Zorrilla - UC 6
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
Marta Zorrilla - UC 7
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
Marta Zorrilla - UC 8
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.
Marta Zorrilla - UC 9
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
Marta Zorrilla - UC 10
Aplicaciones
� Aerolíneas
� Gestión de viajes
� Gestión financiera (sistemas interbanca)
� Manufactura
� Cadenas hoteleras
� Etc.
Marta Zorrilla - UC 11
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
Marta Zorrilla - UC 13
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
Marta Zorrilla - UC 14
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.
Marta Zorrilla - UC 15
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
Marta Zorrilla - UC 16
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
Marta Zorrilla - UC 17
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.
Marta Zorrilla - UC 18
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.
Marta Zorrilla - UC 19
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
Marta Zorrilla - UC 20
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
Marta Zorrilla - UC 21
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
EMP_ID NOMBRE DEPT SALARIO
E1 SANDRA D1 5000000
E2 ALFREDO D1 4000000
FRAGMENTO 2 DE LA TABLA EMPLEADO
EMP_ID NOMBRE DEPT SALARIO
E3 GUILLERMO D2 8000000
FRAGMENTO 3 DE LA TABLA EMPLEADO
EMP_ID NOMBRE DEPT SALARIO
E4 JUAN D3 9000000
FRAG_1 = σ DEPT=D1 ( EMP_TABLE)FRAG_2 = σ DEPT=D2 ( EMP_TABLE)FRAG_3 = σ DEPT=D3 ( EMP_TABLE)
Marta Zorrilla - UC 22
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)
Marta Zorrilla - UC 23
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.
Marta Zorrilla - UC 24
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
Marta Zorrilla - UC 25
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.
Marta Zorrilla - UC 26
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
Marta Zorrilla - UC 27
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
Marta Zorrilla - UC 28
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
Marta Zorrilla - UC 30
¿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.
Marta Zorrilla - UC 31
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.
Marta Zorrilla - UC 32
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
Marta Zorrilla - UC 33
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
Marta Zorrilla - UC 34
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.
Marta Zorrilla - UC 35
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
Marta Zorrilla - UC 36
Protocolo en dos fases
Marta Zorrilla - UC 37
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.
Marta Zorrilla - UC 38
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.
Marta Zorrilla - UC 39
Three phase commit
Marta Zorrilla - UC 40
Técnicas control de
concurrencia distribuido
� 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
Marta Zorrilla - UC 41
Técnicas control de
concurrencia distribuido
� 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
Marta Zorrilla - UC 42
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.
Marta Zorrilla - UC 43
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.