Bases de datos distribuidas
Introducción y conceptos básicos
Complicaciones introducidas por
la distribución
 Replicación en un ambiente distribuido
◦ Escoger una de las copias en caso de
recuperación.
◦ Asegurarse que la actualización se refleje en
cada una de las copias.
 Si algún sitio o enlace de comunicación
falla mientras se ejecuta una
actualización, el sistema debe
asegurarse que los efectos se reflejen
en los datos.
 La sincronización de transacciones en
múltiples sitios es más difícil que en los
sistemas centralizados.
CUESTIONES
(PROBLEMAS) DE
DISEÑO
Diseño de bases de datos
distribuida
 ¿Dónde se deben establecer (sitios)
las bases de datos y las aplicaciones
que corren sobre ella?
 Existen dos alternativas para
establecer o posicionar los datos en
un diseño distribuido.
Diseño de bases de datos
distribuidas
 Particionada (no replicada): La base de
datos se divide en un número de
particiones disjuntas las cuales se
posicionan en diferentes sitios.
 Replicada
◦ Completamente replicada (completamente
duplicada): donde la base de datos entera se
almacena en cada sitio.
◦ Parcialmente replicada (parcialmente
duplicada): donde cada partición se
almacena en más de un sitio, pero no en
todos.
Diseño de bases de datos
distribuidas
 Los problemas fundamentales de
diseño son:
◦ Fragmentación: separación de una base
de datos en particiones llamadas
fragmentos.
◦ Distribución: La distribución óptima de los
fragmentos.
Administración del directorio
distribuido
 Metadatos.
 Los problemas relacionados con el
directorio distribuido son muy
similares a los presentados con los
DDBS’s.
Procesamiento de consultas
distribuidas
 Algoritmos que analizan consultas y
las convierten en una serie de
operaciones de manipulación de
datos.
 Elegir estrategias para ejecutar
consultas sobre la red con el mejor
costo-eficiencia.
 Factores: distribución de los datos,
costo de la comunicación, carencia de
suficiente información disponible
Control de concurrencia
distribuido
 Sincronización de accesos a la base de
datos distribuida.
 Además de preocuparse por la
integridad de los datos, debe
preocuparse de la “consistencia mutua”.
 Las clases de soluciones son:
◦ Pesimista: Sincronizar la ejecución de las
peticiones de los usuarios antes de que
comiencen a ejecutarse.
◦ Optimista: Ejecutar las peticiones y después
checar si la ejecución ha comprometido la
consistencia de la base de datos.
Control de concurrencia
distribuido
 Los principios fundamentales que
pueden utilizarse en las clases de
soluciones son:
◦ Bloqueo (locking): Basado en la exclusión
mutua de accesos a objetos de datos.
◦ Sello de tiempo (timestamping): La
ejecución de las transacciones se
ordenan con sellos de tiempo.
Administración de puntos
muertos (deadlocks) distribuidos
 Los usuarios compiten por un
conjunto de recursos (datos en este
caso), lo cual puede resultar en un
deadlock (punto muerto) si el
mecanismo de sincronización está
basado en bloqueo.
Confiabilidad de los DDBS’s
 falla  varios sitios inoperables o
inaccesibles las bases de datos en
los sitios operables  consistentes y
actualizadas
 Sistema se recupera  DDBS se
recupera  DDBS actualiza los sitios
caídos
Replicación
 Réplica: copia de objeto de datos.
 Implementar protocolos que aseguren
la consistencia de las réplicas.
◦ Protocolo “entusiasta”: Fuerzan las
actualizaciones a todas las réplicas antes
que la transacción se complete.
◦ Protocolo “lento”: La transacción actualiza
una copia (maestro) desde donde las
actualizaciones se propagan hacia las
demás copias una vez que se completa la
transacción.
Relación entre los problemas
ARQUITECTURA
Arquitectura de los DDBS’s
 Componentes identificados
 Funciones de los componentes
identificadas
 Relaciones e interacciones entre
componentes definidas
ANSI / SPARC
Arquitectura centralizada
genérica
MODELOS DE
ARQUITECTURA DE
DDBS’S
Los DDBS’s se clasifican sobre 3 características
Modelos de arquitectura de
DDBS’s
Autonomía
 Se refiere a la distribución del control
