Vous êtes sur la page 1sur 41

Arquitecturas de los

Sistemas de Bases de
Datos

Marta Zorrilla
-Universidad de Cantabria-

Marta Zorrilla - UC 1
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 2
Bases de datos
distribuidas

Marta Zorrilla
-Universidad de Cantabria-

Marta Zorrilla - UC 3
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 4
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 Science
1798. Springer-Verlag. 2000

Marta Zorrilla - UC 5
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 6
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 7
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 8
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 9
Aplicaciones

 Aerolíneas
 Gestión de viajes
 Gestión financiera (sistemas interbanca)
 Manufactura
 Cadenas hoteleras
 Etc.

Marta Zorrilla - UC 10
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 11
Clasificación de SGBDD

BDdistribuidas
BD distribuidas

Nofederadas
No federadas Federadas
Federadas
(homogéneos)
(homogéneos) (heterogéneos)
(heterogéneos)

Ligeramente
Ligeramente Fuertemente
Fuertemente
acoplados
acoplados acoplados
acoplados

Esquema
Esquema Esquema
Esquema
simple
simple múltiple
múltiple

Marta Zorrilla - UC 13
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 14
arquitectura ANSI/SPARC

Modelo para SGBD federados


External External External
schema schema schema

Sólo uno en
Global .... Global single-DBMS
schema schema

Export Export Export .... Export


schema schema schema schema

Component Component Component


....
schema schema schema
No en DBMS
homogéneos
Local Local .... Local
schema schema schema

Marta Zorrilla - UC 15
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 16
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 17
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 18
Diseño de BD distribuidas
Análisis de requisitos

 Hay que decidir en qué nodos Requisitos del Sistema


deben residir los datos y las
aplicaciones que trabajan con los
datos Diseño
Intervención del usuario
Diseño

• Si existen ya las bases de conceptual


Integración de vistas
vistas

datos, hay que integrarlas


Esquema Información Definición
para obtener el esquema Conceptual de acceso esquemas
global global externos

• Si no existen, hay que definir Diseño de la Intervención


el esquema conceptual global distribución del usuario

y fragmentar y asignar a los


nodos Esquemas
conceptuales
locales

Diseño físico

Esquema físico

Monitorización y ajustes
Marta Zorrilla - UC 19
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 20
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 21
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 FRAG_1 = π EMP_ID, DEPT, NOMBRE, EXP ( EMP_TABLE)
E3 DISEÑADOR
E4 PEON
FRAG_2 = π EMP_ID, SALARIO ( EMP_TABLE)

Marta Zorrilla - UC 22
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 23
Reglas para la fragmentación
 Integridad No pérdida de información
• 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 Preservar dependencias


• 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

Marta Zorrilla - UC 24
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 25
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 26
Métodos para fragmentación

 FURD (Fragmentación, Ubicación y Reubicación


Dinámica de Datos) (2005)
• Minimizar la función objetivo :
coste escritura coste actualización

min z = ∑∑ f kj ∑∑ qkj lkm c ji w jmi + ∑∑ f ' ∑∑ q'


kj kj l 'k c ji xmi
k j m i k j m i

+ ∑∑∑ c
j m i
ji d mi w' jmi + ∑∑ C A b
m i
i x
m mi

coste de replicación almacenamiento

 Otras propuestas por Agrawal, Zilio, etc.... Pero no hay


nada estándar
Marta Zorrilla - UC 27
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 28
¿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 30
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 subconsultas


indicadas 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 31
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 32
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 33
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 local
o parte de una global)
• Coordinador de transacciones. Coordina la ejecución de las diferentes
transacciones 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 quede
ejecutada o se aborte.

Marta Zorrilla - UC 34
Técnicas control de
concurrencia distribuido

 Control de concurrencia distribuido basado en una


copia distinguida de cada elemento de
informació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 del
bloqueo 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 35
Protocolo en dos fases

Marta Zorrilla - UC 36
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 37
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 suele
resolver 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 38
Three phase commit

Marta Zorrilla - UC 39
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 40
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 41
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 42
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.
Marta Zorrilla - UC 43