Arquitecturas de Sistemas de BD

1. Arquitecturas de Sistemas de BD IBD

2. Arquitecturas de Sistemas de BD • Introducción: • La conexión en red de varias computadoras permite que algunas tareas se ejecuten en el servidor y otras en los clientes  desarrollo de sistemas de BD Cliente-Servidor • La necesidad de procesamiento paralelo de consultas ha conducido al desarrollo de los sistemas de BD Paralelos • Para administrar datos distribuidos geográfica o administrativamente, se han desarrollado sistemas de BD Distribuidos. IBD

3. Arquitecturas de Sistemas de BD • Sistemas Centralizados: posibilidades • Se ejecutan en una sola computadora sin interactuar con otros sistemas. • Sistemas de cómputo de propósito general: algunas CPU y un número de dispositivos que están conectados a través de un bus común que proveen acceso a memoria compartida • Sistemas monousuario: un único usuario con SO que permite sólo 1 usuario • Sistemas multiusuario: varios usuarios a la vez usando terminales (sistemas mainframes). IBD

4. Arquitecturas de Sistemas de BD • Sistemas Centralizados: • No tienen control de concurrencia • Las facilidades de recuperación en estos sistemas o no existen o son primitivas • La mayoría de estos sistemas no admite o no usa SQL, proporcionan un lenguaje de consulta muy simple IBD

5. Arquitecturas de Sistemas de BD • Sistemas Cliente/Servidor • Servidores satisfacen requerimientos generados por los clientes. • Funcionalidad de BD, dividida en: • Back-end: maneja acceso a estructuras, evaluación y optimización de consultas, control de concurrencia y recuperación (sistema subyacente) • Front-end: consiste de herramientas como formularios, generadores de reportes, interfaces, etc. (parte visible por el usuario) • La interface entre ambas se logra con SQL o una Aplicación. IBD

6. Arquitecturas de Sistemas de BD • Ventajas de reemplazar mainframes con redes de workstations o PC: • Mejor funcionalidad por el costo • Flexibilidad en la ubicación de recursos y facilidades en la expansión • Mejores interfaces de usuario • Facilidad de mantenimiento IBD

7. Arquitecturas de Sistemas de BD • Servidores pueden ser categorizados en dos grupos: • Servers de transacción utilizados en sistemas relacionales • Servers de datos usados por ejemplo en sistemas de BD OO. IBD

8. Arquitecturas de Sistemas de BD • Servidores transaccionales • Los clientes envían requerimientos al servidor donde se ejecutan las transacciones y los resultados se envían nuevamente al cliente. • Los requerimientos se hacen en SQL y se comunican via RPC (remote procedure call) • ODBC (open database conectivity): es la API estandar de Microsoft para la conección de servers, envio de pedidos SQL y recepción de resultados. IBD

9. Arquitecturas de Sistemas de BD • Servidores de datos • Usadas en LAN con conexiones muy rápidas entre clientes y servidores. • Las máquinas clientes son comparables al servidor en cuanto a poder de procesamiento y ejecutan tareas de cómputo intensivo. • Se envían los datos al cliente y es este el que realiza la operación, luego envía nuevamente los resultados al servidor. IBD

10. Arquitecturas de Sistemas de BD • Se requiere funcionalidad back-end completa en los clientes • Utilizada en sistemas de BDOO. IBD

11. Arquitecturas de Sistemas de BD • Sistemas paralelos • Mejoran la velocidad de procesamiento y E/S mediante la utilización de CPU y discos en paralelo • Múltiples procesadores y múltiples discos conectados a través de una red de alta velocidad. • Se utilizan en aplicaciones que han de manejar BD muy grandes (del orden de terabytes=1012 bytes), ó que tienen que procesar miles de transacciones por segundo (los sistemas centralizados o Clientes-Servidor no lo soportan) IBD

12. Arquitecturas de Sistemas de BD • Sistemas paralelos • Dos conceptos: máquinas paralelas • De grano grueso: un pequeño número de procesadores potentes • De grano fino: un gran número de procesadores pequeños (soportan mayor grado de paralelismo) IBD

13. Arquitecturas de Sistemas de BD • Sistemas paralelos • Dos conceptos para medir performance • Throughput (productividad): número de tareas que pueden ser completadas en un intervalo de tiempo • Tiempo de respuesta: en contestar una tarea. IBD

14. Arquitecturas de Sistemas de BD • Sistemas distribuidos • Los datos se ubican en múltiples máquinas (sitio o nodos) • Una red de alta velocidad interconecta las máquinas • Los datos son compartidos por usuarios y múltiples máquinas. • Transacciones de dos tipos • Locales: solo acceden a datos de su propio nodo • Globales: acceden a datos de otras localidades/nodos. IBD

