La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

UNLP - Facultad de Informática IBD1 Arquitecturas de Sistemas de BD.

Presentaciones similares


Presentación del tema: "UNLP - Facultad de Informática IBD1 Arquitecturas de Sistemas de BD."— Transcripción de la presentación:

1 UNLP - Facultad de Informática IBD1 Arquitecturas de Sistemas de BD

2 UNLP - Facultad de Informática IBD2 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.

3 UNLP - Facultad de Informática IBD3 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).

4 UNLP - Facultad de Informática IBD4 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

5 UNLP - Facultad de Informática IBD5 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.

6 UNLP - Facultad de Informática IBD6 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

7 UNLP - Facultad de Informática IBD7 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.

8 UNLP - Facultad de Informática IBD8 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.

9 UNLP - Facultad de Informática IBD9 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.

10 UNLP - Facultad de Informática IBD10 Arquitecturas de Sistemas de BD Se requiere funcionalidad back-end completa en los clientes Utilizada en sistemas de BDOO.

11 UNLP - Facultad de Informática IBD11 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=10 12 bytes), ó que tienen que procesar miles de transacciones por segundo (los sistemas centralizados o Clientes- Servidor no lo soportan)

12 UNLP - Facultad de Informática IBD12 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)

13 UNLP - Facultad de Informática IBD13 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.

14 UNLP - Facultad de Informática IBD14 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.

15 UNLP - Facultad de Informática IBD15 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

16 UNLP - Facultad de Informática IBD16 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)

17 UNLP - Facultad de Informática IBD17 Bases de Datos Distribuidas Diseño de BDD - Reglas de Date 1 Autonomí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.

18 UNLP - Facultad de Informática IBD18 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

19 UNLP - Facultad de Informática IBD19 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)

20 UNLP - Facultad de Informática IBD20 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

21 UNLP - Facultad de Informática IBD21 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.

22 UNLP - Facultad de Informática IBD22 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

23 UNLP - Facultad de Informática IBD23 Bases de Datos Distribuidas 6 Independencia 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

24 UNLP - Facultad de Informática IBD24 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

25 UNLP - Facultad de Informática IBD25 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.

26 UNLP - Facultad de Informática IBD26 Bases de Datos Distribuidas 9 Independencia de hardware –Es necesario tener la posibilidad de ejecutar el mismo DBMS en diferentes plataformas de Hardware

27 UNLP - Facultad de Informática IBD27 Bases de Datos Distribuidas

28 UNLP - Facultad de Informática IBD28 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

29 UNLP - Facultad de Informática IBD29 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

30 UNLP - Facultad de Informática IBD30 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)

31 UNLP - Facultad de Informática IBD31 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

32 UNLP - Facultad de Informática IBD32 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.

33 UNLP - Facultad de Informática IBD33 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.

34 UNLP - Facultad de Informática IBD34 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.

35 UNLP - Facultad de Informática IBD35 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.

36 UNLP - Facultad de Informática IBD36 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

37 UNLP - Facultad de Informática IBD37 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

38 UNLP - Facultad de Informática IBD38 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

39 UNLP - Facultad de Informática IBD39 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

40 UNLP - Facultad de Informática IBD40 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

41 UNLP - Facultad de Informática IBD41 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

42 UNLP - Facultad de Informática IBD42 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éneoLocales: sobre un modelo de datos homogéneo Globales: sobre el modelo de datos heterogéneo.Globales: sobre el modelo de datos heterogéneo.


Descargar ppt "UNLP - Facultad de Informática IBD1 Arquitecturas de Sistemas de BD."

Presentaciones similares


Anuncios Google