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 BD distribuidas BD distribuidas No No federadas (homogéneos) Federadas (heterogéneos) Ligeramente acoplados Fuertemente acoplados Esquema simple simple Esquema 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 schema External schema External schema Global schema... Global schema Sólo uno en single-dbms Export schema Export schema Export schema... Export schema Component schema Component schema... Component schema Local schema Local schema... Local schema No en DBMS homogéneos 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 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 integrarlas para obtener el esquema global Si no existen, hay que definir el esquema conceptual global y fragmentar y asignar a los nodos Diseño conceptual Esquema Conceptual global Análisis de requisitos Requisitos del Sistema Intervención del usuario Integración de vistas Información de acceso Diseño de la distribución Esquemas conceptuales locales Diseño vistas Definición esquemas externos Intervención del usuario 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 E1 E2 E3 E4 EXP PROGRAMADOR ANALISTA DISEÑADOR PEON FRAG_1 = π EMP_ID, DEPT, NOMBRE, EXP ( EMP_TABLE) 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 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 No pérdida de informació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 : min + z = j m i k j c ji d coste escritura f mi kj w' m i jmi + q kj m l km c i ji w CA jmi i b + m x mi k j coste actualización f ' kj m i q' kj l' k c ji x 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 f kj = frecuencia de acceso de la consulta k desde el nodo j = parámetro que indica con 1 si la consulta k usa el atributo m, y con 0 en caso contrario = número de paquetes de comunicación requeridos para transportar el atributo m requerido por la consulta k = costo de comunicación entre el nodo j y el nodo t = variable de decisión igual a 1 si el atributo m se almacena en el nodo t, y 0 en caso contrario = parámetro que indica con 1 si el atributo m se encuentra almacenada actualmente en el nodo j = número de paquetes de comunicación necesarios para cambiar a otro nodo la ubicación del atributo m q km l km c jt x mt a mj d 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