bases de datos distribuidas m. en c. anastacio antolino hernández problema de los sistemas...

M. en C. Anastacio Antolino HernándezM. en C. Anastacio Antolino Hernández

Bases de Datos DistribuidasBases de Datos Distribuidas

PROBLEMA DE LOS SISTEMAS DISTRIBUIDOS

SISTEMAS MANEJADORES DE BASES DE DATOS

DISTRIBUIDAS





• El problema principal es que las redes de comunicación – al menos las de larga distancia o redes de área amplia (WLAN) – son lentas.

• Una Wan típica puede tener una velocidad de datos efectiva cercana a los 5 o 10 mil bytes por segundo.

• Por el contrario, la unidad de disco típica tiene una velocidad de datos cercana a los 5 o 10 millones de bytes por segundo.



• Por consecuencia, un objetivo principal en los sistemas distribuidos es minimizar la utilización de la red.

• Es decir, minimizar la cantidad y el volumen de los mensajes.

• Este objetivo hace a su vez que se presenten problemas en varias áreas complementarias, entre ellas las siguientes:

– Procesamiento de Consultas– Administración del Catálogo– Propagación de la actualización– Control de la Recuperación– Control de la Concurrencia



PROCESAMIENTO DE PROCESAMIENTO DE CONSULTASCONSULTAS



PROCESAMIENTO DE CONSULTAS

• El objetivo de minimizar la utilización de la red implica que el propio Proceso de Optimización de Consultas debe ser distribuido, al igual que el proceso de ejecución de consulta.

• En otras palabras, el proceso de optimización general consistirá típicamente en un paso de optimización global seguido por pasos de optimización local en cada sitio afectado.




DESCOMPOSICION DE CONSULTAS

• En un DDBMS sin transparencia el usuario expresa su consulta en términos de fragmentos específicos. También será responsabilidad del usuario mantener la consistencia.

• Si el DDBMS tiene transparencia el usuario especificará una consulta como si el sistema fuera centralizado.

• En las actualizaciones, la consistencia deberá garantizarla el sistema.




DESCOMPOSICION DE CONSULTAS

• En las consultas, el módulo de descomposición de subconsultas deberá descomponer la consulta en subconsultas que puedan ejecutarse en sitios individuales.

• Además tiene que existir una estrategia de composición de resultados.

• Si el sistema detecta un elemento replicado dentro de una consulta, deberá mantenerlo actualizado tras la ejecución de ésta.




• Supongamos que una consulta C se envía al sitio X, y supongamos que la consulta C involucra la unión de una relación Ry de cien tuplas en el sitio Y con una relación Rz de un millón de tuplas en el sitio Z.

• El optimizador que está en el sitio X seleccionará la estrategia global para la ejecución de C; es claramente necesario que decida mover Ry hacia Z y no Rz hacia Y (por supuesto, tampoco Ry y Rz hacia el sitio X)




• Entonces, una vez que que se ha decido mover Ry hacia Z, la estrategia para ejecutar la unión real en el sitio Z será decida por el optimizador local que está en Z.



Tablas Número de Tuplas

Sitio

Proveedores 10, 000 A

Partes 100, 000 B

Envíos 1, 000, 000 A

• Supongamos que cada tupla almacenada es de 25 bytes (200 bits) de longitud.


• Ejemplo:



SNo Proveedor Status Ciudad

Proveedores

Pno Parte Color Peso Ciudad

Partes

Envíos

SNo PNo Cantidad

Tablas que Componen el SBDD




• Consulta: “Obtener los Números de Proveedores que surten Partes rojas de Londres”.

• Cardinalidad estimada de ciertos resultados intermedios:

– Cantidad de Partes Rojas = 10– Cantidad de envíos de los proveedores de Londres = 100,

000

• Suposiciones de comunicación:– Velocidad de datos = 50, 000 bits/segundo– Retardo en el acceso = 0.1 segundo