(no de los datos).
◦ Las operaciones locales no son afectadas
por su participación en el sistema
distribuido.
◦ La manera en que procesa y optimiza
consultas no son afectadas por la
ejecución de consultas globales que
acceden a múltiples bases de datos.
◦ La consistencia de las operaciones o del
sistema no se comprometen cuando se
deja o se une al sistema distribuido.
Autonomía
 Las dimensiones de autonomía son
las siguientes:
◦ Autonomía de diseño: Utilizan modelos de
datos y administración de transacciones
que prefieran.
◦ Autonomía de comunicación: Libre de
decidir que tipo de información desea
compartir con otros DBMS’s o con el
software que controla su ejecución.
◦ Autonomía de ejecución: Puede ejecutar
las transacciones de la manera que
desee.
Autonomía
 Clasificación de autonomía
◦ Integración estrecha (tight integration): Existe
una única imagen de toda la base de datos
que puede ser compartida y encontrarse en
múltiples bases de datos, y un administrador
de datos tomará el control de las peticiones
de todos los usuarios.
◦ Semiautónomo: deciden participar en una
federación para compartir sus datos locales.
◦ Aislamiento total: no conocen la existencia
de otros DBMS’s ni la manera de
comunicarse con ellos.
Distribución (datos)
 Cliente / servidor.
 Punto a punto.
 Sistemas de Bases de datos
múltiples.
Heterogeneidad
La heterogeneidad puede ocurrir
de varias maneras en sistemas
distribuidos, desde la heterogeneidad
del hardware y las diferencias en los
protocolos de redes hasta las
variaciones en las administraciones de
datos.
 Modelos de datos
 Lenguajes de búsqueda
 Protocolos de administración de
transacciones.

