Arquitecturas de Sistemas de BD

Arquitecturas de Sistemas de BD
UNLP - Facultad de Informática IBD

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

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

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

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

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

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

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

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

Se requiere funcionalidad back-end completa en los clientes Utilizada en sistemas de BDOO. UNLP - Facultad de Informática IBD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9 Independencia de hardware Es necesario tener la posibilidad de ejecutar el mismo DBMS en diferentes plataformas de Hardware UNLP - Facultad de Informática IBD

UNLP - Facultad de Informática IBD

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

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

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

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

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

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

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

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

Protocolos de compromiso Aseguran la atomicidad de las transacciones en un entorno distribuidos Alternativas Dos fases Tres fases Optimista Pesimista Una Fase UNLP - Facultad de Informática IBD

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

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

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

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

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

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

Arquitecturas de Sistemas de BD

Presentaciones similares

Presentación del tema: "Arquitecturas de Sistemas de BD"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Arquitecturas de Sistemas de BD

Presentaciones similares

Presentación del tema: "Arquitecturas de Sistemas de BD"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback