Bases de Datos Distribuidas

Anuncio
Bases de Datos
Distribuidas
Integrantes:
„ Maria A. Ascanio. M
„ José A. González R.
„ Héctor. E. Cruz F.
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
ANTECEDENTES
Las bases de datos distribuidas ofrecen
diversas ventajas a los diseñadores y usuarios
de bases de datos.
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

Entre las más importantes se encuentra la
transparencia en el acceso y localización de
información.
De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
Sin embargo, el diseño y administración de
bases de datos distribuidas constituye un gran
desafío
que
incorpora
problemas
no
encontrados en bases de datos centralizadas.
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Nombramiento de objetos
1
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
INTRODUCCION
Un área en la cual las soluciones están
integrando tecnología con nuevas arquitecturas
o formas de hacer las cosas es, sin lugar a
dudas, el área de los sistemas distribuidos de
información.
Ellos se refieren al manejo
de datos
almacenados en facilidades de cómputo
localizadas en muchos sitios ligados a través
de una red de comunicaciones. Un caso
específico de estos sistemas distribuidos es lo
que se conoce como bases de datos
distribuidas.
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Nombramiento de objetos
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

BASES DE DATOS DISTRIBUIDAS
Los datos en un sistema de la base de datos
distribuida se almacenan a través de varios
sitios, y cada sitio es manejado típicamente por
un DBMS que pueda funcionar independiente
de los otros sitios.
La vista clásica de un sistema de la base de
datos distribuida debe mostrar los datos
distribuidos de forma transparente, dar la
impresión de que los datos son locales
De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Nombramiento de objetos
2
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
BASES DE DATOS DISTRIBUIDAS
Lo que motiva a la distribución de la data es:
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS

Arquitectura Cliente-Servidor

Arquitectura de Servidores
Incrementa la Disponibilidad
Acceso Distribuido a los Datos
Análisis de los Datos Distribuidos
Autonomía
Cooperantes

De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Nombramiento de objetos
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
TIPOS DE TRANSACCIONES
Hay dos tipos de transacciones:
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


Locales: Es aquella que accede a los datos
del único sitio donde se inició la transacción.
Globales: Es aquella que accede a los
datos situados en uno o mas sitios diferentes
de aquel en que se inició la transacción
Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Nombramiento de objetos
3
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
DESVENTAJAS DE LAS BDs DISTRIBUIDAS
Coste de Desarrollo del Software
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
Mayor Probabilidad de Errores
Mayor Sobrecarga del Procesamiento
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Nombramiento de objetos
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


Arquitectura de Servidores
De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Particularmente,
las
características
siguientes se consideran deseables.
Independencia de datos distribuida
Los usuarios deberían ser capaces de
solicitar queries sin especificar donde están
situadas las relaciones, ya sean sus copias o
fragmentos, a las que hizo referencia.
Arquitectura Cliente-Servidor
Cooperantes

CONDICIONES DESEABLES EN UNA BD
Nombramiento de objetos
Atomicidad
de
una
Transacción
distribuida:
Los usuarios deberían ser capaces de
escribir transacciones que accedan y actualicen
datos en muchos sitios, las mismas tienen que
seguir siendo atómicas, sino llevarían a la BD
distribuida a un estado inconsistente
4
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
ARQUITECTURAS DISTRIBUIDAS DEL DBMS
Arquitectura Cliente-Servidor
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

Posee uno o más procesos clientes y
uno o más procesos servidores, un proceso
cliente puede mandar un query a alguno de los
procesos servidores. Los clientes son
responsables de los aspectos relacionados con
la interface de usuario, mientras que los
servidores manejan los datos y ejecutan las
transacciones.
De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Nombramiento de objetos
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


ARQUITECTURAS DISTRIBUIDAS DEL DBMS
Arquitectura
Cooperantes
de
Servidores
Podemos tener una colección de
servidores de bases de datos, cada uno capaz
de correr transacciones sobre los datos locales,
y cooperativamente sobre datos residentes en
otro servidor.
Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Nombramiento de objetos
5
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
ARQUITECTURAS DISTRIBUIDAS DEL DBMS
De una Vía Centralizada:
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
La idea es que necesitamos solo un
servidor de bases de datos capaz de manejar
queries y transacciones provenientes de
múltiples servidores.
Podemos pensar en este servidor
especial como una capa del software que
coordina
la ejecución de
queries
y
transacciones a través de uno o más servidores
de bases de datos independientes, es
usualmente llamado Middleware.
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Nombramiento de objetos
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
ALMACENAR DATOS EN UN DBMS DISTRIBUIDO
Fragmentación
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

Estos fragmentos contienen suficiente
información
como
para
permitir
la
reconstrucción de la relación original.
De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Consiste en partir la relación en
pequeñas relaciones o fragmentos y almacenar
los fragmentos, posiblemente, en diferentes
sitios.
Nombramiento de objetos
Hay dos esquemas diferentes
fragmentación de las relaciones:.
de
Fragmentación Horizontal
Fragmentación Vertical
6
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
ALMACENAR DATOS EN UN DBMS DISTRIBUIDO
Fragmentación Horizontal y Vertical
TIPOS DE TRANSACCIONES
TID
EID
Nombre
Ciudad
Edad
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
T1
53666
José
Caracas
18
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
T2
53688
Juan
Valencia
18
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS
T3
53650
Carlos
Valencia
19
T4
53831
Manuel
Maracay
11
T5
53832
Teresa
Maracay
12
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS


Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Fragmentación Vertical
Fragmentación Horizontal
Nombramiento de objetos
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Nombramiento de objetos
ALMACENAR DATOS EN UN DBMS DISTRIBUIDO
Replicación
Significa que almacenamos muchas
copias de una relación o de los fragmentos de
la misma. Una relación entera puede estar
replicada en uno o mas sitios, y similarmente,
uno o más fragmentos de una relación.
Ventajas:
ƒ
Evaluación más rápida de los queries
ƒ
Incrementa la disponibilidad de los datos
ƒ
Minimiza el movimiento de los datos entre
los sitios
ƒ
Desventajas
Sobrecarga incrementada durante la
actualización
7
Bases de Datos Distribuidas
Agenda
ANTECEDENTES
INTRODUCCIÓN
BASES DE DATOS DISTRIBUIDAS
TIPOS DE TRANSACCIONES
DESVENTAJAS DE LAS BASES DE
DATOS DISTRIBUÍDAS
CONDICIONES DESEABLES EN
UNA BASE DE DATOS
TIPOS DE BASES DE DATOS
DISTRIBUÍDAS
ARQUITECTURAS DISTRIBUÍDAS
DEL DBMS


Arquitectura Cliente-Servidor
Arquitectura de Servidores
Cooperantes

De una Vía Centralizada
ALMACENAR DATOS EN UN DBMS
DISTRIBUIDO

Fragmentación

Replicación
MANEJO DEL CATÁLOGO
DISTRIBUIDO

Nombramiento de objetos
MANEJO DEL CATÁLOGO DISTRIBUIDO
Nombrando Objetos
Si una relación es fragmentada y replicada, se
debe tener un identificador único por cada réplica de
cada fragmento.
La solución a esto es usar nombres con varios
campos: El 1er. campo sería el nombre local
(asignado localmente en el sitio donde fue creada la
relación), y El 2do. Campo el sitio de origen
(identifica al sitio donde la relación fue creada)
Estos 2 campos identifican únicamente a la
relación y llamamos al conjunto nombre global de
la relación.
Para identificar una réplica o un fragmento de
una relación, usamos el nombre global de la relación
y le añadimos el id réplica (identificador de la
réplica). Se le llama nombre global de la réplica.
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Estructura del Catálogo (describe toda la
data de cada sitio):
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

MANEJO DEL CATÁLOGO DISTRIBUIDO
Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
 Replicación Asincrónica
Un sistema de catálogo centralizado
puede ser vulnerable a fallas ocurridas en el
sitio que lo contiene. Una alternativa es
mantener una copia del mismo en cada sitio,
aunque esto compromete la autonomía del
sitio, ya que cada cambio realizado a dicho
catálogo debe ser propagado a todos los otros
sitios.
Otra solución, que preserva la autonomía
local y no es vulnerable a fallas en un solo sitio,
es que cada sitio mantenga un catálogo local
que describa todas las copias de la data
almacenada en el sitio.
8
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Independencia de la Data Distribuida
Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