2. introducción y conceptos básicos

  • 1.
    Bases de datosdistribuidas Introducción y conceptos básicos
  • 2.
    Complicaciones introducidas por ladistribución  Replicación en un ambiente distribuido ◦ Escoger una de las copias en caso de recuperación. ◦ Asegurarse que la actualización se refleje en cada una de las copias.  Si algún sitio o enlace de comunicación falla mientras se ejecuta una actualización, el sistema debe asegurarse que los efectos se reflejen en los datos.  La sincronización de transacciones en múltiples sitios es más difícil que en los sistemas centralizados.
  • 3.
  • 4.
    Diseño de basesde datos distribuida  ¿Dónde se deben establecer (sitios) las bases de datos y las aplicaciones que corren sobre ella?  Existen dos alternativas para establecer o posicionar los datos en un diseño distribuido.
  • 5.
    Diseño de basesde datos distribuidas  Particionada (no replicada): La base de datos se divide en un número de particiones disjuntas las cuales se posicionan en diferentes sitios.  Replicada ◦ Completamente replicada (completamente duplicada): donde la base de datos entera se almacena en cada sitio. ◦ Parcialmente replicada (parcialmente duplicada): donde cada partición se almacena en más de un sitio, pero no en todos.
  • 6.
    Diseño de basesde datos distribuidas  Los problemas fundamentales de diseño son: ◦ Fragmentación: separación de una base de datos en particiones llamadas fragmentos. ◦ Distribución: La distribución óptima de los fragmentos.
  • 7.
    Administración del directorio distribuido Metadatos.  Los problemas relacionados con el directorio distribuido son muy similares a los presentados con los DDBS’s.
  • 8.
    Procesamiento de consultas distribuidas Algoritmos que analizan consultas y las convierten en una serie de operaciones de manipulación de datos.  Elegir estrategias para ejecutar consultas sobre la red con el mejor costo-eficiencia.  Factores: distribución de los datos, costo de la comunicación, carencia de suficiente información disponible
  • 9.
    Control de concurrencia distribuido Sincronización de accesos a la base de datos distribuida.  Además de preocuparse por la integridad de los datos, debe preocuparse de la “consistencia mutua”.  Las clases de soluciones son: ◦ Pesimista: Sincronizar la ejecución de las peticiones de los usuarios antes de que comiencen a ejecutarse. ◦ Optimista: Ejecutar las peticiones y después checar si la ejecución ha comprometido la consistencia de la base de datos.
  • 10.
    Control de concurrencia distribuido Los principios fundamentales que pueden utilizarse en las clases de soluciones son: ◦ Bloqueo (locking): Basado en la exclusión mutua de accesos a objetos de datos. ◦ Sello de tiempo (timestamping): La ejecución de las transacciones se ordenan con sellos de tiempo.
  • 11.
    Administración de puntos muertos(deadlocks) distribuidos  Los usuarios compiten por un conjunto de recursos (datos en este caso), lo cual puede resultar en un deadlock (punto muerto) si el mecanismo de sincronización está basado en bloqueo.
  • 12.
    Confiabilidad de losDDBS’s  falla  varios sitios inoperables o inaccesibles las bases de datos en los sitios operables  consistentes y actualizadas  Sistema se recupera  DDBS se recupera  DDBS actualiza los sitios caídos
  • 13.
    Replicación  Réplica: copiade objeto de datos.  Implementar protocolos que aseguren la consistencia de las réplicas. ◦ Protocolo “entusiasta”: Fuerzan las actualizaciones a todas las réplicas antes que la transacción se complete. ◦ Protocolo “lento”: La transacción actualiza una copia (maestro) desde donde las actualizaciones se propagan hacia las demás copias una vez que se completa la transacción.
  • 14.
  • 15.
  • 16.
    Arquitectura de losDDBS’s  Componentes identificados  Funciones de los componentes identificadas  Relaciones e interacciones entre componentes definidas
  • 17.
  • 18.
  • 19.
    MODELOS DE ARQUITECTURA DE DDBS’S LosDDBS’s se clasifican sobre 3 características
  • 20.
  • 21.
    Autonomía  Se refierea la distribución del control (no de los datos). ◦ Las operaciones locales no son afectadas por su participación en el sistema distribuido. ◦ La manera en que procesa y optimiza consultas no son afectadas por la ejecución de consultas globales que acceden a múltiples bases de datos. ◦ La consistencia de las operaciones o del sistema no se comprometen cuando se deja o se une al sistema distribuido.
  • 22.
    Autonomía  Las dimensionesde autonomía son las siguientes: ◦ Autonomía de diseño: Utilizan modelos de datos y administración de transacciones que prefieran. ◦ Autonomía de comunicación: Libre de decidir que tipo de información desea compartir con otros DBMS’s o con el software que controla su ejecución. ◦ Autonomía de ejecución: Puede ejecutar las transacciones de la manera que desee.
  • 23.
    Autonomía  Clasificación deautonomía ◦ Integración estrecha (tight integration): Existe una única imagen de toda la base de datos que puede ser compartida y encontrarse en múltiples bases de datos, y un administrador de datos tomará el control de las peticiones de todos los usuarios. ◦ Semiautónomo: deciden participar en una federación para compartir sus datos locales. ◦ Aislamiento total: no conocen la existencia de otros DBMS’s ni la manera de comunicarse con ellos.
  • 24.
    Distribución (datos)  Cliente/ servidor.  Punto a punto.  Sistemas de Bases de datos múltiples.
  • 25.
    Heterogeneidad La heterogeneidad puedeocurrir de varias maneras en sistemas distribuidos, desde la heterogeneidad del hardware y las diferencias en los protocolos de redes hasta las variaciones en las administraciones de datos.  Modelos de datos  Lenguajes de búsqueda  Protocolos de administración de transacciones.

Notas del editor

  • #15 Basado en las explicaciones anteriores, identifique las relaciones entre los diferentes problemas que se presentan.
  • #17 La arquitectura de un sistema define su estructura.
  • #22 Indica el grado en el que los DBMS’s individuales pueden operar de manera independiente. Intercambio de información Ejecutar transacciones de manera independiente Si uno de los DBMS’s puede modificar a los demás
  • #24 Integración estrecha: desde la perspectiva del usuario, los datos están lógicamente integrados en una sola base de datos. Un solo DBMS funciona como administrador de datos. Semiautónomo: cada uno decide que partes de información se van a compartir. No son completamente autónomos porque necesitan modificarse para habilitar el intercambio de información. Aislamiento tota: el procesamiento de las transacciones de usuario se dificulta debido a que no hay control global.
  • #26 Tarea en equipo, exponer sistema cliente/servidor, punto a punto y multibase de datos. Que es el diseño top-down. Tipos de fragmentación.