09 de junio 1999bd distribuidas2 arquitecturas de bases de datos n centralizadas – bd en una sola...

09 de Junio 1999 BD distribuidas 2

Arquitecturas de bases de datos Centralizadas

– BD en una sola máquina y una sola CPU– todos los usuarios acceden a esa máquina

Sistemas paralelos– BD en una sola máquina y varias CPU y varios discos– todos los usuarios acceden a esa máquina

Sistemas cliente-servidor– BD en una sola máquina (back-end)– los usuarios acceden desde sistemas remotos (front-end)

Sistemas distribuidos– BD repartida entre varias máquinas– los usuarios acceden a cualquiera de las máquinas del sistema


Base de datos distribuida

Es una colección de múltiples y lógicamente relacionadas bases de datos sobre una red de ordenadores.

Un DBMS distribuido se define como el software que permite gestionarlo y hacer la distribución transparente a los usuarios.

Es una BD almacenada en varios ordenadores que se comunican mediante una red de comunicaciones.

El usuario debe poder usarla como un sistema único. Puede procesar todo tipo de peticiones complejas. La peticiones se pueden procesar en el sitio que hizo la petición o en

cualquier otro o parcialmente en varios. Necesita una gestión de transacciones especial. Debe proporcionar optimización de peticiones automáticamente.


Ventajas

Autonomía local Mejora de rendimiento Mejora de la seguridad y la disponibilidad Economía Capacidad de expansión Capacidad de compartición


Desventajas

Falta de experiencia Complejidad Coste Control de distribución Seguridad Dificultades para cambiar


Aspectos a tener en cuenta

Transparencia de datos en red Proceso de peticiones distribuido Modelo de transacciones distribuido Control de concurrencia Manejo de bloqueos Sistemas distribuidos con múltiples bases

de datos


Transparencia de red

Capacidad del sistema para abstraer a los usuarios los detalles de donde y como están almacenados los datos en el sistema distribuido.

Aspectos a considerar:– Formas de distribuir los datos:

réplica y fragmentación

– Denominación de los datos– Localización de fragmentos y réplicas


Distribución de los datos

Réplica– se mantienen tantas copias de los datos como sitios

para facilitar la recuperación y la tolerancia a fallos.

Fragmentación– la relación se divide en varios fragmentos

almacenando uno en cada sitio.

Réplica y fragmentación– la relación se parte en varios fragmentos manteniendo

el sistema una copia en cada sitio.


Réplica de datos

Consiste en mantener una copia exacta de de una relación o parte de ella en mas de un sitio.

La réplica completa se produce cuando se copia la relación en todos los sitios.

Una BD completamente redundante es aquella en la que cada sitio contiene una réplica completa de la BD.


Características

Ventajas de la réplica– Disponibilidad

frente a fallos de la red.– Paralelismo

las peticiones se pueden procesar en varios nodos en paralelo.

– Transferencia de datos reducida

Inconvenientes– Se eleva el coste de la actualizaciones– Se complica el control de la concurrencia


Fragmentación

Consiste en dividir una relación en varios trozos que contengan suficiente información para poder reconstruir la relación cuando sea necesario

– Horizontal se asignan las tuplas a fragmentos

– Vertical el esquema de la relación se divide en varios todos los esquemas resultantes contienen una clave candidato común

(o superclave) se añade un atributo especial que actúa como clave candidata.

Ambos tipos de fragmentación se pueden mezclar


Ejemplo

type cuenta =

record

nombre: char(22);

maquina: char(8);

login: char(8);

end

pedro jupiter plp01luis venus lls02

maria jupiter mrm03ana venus ana04

pedro sol ppp05elena marte cmr06carlos jupiter crc07sofia venus sofi08elena jupiter elsb09elena venus els10elisa pluton eli11elena neptuno elsc12


Fragmentación horizontal



pedro sol ppp05elena marte cmr06carlos jupiter crc07sofia venus sofi08elena jupiter elsb09elena venus els10elisa pluton eli11elena neptuno elsc12



pedro sol ppp05