15. Arquitecturas de Sistemas de BD • Compromisos • Compartir datos: se debe poder acceder a los datos de cualquier nodo (esta es la mayor ventaja) • Autonomía: cada sitio tiene el control de su información • Disponibilidad: los datos pueden ser replicados en varios lugares y el sistema puede funcionar aún si un sitio falla. • Ej. de uso ( la falla temporal de acceso a un dato de una cía. aérea , puede hacer perder venta de pasajes) • Desventajas • Costo de desarrollo del software (complejidad inherente a garantizar la coordinación entre nodos) • Mayor posibilidad de bugs • Mayor sobrecarga de procesamiento • Mas vulnerable IBD

16. Bases de Datos Distribuidas • Sistemas distribuidos vs. Paralelos • Procesadores poco acoplados • No comparten componentes físicos • Independencia de DB de cada nodo o localidad • Almacenamiento de datos distribuido • Replicación • Disponibilidad (aspecto positivo) • Aumento de paralelismo en consultas (aspecto positivo) • Aumento en la sobrecarga en actualizaciones (aspecto negativo) IBD

17. Bases de Datos Distribuidas • Diseño de BDD - Reglas de Date 1Autonomía local • Los nodos o localidades deben ser independiente entre ellos. • Características de cada nodo • Tiene su propio DBMS • DBMS controla todos los aspectos ligados a él • Las operaciones de acceso a datos locales utilizan solo recursos locales • Hay cooperación entre los nodos para el acceso distribuido de datos. IBD

18. Bases de Datos Distribuidas 2 No es necesario un sitio central • Todos los sitios/nodos deben ser tratados como iguales • De existir un sitio central, sería cuello de botella • De existir un sitio central, el sistema sería vulnerable, porque una falla haría fallar todo el sistema • Para el protocolo de commit de dos fases se necesita sitio central pero solo durante la ejecución de una transacción IBD

19. Bases de Datos Distribuidas 3 Operación continua • Un sistema BDD no requiere estar nunca fuera de servicio • Debe proporcionar mayor confiabilidad y mayor disponibilidad • Se requiere • Soporte para backups on line, total o incremental • Soporte para recuperaciones rápidas de BD • Soporte de DBMS tolerante a fallos (con hardware acorde) IBD

20. Bases de Datos Distribuidas 4 Independencia de ubicación de datos • Los usuarios y las aplicaciones no tienen que conocer la ubicación física de los datos. Actúan como si fuesen locales a ellos. • Sin transparencia local deberían distinguirse los datos locales de los remotos. • Simplifica los programas de usuario IBD

21. Bases de Datos Distribuidas • Punto crítico: Diccionario de datos • Usuarios y aplicaciones se refieren a los datos mediante alias • El DD debe mantener una tabla con los elementos de datos, sus alias y sus ubicaciones • Un DDBMS debe mantener y utilizar el DD, aún cuando los datos se mueven entre localidades • El DD debe estar replicado en las localidades y las réplicas deben mantenerse actualizadas. IBD

22. Bases de Datos Distribuidas 5 Independencia de Fragmentación de datos • Fragmentación • Horizontal -> a nivel fila • r = r1 U r2 U ... U rn • Vertical -> a nivel columna • r = r1 |x| r2 |x| ... |x| rn • Mixta • La fragmentación es necesaria por razones de rendimiento. • Los usuarios deben comportarse como si los datos no estuvieran fragmentados • Los datos pueden estar almacenados en la ubicación donde son usados más frecuentemente para que la mayoría de las operaciones sean locales y se reduzca el tráfico de la Red IBD

23. Bases de Datos Distribuidas 6Independencia de la Replicación de datos • Replicación • Mejor rendimiento: las aplicaciones operan sobre copias locales en vez de comunicarse con sitios remotos • Mejor disponibilidad: un objeto replicado esta disponible mientras haya al menos una copia • Desventaja: propagar las actualizaciones • El usuario debe comportarse como si los datos no estuvieran replicados IBD

24. Bases de Datos Distribuidas 7 Procesamiento de consultas distribuidas • La performance de una consulta debe ser independiente del sitio donde se realiza la consulta • Se debe maximizar la optimización de consultas IBD

25. Bases de Datos Distribuidas 8 Administración de transacciones distribuidas • Debe mantenerse la atomicidad de las transacciones • Control de recuperación de información • Control de concurrencia • Protocolos utilizado para preservar la atomicidad: dos fases o tres fases más conocidos. IBD

26. Bases de Datos Distribuidas 9 Independencia de hardware • Es necesario tener la posibilidad de ejecutar el mismo DBMS en diferentes plataformas de Hardware IBD

27. Bases de Datos Distribuidas IBD

28. Bases de Datos Distribuidas 10 Independencia del SO • Es necesario tener la posibilidad de ejecutar el mismo DBMS en diferentes SO 11 Independencia de red 12 Independencia del DBMS • Todos los DBMS en sitios distintos deben soportar la misma interface IBD