MANEJO DEL CATÁLOGO DISTRIBUIDO
Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
Significa que el usuario debería ser capaz
de escribir un query sin importarle como la
relación esta fragmentada o replicada, es decir,
esto debe ser “transparente” al usuario.
En realidad es responsabilidad del DBMS
procesar la relación como se necesite,
(localizando
copias
convenientes
de
fragmentos, ensamblando los fragmentos
verticales, y tomando la unión de fragmentos
horizontales)
 Replicación Asincrónica
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Procesamiento en Query Distribuido
Consideremos las siguientes relaciones:
Marinero (mid, mnombre, promedio, edad)
Reservación: (mid, bid, día, rnombre)
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
 Replicación Asincrónica
Usaremos lo anterior, para estimar el costo de
una estrategia de evaluación, mas el numero de
I/O’s de página, también debemos contar el número
de páginas mandadas de un sitio a otro, ya que la
comunicación implica un costo significativo del costo
total en un sistema de BD distribuida. Añadiremos el
costo de trasladar las tuplas resultantes del sitio
donde se realizó el Query al sitio donde se
ensamblará el resultado total.
9
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Procesamiento en Query Distribuido
Se asumirá la siguiente notación:
Td: Tiempo que toma leer una página del disco.
Ts: Tiempo que toma trasladar una pagina.
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
 Replicación Asincrónica
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
Queries Nonjoin en un DBMS Distribuido
Incluso simples operaciones como búsqueda,
selección, y proyección en una relación, son
afectadas por la fragmentación y duplicación.
Consideremos el siguiente Query:
SELECT S.edad
FROM Marinero S
WHERE S.promedio > 3 and S.promedio < 7
Suponiendo que la relación marinero esta
fragmentada horizontalmente, con todas las tuplas
< 5 en Shangai, y todas las tuplas >= 5 en Tokio.
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
 Replicación Asincrónica
10
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Queries Nonjoin en un DBMS Distribuido
El DBMS debe responder este Query evaluando
en ambos sitios y tomando la unión de las
respuestas. Si la clausula SELECT contuvo el AVG
(S.edad), la combinación, de las respuestas no
puede hacerse con un simple join. El DBMS debe
calcular la cuenta y suma de los valores de las
edades en los dos sitios y usar esta información
para calcular la edad promedio de todos los
marineros.
Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
Por otra parte, si la cláusula WHERE contenía
solo la condición S.promedio > 6, por la otra parte, el
DBMS debe reconocer que este Query puede ser
respondido ejecutándolo solamente en Tokio.
 Replicación Asincrónica
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Joins en una DBMS Distribuida
Los Joins de Relaciones almacenadas en
diferentes sitios pueden ser muy costosos. Ahora
supondremos que la relación Marinero fue
almacenada en Londres y Reservación en Paris.
Consideraremos varias maneras para resolver:
Marinero
Reservación
Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
 Replicación Asincrónica
11
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Leer lo Necesario
La idea principal, es traer las páginas necesarias
y almacenarlas en la cache, para terminar de
procesarlas. Podemos hacer un Page-oriented
nested loops join en Londres con marinero como la
más externa, y por cada página de marinero, y leer
todas las páginas de Reservación de Paris. Si
almacenamos las páginas leídas de Reservación en
Londres hasta que el join este completo, estas son
leídas una sola vez.
Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
 Replicación Asincrónica