• Ahora analicemos brevemente 6 estrategias posibles para el procesamiento de esta consulta, y para cada estrategia calcularemos el tiempo de comunicación total a partir de la fórmula:

(retardo de acceso total) + (volumen total de datos / velocidad de datos)

que se convierte (en segundos)

(cantidad de mensajes / 10) + (cantidad de bits / 50 000)




Primer Estrategia.

• Mover Partes hacia el sitio A y procesar la consulta en A.

T1 = 0.1 + (100 000 * 200) / 50 000

= 400 segs. Aproximadamente (6.67 minutos)




Segunda Estrategia.

• Mover Proveedores y Envíos hacia el sitio B y procesar la consulta en B.

T2 = 0.2 + ((10 000 + 1 000 000) * 200) / 50 000

= 4040 segs. Aproximadamente (1.12 horas)




Tercer Estrategia.

• Juntar Proveedores y Envíos en el sitio A, restringir el resultado a los proveedores de Londres y luego, para cada uno de esos proveedores, revisar el sitio B para ver si la parte correspondiente es roja.

• Cada una de estas revisiones involucrará dos mensajes (una consulta y una respuesta). El tiempo de transmisión para estos mensajes será pequeño en comparación con el retardo del acceso.

T3 = 20 000 segundos aproximadamente (5.56 horas)




Cuarta Estrategia.

• Restringir las Partes en el sitio B a solamente las que sean rojas y luego, para cada una de éstas, revisar el sitio A para ver si existe un envío que relacione la parte con un proveedor de Londres.

• Cada una de estas revisiones involucrará dos mensajes; de nuevo, el tiempo de transmisión de los mensajes será pequeño en comparación con el retardo del acceso.

• T4 = 2 segundos aproximadamente




Quinta Estrategia.

• Juntar Proveedores y Envíos en el sitio A, restringir el resultado a los proveedores de Londres, proyectar el resultado sobre Sno y Pno, y mover el resultado al sitio B. Completar el procesamiento en el sitio B.

T5 = 0.1 + (100 000 * 200) / 50 000

= 400 segundos aproximadamente (6.67 minutos)




Sexta Estrategia.

• Restringir las Partes en el sitio B a las que son Rojas y mover el resultado al sitio A.

• Completar el procesamiento en el sitio A.

T6 = 0.1 + (10 * 200) / 50 000

= 0.1 segundos aproximadamente



Estrategia Técnica Tiempo de comunicación

1 Mover Partes hacia A 6.67 minutos

2 Mover Proveedores y Envíos hacia B

1.12 horas

3 Para cada envío de Londres, revisar si la parte es roja

5.56 horas

4 Para cada parte roja, revisar si existe un proveedor de Londres

2.00 segundos

5 Mover los envíos de Londres hacia B

6.67 minutos

6 Mover las partes rojas hacia A 0.10 segundos (el mejor)

Resumen de las Estrategias y Tiempos




Conclusión:

• Cada una de las seis estrategias representan un enfoque admisible para el problema, pero la variación en el tiempo de comunicación es enorme (la más lenta es dos millones de veces más lenta que la más rápida).




Conclusión:

• La velocidad de datos y el retardo en el acceso son factores importantes para selección de una estrategia.

• Además, algunas estrategias permiten el procesamiento paralelo en los dos sitios; por lo tanto, el tiempo de respuesta ante el usuario puede ser, de hecho, menor que en un sistema centralizado.



ADMINISTRACION DEL ADMINISTRACION DEL CATALOGOCATALOGO



ADMINISTRACION DEL CATALOGO

ACTUALIZACIONES

La información relativa a las réplicas se encuentra en el catálogo:

• Para la fragmentación horizontal se guarda la condición de cada fragmento.

• Para la vertical la lista de atributos de cada fragmento.

• Para la mixta se almacenan ambas informaciones.