elena marte cmr06carlos jupiter crc07sofia venus sofi08elena jupiter elsb09elena venus els10elisa pluton eli11elena neptuno elsc12

Sitio A

Sitio B


Fragmentación vertical

pedro jupiter 0101luis venus 0202

maria jupiter 0303ana venus 0404

pedro sol 0505elena marte 0606carlos jupiter 0707sofia venus 0808elena jupiter 0909elena venus 1010elisa pluton 1111elena neptuno 1212

01plp0102lls0203mrm0304ana0405ppp0506cmr0607crc0708sofi0809elsb0910els1011eli1112elsc12

Sitio A Sitio B


Ventajas de la fragmentación

Horizontal– permite el procesamiento paralelo de una relación– permite que una tabla global pueda estar donde se utiliza mas

frecuentemente Vertical

– permite que una tabla pueda ser distribuida en función del uso de sus atributos.

– permite descomposiciones adicionales que se pueden conseguir con normalización.

– el atributo especial facilita la mezcla de fragmentos verticales– permite el procesamiento paralelo de una relación


Criterios de denominación de datos

1. Cada dato debe tener un nombre único en el sistema

2. Debe ser posible encontrar la localización de los datos de forma eficiente.

3. Debe ser posible cambiar la localización de los datos de forma transparente.

4. Cada sitio debe poder crear nuevos datos autónomamente.


Esquema centralizado

Estructura– un servidor asigna todos los nombres– cada sitio mantiene un registro de todos los datos locales– los sitios piden al servidor la localización de los datos remotos

Ventajas– Cumple los tres primeros criterios de denominación de datos

Inconvenientes– no satisface el último criterio– el servidor puede saturarse– el servidor es un elemento crítico


Uso de alias

Cada sitio añade su identificador a cada nombre que genera.– sitio17.datoXXX

Maneja un identificador único y elimina los problemas del servidor central, pero no consigue transparencia de red.

La solución es asignar alias a los datos y almacenar la relación en cada sitio

– no hace falta conocer la localización del dato– no afecta si los datos cambian de sitio


Nombres únicos

Cada réplica de cada fragmento de un dato tiene un nombre único

Se utilizan sufijos para indicar de que réplica y de que fragmento es cada dato– sitio17.datoXXX.frag005.replica56

El nombre real de un dato se obtiene del alias localizando– primero la réplica– luego el fragmento


Para encontrar un dato

El subsistema de procesamiento de peticiones busca el nombre en la tabla de alias local

Si es una réplica se consulta la tabla de réplicas Si la réplica es fragmentada se examina la tabla de

fragmentación para saber como reconstruir la relación

Aunque solo se suelen consultar una o dos tablas, el algoritmo maneja cualquier combinación de réplicas y fragmentos.


Transparencia y actualización Debe asegurar que todas las réplicas y todos los

fragmentos de los datos afectados se actualizan.

Fragmentación horizontal– aplicar un predicado para saber si el dato pertenece a un

fragmento o no– insertar el dato en todas las réplicas

Fragmentación vertical– dividir el dato en fragmentos– insertar cada fragmento en cada réplica– Problema: pueden lanzarse dos actualización de

fragmentos distintos del mismo dato en paralelo sobre réplicas distintas


Proceso de peticiones distribuido

Hay que considerar criterios de coste más sofisticados que el sistemas centralizados:– Número de accesos a disco– Coste de la transmisión de datos sobre la red– Capacidad de procesamiento paralelo– Selección del sitio de procesamiento

Es necesario considerar expresiones sobre fragmentos– Construir una relación desde sus fragmentos– Sustituir una relación por una expresión que la

construye desde sus fragmentos.


Ejemplo

Con fragmentación horizontal– r = r1 r2

– r1 = atributo = valor1 (r)– r2 = atributo = valor2 (r)

La petición atributo = valor1 (r) consiste en atributo = valor1 (r1 r2 )

La optimización consiste en hacer la selección antes que la unión de fragmentos atributo = valor1 (r1) atributo = valor1 (r2 )

Como r2 no tiene valor1, la selección es vacía y el resultado es la selección de r1


Proceso de mezcla simple