Ahora,
supondremos que las páginas de
Reservación no pueden ser almacenadas en un
cache:
El costo es 500td para scan Marinero + (por cada
página de Marinero) el costo del canning y envio de
todas las de Reservación, el cual es de 1000 (td+
ts). Por lo tanto el costo total sería: 500td +
500.000(td +ts).
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
Leer lo Necesario
Además, si el query no fue hecho desde el sitio
en Londres, debemos añadir el costo del envío del
resultado al sitio donde se realizó la consulta, lo que
depende del tamaño del resultado. Debido a que
mid es una clave para Marinero, el número de tuplas
en el resultado es 100.000 (# tuplas n Reservación)
y cada tupla tiene una longitud de 40 + 50 = 90
bytes, entonces hay 4000/90 = 44 tuplas por página
en el resultado, el tamaño total de éste es de
100.000/44 = 2273 páginas.
El costo de enviar la respuesta a otro sitio es de
2273ts. En el caso anterior (el sitio del
query no es ni Londres ni Paris), sería más barato
si trasladáramos ambas relaciones al sitio del query
y ejecutáramos el join allí.
 Replicación Asincrónica
12
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Envió a un sitio
Consiste en enviar, completamente, una de las 2
relaciones al sitio donde se encuentra la otra y luego
ejecutar allí el query. Podríamos trasladar la relación
Marinero de Londres a Paris y ejecutar luego el join
allá, o en lugar de mover Marinero, trasladar
Reservación a Londres y realizar el join en Londres;
otra opción sería trasladar ambas (Marinero y
Reservación) al sitio donde se realizó el query y
procesar el join en él.
Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
El costo del scanning, el envío de Marinero,
guardando la relación Marinero en Paris y
asumiendo un sort-merge join, y la ejecución del join
en Paris es de: 500(2td + ts).
 Replicación Asincrónica
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

SEMIJOINS Y BLOOMJOINS
Suponiendo que se envío Reservación a Londres
y se ejecutó el join allí. Algunas tuplas de
Reservación no harían join con ninguna tupla de
Marinero. Si de alguna manera identificamos las
tuplas de Reservación que seguramente no van a
hacer join con ninguna de Marinero, entonces
podríamos evitar enviarlas. Estas dos técnicas
proponen reducir el número de tuplas a ser
trasladadas
Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
 Replicación Asincrónica
13
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
 Replicación Asincrónica
Semijoins
La idea es seguir los siguientes tres pasos:
1) En Londres, computar la proyección de Marinero en
el join por columnas (en este caso solo el campo mid) y
trasladarla a Paris.
2) En Paris, realizar el join natural de la
proyección
recibida desde el primer sitio con la relación
Reservación. El resultado de este join es llamado la
reducción de Reservación con respecto a Marinero.
Solo aquella tuplas en la reducción harán join con
las tuplas en la relación Marinero. Trasladar la
reducción de Reservación a Londres es preferible
antes que la relación completa.
3) En Londres, calcular el join de la reducción de
Reservación con Marinero.
El semijoin es especialmente útil en conjunción con
una selección aplicada a una de las relaciones.
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
Bloomjoins
Es muy similar a la técnica de Semijoin, solo que
usa un vector de bits conjuntamente con hash. En el
1er. paso no se envía la proyección de Marinero sino
un vector de bits. Un vector de bits de tamaño k es
procesado aplicando hashing a cada tupla de
Marinero en un rango de 0 a (k - 1), colocando el bit i
a 1 algunas tupla hashes con i, y 0 de lo contrario.
En el 2do. paso, la reducción de Reservación es
procesada mediante el hashing de cada tupla de
Reservación (usando el campo mid) en un rango de 0
– (k-1) usando la misma función de hash empleada
para construir el vector de bits y desechando las
tuplas cuyo valor de i corresponda a un bit 0. El costo
de aplicar esta técnica aplicada a Reservación es
menor que el correspondiente a la de Semijoins; por
otra parte, el tamaño de la reducción de Reservación
tiende a ser más grande y el costo del envío de la
reducción y de hacer el join con Marinero es mayor.
 Replicación Asincrónica
14
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
Optimización Basada en Costos
Hemos visto como la distribución de datos
pueden afectar la implementación de operaciones
individuales, como una selección, adición, etc. En
general, un query involucra severas operaciones, y
la optimización de esta en una BD distribuida nos
trae los siguientes retos:
*El costo de la comunicación debe ser
considerado. Si tenemos muchas copias de una
relación, debemos decidir cual copia usar.
*Si cada sitio corre individualmente bajo el
control de diferentes DBMS, la autonomía de cada
sitio debe ser respetada cuando se hacen planes
de queries globales.
La optimización de queries se hace
básicamente como en las BD Centralizadas, claro
que hay nuevos métodos para las operaciones (por
ejemplo: joins distribuidos).
 Replicación Asincrónica
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

ACTUALIZACIÓN DE LA DATA DISTRIBUIDA
En relación a las actualizaciones, igualmente las
transacciones deben continuar siendo atómicas, sin
importar que la data este fragmentada o replicada.
Hay dos maneras de actualizar las copias de una
relación modificada:
- Replicación sincrónica.
- Replicación asincrónica.
Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
 Replicación Asincrónica