• En un sistema distribuido, el Catálogo del Sistema (o Diccionario de Datos) incluirá no solamente los datos usuales del catálogo con relación a la estructura de las tablas, vistas, autorizaciones, etc.

• Sino también toda la información de control necesaria para permitir que el sistema proporcione la independencia de ubicación, fragmentación y replicación necesaria.

• Ahora bien ¿Dónde y cómo debe ser almacenado el propio catálogo?




1. Centralizado.• El catálogo total es almacenado exactamente una

vez en un sitio central.

2. Completamente replicado.• El catálogo total es almacenado por completo en

cada uno de los sitios.

3. Dividido.• Cada sitio mantiene su propio catálogo de los

objetos que están almacenados en ese sitio.– El catálogo total es la unión de todos los catálogos

locales.




4. Combinación de Centralizado y Dividido.

• Cada sitio mantiene su propio catálogo local.

• Además, un único sitio central mantiene una copia unificada de todos esos catálogos locales.




Problemas del Manejo del Catálogo

1. Centralizado.- Viola el objetivo de “no dependencia de un sitio central”.

2. Completamente Replicado.- Sufre una severa pérdida de autonomía, ya que cada actualización del catálogo tiene que ser propagada a cada uno de los sitios.




Problemas del Manejo del Catálogo

3. Dividido.- El enfoque eleva en gran medida el costo de las operaciones que no son locales (para localizar un objeto remoto será necesario acceder, en promedio, a la mitad de los sitios).

4. Centralizado-Dividido.- Este enfoque es más eficiente que el punto 3 (la localización de un objeto remoto requiere sólo un acceso al catálogo remoto), pero viola nuevamente el objetivo de “no dependencia de un sitio central”




• Una forma de manejador el Catálogo del Sistema, para lograr la transparencia de localización, es a través del Mapeo.

• Esto es, primero se distingue el Nombre Común de una relación o tabla, que es nombre por el cual los usuarios hacen normalmente referencia al objeto.

• Y su Nombre a Nivel de Sistema, que es un identificador interno globalmente único para ese objeto.




• Los nombres a nivel de sistema tienen cuatro componentes:

– ID del creador (ID del usuario)– ID del sitio del creador (sitio donde se operó CREATE)– Nombre local (nombre original)– ID del sitio de nacimiento (sitio donde se almacenó

inicialmente)

Por ejemplo: ALBERTO @ MORELIA . CLIENTE @ URUAPAN




ALBERTO @ MORELIA . CLIENTE @ URUAPAN

• Donde se denota la creación de una tabla denominada localmente Cliente.

• Creada por el usuario Alberto desde el sitio de Morelia.

• Y almacenada inicialmente en Uruapan.

Donde se garantiza que este nombre no cambiará, ni aunque el objeto emigre a otro sitio.




• Los usuarios pueden acceder a ella a través de su nombre común o un sinónimo para ese nombre a nivel de sistema.

• Para esto, se realiza un mapeo del nombre común al de nivel de sistema. Por ejemplo (sistema R*):

CREATE SYNONYM MCLIENTE FOR ALBERTO @ MORELIA . CLIENTE @ URUAPAN;




• Ahora la manipulación del elemento se puede realizar de la siguiente manera:

SELECT ... FROM CLIENTE ...;

o

SELECT ... FROM MCLIENTE ...;




• Para acceder a la tabla MCLIENTE, el sistema consulta la Tabla de Sinónimos.

• Donde la tabla de sinónimos puede ser vista como el primer componente del catálogo.

• Cada sitio mantiene un conjunto de esas tablas para los usuarios, y transforma los sinónimos conocidos en los nombres a nivel de sistema correspondiente.




Además, cada sitio mantiene:

• Una entrada de catálogo para cada tabla nacida en ese sitio

• Una entrada de catálogo para cada tabla almacenada actualmente en ese sitio.

bases de datos distribuidas m. en c. anastacio antolino hernández problema de los sistemas...

Documents