Considerando la expresión r1r2r3 Suponer que

– no hay réplicas ni fragmentaciones– cada relación está en un sitio distinto– que el resultado hay que producirlo en el sitio de r1

Estrategia1. copiar r1 de S1 a S2 y hacer la mezcla r1r2

2. copiar el resultado temporal en S3 y hacer la mezcla

temporalr3

3. enviar el resultado a S1


Planes de evaluación alternativos

Se pueden diseñar diferentes estrategias cambiando los roles de los tres sitios

Se deben considerar los siguientes factores:– cantidad de información que hay que

transportar– coste de la transmisión de bloques de datos

entre sitios– la velocidad relativa de procesamiento de cada

sitio


Proceso de mezcla parcial

Sea r1 una relación con esquema R1 almacenada en S1

Sea r2 una relación con esquema R2 almacenada en S2

Se trata de evaluar la expresión r1r2 y almacenar el resultado en R1

– calcular temp1 = R1 R2(r1) en S1

– enviar temp1 a S2

– calcular temp2 = r1temp1 en S2

– enviar temp2 a S1

– calcular r1temp2 en S1


Definición formal

La mezcla parcial de r1 y r2 = r1< r2 Se define como R1(r1r2) Selecciona los elementos de r1 que

contribuyen a la mezcla r1r2 El procedimiento puede extenderse a

cualquier número de relaciones realizando varios pasos de mezcla parcial.


Estrategias para explotar el paralelismo

Considerar r1r2r3r4

donde cada relación se guarda en un sitio diferente y el resultado se debe dejar en S1

Estrategia paralela

– Se manda r1 a S2 y se calcula r1r2

– Se manda r3 a S4 y se calcula r3r4

– Se envían los resultados a S1 según se van produciendo

– Según van llegando los resultados a S1 se procesa la mezcla final (r1r2)(r3r4)


Modelo de transacciones distribuido

Soportar el proceso de transacciones– locales: en un solo sitio– globales: en varios sitios

Cada sitio debe disponer de un Gestor de Transacciones Local– mantiene el registro de actividades– participa en la coordinación de la ejecución de transacciones

globales. Hace falta un Coordinador de Transacciones en cada sitio:

– arranca la ejecución de transacciones en ese sitio– distribuye operaciones de la transacción a otros sitios– coordina la terminación de las transacciones originadas en ese sitio


Control de transacciones

Es el subsistema encargado de controlar la atomicidad de la ejecución de transacciones:

– parte local– parte distribuida

Para la parte distribuida hace falta un protocolo:– protocolo de acuerdo en dos fases (2PC)– protocolo de acuerdo en tres fases (3PC)

Hace falta un protocolo de selección de coordinador en caso de fallo Hace falta un algoritmo de control de concurrencia a nivel global

– protocolos de bloqueo– marcas de tiempo


Protocolo 2PC

Sirve para certificar que una transacción que se ha ejecutado de forma distribuida ha terminado bien.

El Coordinador de la transacción ejecuta el protocolo cuando se ejecuta el último paso de la transacción.

El protocolo tiene en cuenta todos los sitios que han intervenido en la transacción.

Si Si es el sitio que inició la transacción T, actúa como coordinador Ci y es el que inicia el protocolo.


Protocolo de acuerdo 2PC

<T prepare>

<T commit>

<T complete>

registroSi (Ci)

protocolo

prepare T ready T de S1

ready T de S2

.

ready T de Sn

commit T ack T de S1

ack T de S2

.

ack T de Sn

<T prepare>

<T abort>

registroSi (Ci)

protocolo


no T de Sj

.

abort T

Fase

1Fa

se 2


Fallo en un participante

La recuperación depende de la información del registro– si contiene un <T commit>, ejecuta un <T redo>– si contiene un <T abort>, ejecuta un <T undo>– si contiene un <T ready>, debe consultar a Ci para

decidir que hacer si <T commit>, ejecuta un <T redo> si <T abort>, ejecuta un <T undo>

Si no hay entradas de T en el registro, es que fallo antes de recibir el <T prepare>,

– se debe ejecutar un <T undo>


