PROBLEMA DE LOS SISTEMAS DISTRIBUIDOS

1. PROBLEMA DE LOS SISTEMAS DISTRIBUIDOS SISTEMAS MANEJADORES DE BASES DE DATOS DISTRIBUIDAS

2. 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. M. en C. Anastacio Antolino Hernández

3. 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

4. PROCESAMIENTO DE CONSULTAS

5. 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.

6. PROCESAMIENTO DE CONSULTAS 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.

7. PROCESAMIENTO DE CONSULTAS 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.

8. PROCESAMIENTO DE CONSULTAS • 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)

9. PROCESAMIENTO DE CONSULTAS • 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.

10. PROCESAMIENTO DE CONSULTAS • Ejemplo: • Supongamos que cada tupla almacenada es de 25 bytes (200 bits) de longitud.

11. Tablas que Componen el SBDD Proveedores Partes Envíos

12. PROCESAMIENTO DE CONSULTAS • 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

13. PROCESAMIENTO DE CONSULTAS • 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)

14. PROCESAMIENTO DE CONSULTAS 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)

15. PROCESAMIENTO DE CONSULTAS 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)

16. PROCESAMIENTO DE CONSULTAS 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)

17. PROCESAMIENTO DE CONSULTAS 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

18. PROCESAMIENTO DE CONSULTAS 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)

19. PROCESAMIENTO DE CONSULTAS 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

20. Resumen de las Estrategias y Tiempos

21. PROCESAMIENTO DE CONSULTAS 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).

22. PROCESAMIENTO DE CONSULTAS 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.

23. ADMINISTRACION DEL CATALOGO

24. 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.

25. ADMINISTRACION DEL CATALOGO • 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?

26. ADMINISTRACION DEL CATALOGO 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.

27. ADMINISTRACION DEL CATALOGO 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.

28. ADMINISTRACION DEL CATALOGO Problemas del Manejo del Catálogo • Centralizado.- Viola el objetivo de “no dependencia de un sitio central”. • 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.

29. ADMINISTRACION DEL CATALOGO Problemas del Manejo del Catálogo • 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). • 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”

30. ADMINISTRACION DEL CATALOGO • 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.

31. ADMINISTRACION DEL CATALOGO • 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

32. ADMINISTRACION DEL CATALOGO 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.

33. ADMINISTRACION DEL CATALOGO • 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;

34. ADMINISTRACION DEL CATALOGO • Ahora la manipulación del elemento se puede realizar de la siguiente manera: SELECT ... FROM CLIENTE ...; o SELECT ... FROM MCLIENTE ...;

35. ADMINISTRACION DEL CATALOGO • 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.

36. ADMINISTRACION DEL CATALOGO 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.