15
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Replicación sincrónica
Es cuando todas las copias de la relación
modificada son actualizadas antes que la
transacción que las modificó haga commit. Aquí se
aplican 2 técnicas:
- Voting (votando): Una transacción debe escribir
la mayoría de las copias para modificar un objeto y
leer al menos suficientes copias para asegurarse
que esa copia está presente.
Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
Esta técnica no es muy recomendada ya que en
la mayoría de los casos leer un objeto
requiere leer múltiples copias, y en muchas
aplicaciones, los objetos son leídos con más
frecuencia que actualizados, es así la eficiencia
en cuanto a lectura muy importante.
 Replicación Asincrónica
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
Replicación sincrónica
- Read-any write-all (Leer cualquiera, escribir
todas): Para leer un objeto, una transacción puede
leer cualquier copia, pero para escribir un objeto,
ésta debe escribir todas las copias. Las lecturas
son rápidas, especialmente si tenemos una copia
local, pero escribir se vuelve muy lento, en relación
con la técnica Voting.
Esta técnica (read-any write-all) recomendada
cuando las lecturas son más frecuentes que las
escrituras, y es la más usada a la hora de
implementar la replicación síncrona.
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
 Replicación Asincrónica
16
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
Replicación Asincrónica
Es la más ampliamente usada a nivel comercial
en los DBMSs. Aquí las copias de una relación
modificada son actualizadas solo periódicamente y
una transacción que lea diferentes copias de la
misma relación puede leer diferentes valores. Este
tipo de replicación compromete la independencia de
la data distribuida.
La replicación asíncrona trae consigo un costo
significativo. Antes que una transacción de
actualización pueda hacer commit, esta debe
obtener los locks sobre todas las copias –
asumiendo el uso de la técnica read-any write-all de la data modificada. La transacción puede haber
mandado solicitudes de lock a sitios remotos y
esperar por los locks, pero durante este periodo ella
mantiene sus otros locks.
 Replicación Asincrónica
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Replicación Asincrónica
Si el sitio o el enlace de comunicación fallan, la
transacción no puede hacer commit hasta que
todos los sitios a los cuales les ha modificado la
data se recuperen. Por todo esto, la replicación
asíncrona no es deseable e inclusive inalcanzable
en muchas situaciones. El hecho de mantener
copias con distintitos valores de una misma relación
ocasiona la inconsistencia de los datos.
Este tipo de replicación tiene dos formas:
Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
- De Sitio Primario: Una copia de la relación es
designada como copia maestra o primaria. Las
réplicas o los fragmentos de la relación completa
pueden ser creados en otros sitios; estas serían
copias secundarias, y a diferencia de la copia
primaria; pueden no ser actualizadas.
 Replicación Asincrónica
17
Bases de Datos Distribuidas
Agenda
MANEJO DEL CATÁLOGO
DISTRIBUIDO


Estructura Del Catálogo
Independencia De
Datos Distribuida
PROCESAMIENTO EN QUERY
DISTRIBUIDO
QUERIES NONJOIN EN UN DBMS
DISTRIBUIDO
JOINS EN UNA DBMS DISTRIBUIDA
 Leer lo Necesario

Envió a un sitio
SEMIJOINS Y BLOOMJOINS

Semijoins

Bloomjoins
¾ OPTIMIZACIÓN BASADA EN
COSTOS
¾ ACTUALIZACIÓN DE LA DATA
DISTRIBUIDA
 Replicación sincrónica