Fallo del coordinador

Los demás sitios deben decidir que hacer con T, en función del contenido del registro– si contiene un <T commit>, se da a T por entregada– si contiene un <T abort>, T debe abortar– si algunos sitios contienen <T ready>, hay que abortar– si todos los sitios contienen <T ready>, hay que

esperar a que el coordinador vuelva a funcionar esto puede provocar un bloqueo al obligar a esperar

a los sitios activos. el Protocolo 3PC puede resolver este problema


Protocolo de acuerdo 3PC

<T prepare>

<T precommit>

<T commit>

registroSi (Ci)

protocolo

prepare T ready T de Sk

k sitios

.

precommit T ack T de Sk

k sitios

commit T

<T prepare>

<T abort>

registroSi (Ci)

protocolo


no T de Sj

.

abort T

Fase

1Fa

se 2

Fase

3


Protocolo de fallo del coordinador

1. Los sitios activos eligen un nuevo coordinador Cnew.

2. Cnew pide el estado de T a cada participante.

– Commit: si el registro contiene un commit– Abort: si el registro contiene un abort– Ready: si el registro contiene ready y no contiene abort o precommit.– Precommit: si contiene un precommit y no contiene un abort o un commit– Not ready: si no contiene ni ready ni abort

3. Cada participante manda su estado a Cnew para que este decida.

4. Cnew decide en función de todos los participantes

– si un sitio envía un commit commit– si un sitio envía abort abort– si un sitio envía precommit y nadie envía commit o abort

aplicar el protocolo desde la segunda fase– en cualquier otro estado abort


Sistemas con múltiples bases de datos

Sobre los sistemas de gestión local es preciso añadir sistemas de gestión global del entorno distribuido.

De igual forma se añade una interfaz al más alto nivel para manipular información en sistemas heterogéneos.

Son sistemas con limitaciones pues– los modelos de datos pueden ser diferentes– los protocolos locales de gestión de transacciones

pueden ser incompatibles.– El control de concurrencia puede utilizar técnicas

diferentes.


Ventajas

Se mantiene la inversión existente– hardware– software de sistema– aplicaciones

Autonomía y control administrativo local Permite el uso de DBMS de propósito especial Es una primera aproximación hacia un sistema de gestión

de bases de datos unificado.


Unificación de la visión de datos

Acuerdo en un modelo de datos común Acuerdo en un esquema conceptual común Acuerdo en una representación de datos

compartidos única. Acurerdo en las unidades de medida. Preparación para aceptar transacciones

globales


Gestión de transacciones

Las transacciones locales no se comunican al resto del sistema.

La autonomía local implica que no se comunica directamente con el gestor de transacciones global y estas transacciones no están bajo control.– control de concurrencia local– hay que protegerse contra bloqueos locales– hacen falta mecanismos para asegurar la seriabilidad

global.


Sistema de gestión de fallos

Aparecen nuevas causas de fallo– fallo de un sitio– pérdida de mensajes– fallo en los enlaces de la red– partición de la red

La forma de responder a los fallos es ofrecer el mayor grado de robustez posible

– detectar el fallo– reconfigurar el sistema– recuperarse del error


Reconfiguración del sistema

Si se produce un fallo en el sitio S y Si hay datos replicados en S, eliminar a S de la lista de

actualizaciones. Si había transacciones corriendo S cuando se produce el fallo,

pasan a estado abort.– es importante hacerlo pronto, pues puede haber datos

bloqueados para sitios que están activos. Si S es un servidor central de algún subsistema, se debe elegir

un nuevo servidor– servidor de nombres, coordinador de concurrencia, detector

de bloqueos globales.


Reconfiguración del sistema

La reconfiguración debe soportar particiones de la red, evitando,– la elección de dos o mas servidores centrales en cada

partición.– actualización de datos replicados por mas de una

partición. La reconfiguración se puede representar como una serie de

transacciones– subsistema de control de concurrencia– subsistema de gestión de transacciones

09 de junio 1999bd distribuidas2 arquitecturas de bases de datos n centralizadas – bd en una sola...

Documents