29. Bases de Datos Distribuidas • Denominación de elementos • Como asegurar nombre únicos entre localidades • Asignador de nombres central • Contradice las reglas de Date • Cuello de botella, inseguridad ante caídas • Cada localidad agrega como prefijo su nombre IBD

30. Bases de Datos Distribuidas • Procesamiento de consultas • Aspectos • Costos de transmisión de datos por la red • Ganancia potencial ante la posibilidad de utilizar paralelismo en la consulta • Existen diversas posibilidades para el desarrollo de las consultas en BDD, el desarrollo de las mismas depende de la ubicación de los datos y del tipo de consulta. • Ej: movimientos del cliente Garcia • Consulta cliente=“Garcia” (cuenta) • En realidad cliente=“Garcia” (cuenta1)Ucliente=“Garcia” (cuenta2) IBD

31. Bases de Datos Distribuidas • Transacciones distribuidas • El coordinador actúa como centro durante la vida de la transacción. • Deben preservar ACID • Autonomía • Consistencia • Isolation (aislamiento) • Durabilidad • Se complica con transacciones globales, el fallo puede estar en varios lugares • Cuando una transacción se genera y se determina que es global se subdivide y cada copia es gestionada en cada localidad. ESTO PRESERVA LA AUTONOMÍA IBD

32. Bases de Datos Distribuidas • Arquitectura del sistema • Gestor de transacciones: encargado local de la transacción. • El gestor de transacciones preserva la autonomía de cada localidad, (una transacción es gestionada en cada localidad por el gestor de la misma). • Coordinador de transacciones: coordina la ejecución de la transacción generada localmente. Actua como centro durante la vida de la transacción. IBD

33. Bases de Datos Distribuidas • Responsabilidad del gestor • Conservar registro histórico con fin de recuperación • Participar en el esquema de control de concurrencia de la transacción en esa localidad • Responsabilidad del coodinador • Iniciar la ejecución de la transacción • Dividir la transacción en subtransacciones y dividir a estas para su ejecución • Coordinar la terminación de la transacción entre todas las localidades participantes. IBD

34. Bases de Datos Distribuidas • Fallos del sistema • Fallo de una localidad • Pérdida de mensajes • Fallo del enlace de comunicaciones • División o particionamiento de la red • Topologías de red • Diversos tipos • Características • Costo de instalación • Costo de comunicaciones • Disponibilidad. IBD

35. Bases de Datos Distribuidas • Robustez: debe detectar los fallos, volver a configurar el sistema y recuperarse cuando se repare el enlace. • Pasos ante un fallo • Si localidad tiene datos replicados  actualizar el catálogo para no acceder a ella • Si había transacciones activas en esa localidad  abortarlas. • Si la localidad es un “servidor central” de una transacción obrar de acuerdo al protocolo que veremos más adelante. IBD

36. Bases de Datos Distribuidas • Protocolos de compromiso • Aseguran la atomicidad de las transacciones en un entorno distribuidos • Alternativas • Dos fases • Tres fases • Optimista • Pesimista • Una Fase IBD

37. Bases de Datos Distribuidas • Dos Fases (Resumen) Fase I • Un nodo coordinador inicia el protocolo para una Transacción. El resto de los nodos se denominan participantes • Una transacción no compromete en ningún nodo hasta que todos los participantes estén preparados. • El coordinador envía un msg prepare a los participantes IBD

38. Bases de Datos Distribuidas • Dos Fases – Fase II • Cada participante responde al coordinador un voto (+ ó -) • Si el coordinador recibe un voto (-) aborta la transacción y se lo comunica a todos los participantes • Si el coordinador recibe todos los votos y son (+), registra el compromiso y se lo comunica a todos los participantes IBD

39. Bases de Datos Distribuidas • Dos Fases • Los participantes registran la decisión, la aplican y envían un done al coordinador • El coordinador da finalizada la Transacción cuando recibe el done de todos los participantes IBD

40. Bases de Datos Distribuidas • Dos Fases (Fallos) • Desde el punto de vista del coordinador • Al coordinador no le llegan todas las respuestas al prepare. Aborta unilateralmente la Transacción • No le llegan los mensajes done. Los sigue pidiendo por un tiempo • Desde el punto de vista del participante • No recibe el prepare. Aborta la transacción. Si después recibe este mensaje contesta (-) o lo ignora • Si no recibe el resultado luego de emitir su voto (+) se bloquea IBD

41. Bases de Datos Distribuidas • Dos Fases (Ppal desventaja): • El coordinador recibió todos los votos, todos (+), y se cae antes de enviar el resultado a los participantes. • No veremos como es la recuperación ante fallos IBD

42. Bases de Datos Federales • Bases de datos heterogeneas en la solución de un problema • Heterogeneidad de hardware y software de soporte. • Heterogeneidad del modelo de datos • Deben producirse traducciones directas entre modelos. • Transacciones • Locales: sobre un modelo de datos homogéneo • Globales: sobre el modelo de datos heterogéneo. IBD