Replicación Asincrónica
Un mecanismo común para establecer las copias
primaria y secundaria es que los usuarios primero
registran la relación en el sitio primario y
subsecuentemente suscriben
Un fragmento de la relación registrada en otro
(secundario) sitio.
- Par a Par: Más de una copia (aunque no todas)
puede ser designada como actualizables, esta es
una copia maestra. Además para propagar los
cambios,
Una resolución de conflicto puede ser usada para
lidiar con el hecho de hacer el cambio en los
diferentes sitios. Esta es la más utilizada.
 Replicación Asincrónica
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
TRANSACCIÓN DISTRIBUIDA
Las transacciones realizadas en bases de
datos distribuidas puede acceder a otros sitios,
los cuales se les llama subtransacciones.
Cuando una transacción es remitida de un
lugar, el manejador de transacciones de ese
lugar divide la transacción en colecciones de
subtransacciones para ejecutar en diferentes
lugares, que se ejecutara en sus respectivos
manejadores de transacciones.
18
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
CONTROL DE CONCURRENCIA
DISTRIBUIDA
El protocolo de control de concurrencia es el
encargado
de
determinar
que
objeto
almacenado utilizara un lock.
Para un ambiente distribuido existen varias
técnicas para escoger dicho objeto y la elección
de una de estas técnicas determinara la forma
de administrar los locks.
Las técnicas a tratar son:
•Centralizado
•Copia Primaria
•Totalmente Distribuido
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
CONTROL DE CONCURRENCIA
DISTRIBUIDA
Centralizado:
Cada sitio esta encargado de manejar los
locks para todos los objetos que lo soliciten.
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
19
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
CONTROL DE CONCURRENCIA
DISTRIBUIDA
Copia Primaria:
Una copia de cada objeto es designada
como copia primaria. Todas las peticiones de
locks y unlocks sobre una copia de este objeto
son procesadas por el manejador de lock en el
sitio donde la copia primaria está almacenada,
sin importar donde la copia particular solicitada
esté guardada.
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
Totalmente Distribuido
Las peticiones de locks y unlocks sobre una
copia de un objeto almacenado en un sitio son
manejadas por el manejador de lock del mismo.
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
20
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
CONTROL DE CONCURRENCIA
DISTRIBUIDA
Interbloqueos Distribuidos
Uno de los aspectos que requieren atención
es la detección de interbloqueos al usar locking
en copia primaria y totalmente distribuido.
A diferencia de la técnica centralizada, la
copia primaria y el totalmente distribuido no
necesariamente se puede detectar un
interbloqueo con el grafo de espera local, hay
que revisar los grafos de espera global.
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
CONTROL DE CONCURRENCIA
DISTRIBUIDA
Por ejemplo supóngase que 2 sitios, A y B,
ambos contienen copias de los objetos O1 y
O2, y que la técnica usada es read-any writeall. Tenemos las transacciones: T1 en A (quiere
leer O1 y escribir O2) y T2 en B (quiere leer O2
y escribir O1):
T1:
T2:
T1
T2
Begin
Begin
S-lock O1 at sitio A
S-lock O2 at sitio B
global
X-lock O2 at sitioEspera
A
X-lock O1 at sitio B
X-lock O2 at sitio B
X-lock O1 at sitio A
T1
T2
En el lugar A
T1
T2
En el lugar B
21
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
CONTROL DE CONCURRENCIA
DISTRIBUIDA
Para detectar este caso, existen tres
algoritmos para detección de interbloqueos
distribuidos:
• Centralizado: envía periódicamente todos
los grafos de espera locales de cada sitio a un
lugar designado para la detección de
interbloqueos, y allí el algoritmo realiza una
unión de todos los grafos locales recibidos
formando un grafo de espera global en el que
detecta interbloqueos.
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
CONTROL DE CONCURRENCIA
DISTRIBUIDA
• Jerárquico: este algoritmo es orientado a
BDD a nivel de países, en el que los sitios se
forman en grupos por estados, y luego por
país y finalmente por un grupo que tenga
todos los grupos. Cada nodo realiza un grafo
que revela los interbloqueos locales, y cada
uno de estos envían periódicamente dichos
grafos al lugar encargado de hacer el grafo
estadal y así ver los interbloqueos estadales.
Luego estos envían periódicamente ese grafo
al lugar donde se encarga de hacer los grafos
por país que a su vez hacen un grafo y lo
envían al sitio que finalmente realiza el grafo
de espera global.
22
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
CONTROL DE CONCURRENCIA
DISTRIBUIDA
Y el último algoritmo es el más simple:
aborta toda transacción que su tiempo de
ejecución sobrepase un tiempo estipulado
llamado time-out. Este tiene el problema que si
se escoge mal el time-out ocurrirán muchos
reinicios innecesarios.
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
RECUPERACIÓN DISTRIBUIDA
La recuperación de fallas en un DDBMS es
mas complicado que las de un DBMS por:
• Aparecen nuevas clases de fallas: una
falla de comunicación y la falla de algún sitio
que
se
encontraba
ejecutando
una
subtransacción.
• O todas las transacciones llegan al commit
o no lo hacen, sin importar fallas de
comunicación o de la localización de un sitio.
Esto es garantizado al usar un protocolo de
commit.
23
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
RECUPERACIÓN DISTRIBUIDA
Ejecución Normal y Protocolos de Commit:
Durante la ejecución normal cada sitio
mantiene su log, y las acciones de las
subtransacciones son logged en el sitio donde
son ejecutadas. El manejador de transacciones
en el sitio donde ésta se originó es llamado el
coordinador para la
transacción, los
manejadores de transacciones en los sitios
donde las subtransacciones se ejecutan son
llamados subordinados (con respecto al
coordinador de esa transacción).
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
RECUPERACIÓN DISTRIBUIDA
Protocolo de Dos Fases: Cuando el usuario
decide hacer commit en una transacción, el
comando de commit es mandado al
coordinador para la transacción. Los pasos son
los siguientes:
1. El coordinador manda un
prepárense a cada subordinado.
mensaje
2. Cuando el subordinado recibe el mensaje
prepárense, decide si abortar o hacer commit
en su subtransacción. Él fuerza la escritura de
un abort o preparado en el log, y luego manda
un mensaje de si o no al coordinador.
24
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
RECUPERACIÓN DISTRIBUIDA
3. Si el coordinador recibe un mensaje de si
de todos los subordinados, fuerza la escritura
del commit en los registros del log y luego
manda un mensaje de commit a todos los
subordinados. Caso contrario o algunos de
los subordinados no responde en intervalo de
tiempo específico, fuerza la escritura de abort
en el log, y manda un mensaje de aborten a
los subordinados.
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
RECUPERACIÓN DISTRIBUIDA
4. Cuando un subordinado abort este fuerza
la escritura de abort en el log, y manda un
mensaje de ack al coordinador, y aborta la
subtransacción. Cuando un subordinado
commit fuerza la escritura de commit al log, y
manda un mensaje de ack al coordinador,
luego hace commit con su transacción.
5. Finalmente el coordinador recibe todos
los ack de sus subordinados y escribe en el
log end para la transacción.
25
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
RECUPERACIÓN DISTRIBUIDA
Reinicio luego de una falla: Al momento de
hacer una recuperación se aplican los
siguientes pasos:
*Si tenemos un commit o un abort de la
transacción T, limpiamos la transacción,
aplicamos REDO o UNDO (según el caso).
Si este sitio es el coordinador, el cual puede
determinar los commits y los aborts a partir del
log, debemos periódicamente reenviar un
commit o un abort a cada subordinado hasta
que recibamos un ack. Después de recibidos
los acks de todos los subordinados, se escribe
un end en el log para T.
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
RECUPERACIÓN DISTRIBUIDA
*Si nos preparamos para escribir en log para
la transacción T, pero esta no a enviado ni
commit ni un abort; entonces este sitio es
subordinado, y el coordinador puede estar
determinado para preparado para grabar en el
log. Debemos repetidamente contactar al
coordinador del sitio y determinar el estatus de
T. Una vez que el coordinador responda con
cualquiera de las dos commit o abort,
escribimos el correspondiente registro log,
aplicamos REDO o UNDO (según sea el caso)
y escribimos end de la transacción en el log.
26
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
RECUPERACIÓN DISTRIBUIDA
*Si no nos preparamos, escribimos un
commit o un abort en el registro del log para la
transacción T; seguramente T no había hecho
commit antes de la falla, entonces podemos
abortar unilateralmente y deshacemos (UNDO)
T y escribir un end en el registro log. En este
caso no tenemos manera de determinar si el
presente sitio es coordinador o subordinado
para T. Sin embargo, si el sitio coordinador
para una transacción T falla, los subordinados
que votaron si no pueden decidir si hacen
commit o abort a T hasta que el coordinador se
recupere; decimos
entonces que T está
bloqueada.
Bases de Datos Distribuidas
Agenda
TRANSACCIÓN DISTRIBUIDA
CONTROL DE CONCURRENCIA
DISTRIBUIDA
 Centralizado
 Copia Primaria
 Totalmente Distribuido
 Interbloqueos Distribuidos
RECUPERACIÓN DISTRIBUIDA
 Ejecución Normal y Protocolos
Comprometidos (Commit)

Protocolo de Dos Fases

Reinicio luego de una falla

Protocolo de Tres Fases
RECUPERACIÓN DISTRIBUIDA
Es una mejora al protocolo de 2 fases. La
idea básica es que, cuando el coordinador
mande el mensaje prepárense y reciba el
mensaje de si de todos los subordinados,
manda a todos los sitios un mensaje de
precommit. Cuando un número suficiente de
acks han sido recibidos, se hace commit en el
registro log y manda un mensaje de commit a
todos los subordinados. Este protocolo impone
un costo adicional durante la ejecución normal
y requiere que las fallas en los enlaces de
comunicación no conlleven a la partición de la
red, para asegurar estar libre de bloqueos. Por
esta razón no se usa en la práctica.
27
Descargar