Traducido del inglés al español - www.onlinedoctranslator.

com

BASES DE DATOS DISTRIBUIDAS

M. Tamer Özsu
Universidad de Alberta

Una base de datos distribuida (DDB) es una colección de múltiples bases de datos lógicamente interrelacionadas distribuidas a través de
una red informática. Un sistema de gestión de bases de datos distribuidas (DBMS distribuido) es el sistema de software que permite la
gestión de la base de datos distribuida y hace que la distribución sea transparente para los usuarios [1]. El término sistema de base de
datos distribuida (DDBS) se usa típicamente para referirse a la combinación de DDB y DBMS distribuido. Repartido
Los DBMS son similares a los sistemas de archivos distribuidos (ver Sistemas de archivos distribuidos) en el sentido de que ambos facilitan el acceso a los
datos distribuidos. Sin embargo, existen diferencias importantes en la estructura y la funcionalidad, y estas caracterizan a un sistema de base de datos
distribuido:

1. Los sistemas de archivos distribuidos simplemente permiten a los usuarios acceder a archivos que se encuentran en equipos distintos a los
suyos. Estos archivos no tienen una estructura explícita (es decir, son planos) y las relaciones entre los datos en diferentes archivos (si las
hay) no son administradas por el sistema y son responsabilidad de los usuarios. Un DDB, por otro lado, está organizado
de acuerdo a una esquema que define tanto la estructura de los datos distribuidos como las relaciones entre los datos.
El esquema se define de acuerdo con algún modelo de datos, que suele ser relacional u orientado a objetos (ver
Esquemas de bases de datos distribuidas).

2. Un sistema de archivos distribuido proporciona una interfaz simple a los usuarios que les permite abrir, leer / escribir (registros o bytes) y
cerrar archivos. Un sistema DBMS distribuido tiene la funcionalidad completa de un DBMS. Proporciona capacidad de consulta declarativa
de alto nivel, gestión de transacciones (tanto control de simultaneidad como recuperación) y cumplimiento de la integridad. En este sentido,
los DBMS distribuidos también son diferentes de los sistemas de procesamiento de transacciones, ya que estos últimos proporcionan solo
algunas de estas funciones.

3. Un DBMS distribuido proporciona transparente acceso a los datos, mientras que en un sistema de archivos distribuido el usuario tiene que saber

(hasta cierto punto) la ubicación de los datos. Una DDB puede estar particionada (llamadafragmentación) y replicado
además de distribuirse en varios sitios. Todo esto no es visible para los usuarios. En este sentido, el distribuido
La tecnología de base de datos amplía el concepto de independencia de datos, que es una noción central de la gestión de bases de
datos, a entornos donde los datos se distribuyen y replican en varias máquinas conectadas por una red. Por lo tanto, desde la
perspectiva de un usuario, una DDB es lógicamente una base de datos única, incluso si está distribuida físicamente.

Alternativas arquitectónicas

Arquitectónicamente, un sistema de base de datos distribuida consta de un conjunto (posiblemente vacío) de sitios de consulta y un conjunto no vacío de

sitios de datos. Los sitios de datos tienen capacidad de almacenamiento de datos, mientras que los sitios de consulta no. Este último solo ejecuta la interfaz
de usuario (además de las aplicaciones) para facilitar el acceso a los datos en los sitios de datos (Figura 1).

Sitio 1

Sitio 2
Sitio 5

Comunicación
La red

Sitio 4 Sitio 3

Figura 1. Entorno de base de datos distribuida

Si los sistemas de bases de datos distribuidas en varios sitios son autónomos y (posiblemente) exhiben alguna forma de heterogeneidad, se
denominan sistemas de bases de datos múltiples (ver Sistemas de bases de datos múltiples) o sistemas de bases de datos federadas
(ver Sistemas de bases de datos federadas). Si la distribución de la funcionalidad de datos y DBMS se realiza en un
computadora multiprocesador, entonces se conoce como un sistema de base de datos paralelo (ver Bases de datos paralelas). Estos son
diferentes a un sistema de base de datos distribuida donde la integración lógica entre los datos distribuidos es más estricta que en el caso de los
sistemas de bases de datos múltiples o los sistemas de bases de datos federadas, pero el control físico es más flexible que en paralelo.
DBMS.
Hay varios modelos arquitectónicos diferentes para el desarrollo de un DBMS distribuido, que van desde
sistemas cliente / servidor [2], donde los sitios de consulta corresponden a clientes mientras que los sitios de datos corresponden a
servidores (ver Computación cliente-servidor), a un sistema peer-to-peer donde no se hace distinción entre las máquinas cliente y el
servidor máquinas. Estas arquitecturas difieren con respecto a la ubicación donde se proporciona cada función de DBMS.

En el caso de los DBMS cliente / servidor, el servidor realiza la mayor parte del trabajo de gestión de datos. Esto significa que todo el
procesamiento y la optimización de consultas, la gestión de transacciones y la gestión del almacenamiento se realiza en el servidor. El cliente, en
Además de la aplicación y la interfaz de usuario, tiene un Cliente DBMS módulo que es responsable de administrar los datos que se almacenan en
caché en el cliente y (a veces) administrar los bloqueos de transacciones que también se pueden haber almacenado en caché. En la Figura 2 se
muestra una distribución funcional típica de cliente / servidor.

Usuario Solicitud
Interfaz Programa
Operando
Sistema

DBMS del cliente

Software de comunicación

SQL Resultado
consultas relación

O Software de comunicación
pag
mi
Responsable del tratamiento de datos semánticos

r Optimizador de consultas
a
Gerente de transacciones
t
I Gestor de recuperación
norte

Procesador de soporte en tiempo de ejecución

gramo

Sistema

Base de datos

Figura 2. Arquitectura cliente / servidor

La arquitectura cliente / servidor más simple es una múltiples clientes / un solo servidor sistema. Desde la perspectiva de la administración de
datos, esto no es muy diferente de las bases de datos centralizadas, ya que la base de datos se almacena en una sola máquina (el servidor) que
también aloja el software para administrarla. Sin embargo, existen algunas diferencias importantes con los sistemas centralizados en la forma en
que se ejecutan las transacciones y se administran las cachés. Una arquitectura cliente / servidor más sofisticada es
uno donde hay varios servicios en el sistema (el llamado múltiples clientes / múltiples servidores Acercarse). En este caso, son
posibles dos estrategias de gestión alternativas: o cada cliente DBMS gestiona su propia conexión al servidor apropiado o cada
cliente conoce solo su servidor de origen, que luego se comunica con otros servidores según sea necesario. El primer enfoque
simplifica el código del servidor, pero carga las máquinas cliente con responsabilidades adicionales (cliente pesado) mientras
que el segundo enfoque concentra la funcionalidad de gestión de datos en los servidores y proporciona transparencia de
acceso a los datos en la interfaz del servidor (cliente derecho).
 USUARIO

Sistema Usuario
respuestas peticiones

USUARIO
PROCESADOR Interfaz de usuario
Externo
Manipulador
Esquema

Datos semánticos
Controlador Global
Conceptual
Esquema
Consulta global
Optimizador

GD / D
Ejecución global
Monitor

DATOS Local
Local
PROCESADOR Conceptual
Procesador de consultas
Esquema

Local Sistema
Gestor de recuperación Tronco

Soporte de tiempo de ejecución Interno local

Procesador Esquema

Figura 3. Funcionalidad de DBMS distribuido de igual a igual

En el caso de los sistemas de igual a igual, no hay distinción entre clientes y servidores y cada sitio del sistema puede realizar la misma
funcionalidad. Aún es posible separar los módulos que atienden las solicitudes de los usuarios de otros que administran datos (ver
Figura 3), pero esto es solo una separación lógica y no implica ninguna distribución de funcionalidad. Al ejecutar consultas
(transacciones), es posible que el optimizador de consultas global (monitor de ejecución global) se comunique directamente con los
procesadores de consultas locales (gestores de recuperación locales) donde se ejecutan partes de la consulta (transacción). Por lo tanto,
el mecanismo de comunicación está más involucrado, lo que lleva a estructuras de software más complicadas.

Problemas técnicos

Como se indicó anteriormente, los DBMS distribuidos brindan la misma funcionalidad que sus contrapartes centralizadas. Por lo tanto, surgen
los mismos problemas técnicos, aunque en un contexto distribuido. La distribución también aumenta las dificultades para abordar estos
problemas debido a la fragmentación / replicación / distribución de datos, la falta de conocimiento instantáneo sobre lo que está sucediendo
en otro sitio y la dificultad general de administrar un entorno distribuido.
Procesamiento y optimización de consultas

El procesamiento de consultas es el proceso mediante el cual una consulta declarativa se traduce en operaciones de manipulación de datos de bajo nivel.
SQL [3] es el lenguaje de consulta estándar que se admite en los DBMS actuales. La optimización de consultas se refiere al proceso mediante el cual se
encuentra la mejor estrategia de ejecución para una consulta determinada entre un conjunto de alternativas.

En los DBMS centralizados, el proceso generalmente implica dos pasos: descomposición de consultas y optimización de consultas. La
descomposición de consultas toma una consulta SQL y la traduce a una expresada en álgebra relacional. En el proceso, la consulta se
analiza semánticamente para que las consultas incorrectas se detecten y rechacen con la mayor facilidad posible y se simplifiquen las
consultas correctas. Para una consulta SQL determinada, hay más de una consulta algebraica posible, algunas de las cuales son mejores
que otras, según se define en términos de rendimiento de ejecución esperado. Encontrar la mejor entre las alternativas es el proceso
de optimización de consultas y requiere considerar la organización física de los datos (es decir, la disponibilidad de índices y estructuras
hash).

En procesamiento / optimización de consultas distribuidas (ver Procesamiento de consultas distribuidas), el objetivo es asegurar que la consulta
del usuario, que se plantea como si la base de datos estuviera centralizada (es decir, integrada lógicamente), se ejecute correcta y eficientemente
sobre los datos que se distribuyen. Por lo tanto, hay dos pasos más involucrados entre la descomposición de la consulta y la consulta.
optimización: localización de datos y optimización de consultas globales. La localización de datos toma la consulta algebraica que se obtiene como
resultado de la descomposición de la consulta y localiza los datos de la consulta usando información de distribución / fragmentación de datos. En
este paso, se determinan los fragmentos que están involucrados en la consulta y la consulta se transforma en una que opera sobre fragmentos
en lugar de unidades de datos globales especificadas en la consulta del usuario. El paso de optimización de la consulta global toma la consulta
localizada y determina el mejor método para ejecutar operaciones que abarcan varios sitios. Estas operaciones son los operadores relacionales
binarios habituales como join, union, intersect, etc.

Gestión de transacciones distribuidas

Una transacción es una unidad de atomicidad y consistencia, y asegura que la integridad de la base de datos se mantenga frente a
accesos concurrentes y fallas del sistema (ver Gestión de transacciones, procesamiento de transacciones). Los DBMS brindan soporte para lo que
se llama transacciones ACID (Atómicas, Consistentes, Aisladas y Durables): una transacción es una unidad atómica de ejecución, o todas sus
acciones están completadas o ninguna de ellas; una transacción es coherente en el sentido de que transforma un estado de base de datos
coherente en otro estado de base de datos coherente; una transacción se aísla de otras transacciones en ejecución ocultando sus modificaciones
hasta que se complete y no accediendo a las modificaciones que otras transacciones están haciendo simultáneamente en la base de datos; una
transacción es duradera, por lo que, una vez completada con éxito, los resultados sobrevivirán a cualquier falla del sistema [4].

El soporte de transacciones ACID en un entorno distribuido implica, además de los protocolos de control de concurrencia y confiabilidad
que se describen a continuación, problemas de arquitectura que tienen que ver con el control y la coordinación de la ejecución de
partes de transacciones en diferentes sitios. En el modelo presentado en la Figura 3, esta coordinación la realiza el Monitor de ejecución
global en el sitio donde se inicia la transacción por primera vez. El Monitor de ejecución global envía partes de esta transacción a los
Módulos de recuperación local relevantes para el procesamiento real y controla que se mantengan las propiedades de ACID.

Control de simultaneidad distribuido

El control de concurrencia implica la sincronización de accesos concurrentes a la base de datos distribuida, de modo que se mantenga la
integridad de la base de datos. Si el resultado en la base de datos de la ejecución concurrente de un conjunto de transacciones es
equivalente a alguna ejecución en serie (una tras otra) del mismo conjunto de transacciones, entonces se dice que las transacciones que
se ejecutan simultáneamente han mantenido la consistencia de la base de datos distribuida. Esto se conoce como
serializabilidad condición. En términos de las propiedades de ACID, los algoritmos de control de simultaneidad mantienen las propiedades de
consistencia y aislamiento de las transacciones.

El control de simultaneidad de las transacciones distribuidas requiere un algoritmo de sincronización distribuida que debe garantizar
que las transacciones concurrentes no solo sean serializables en cada sitio donde se ejecutan, sino que también sean serializables
globalmente. Esto implica que el orden en el que se ejecutan en cada sitio tiene que ser idéntico.
Los algoritmos de control de simultaneidad distribuidos se pueden agrupar en dos clases generales como pesimista, cuales
sincronizar la ejecución de las solicitudes de los usuarios antes de que comience la transacción, y optimista, que ejecutan las solicitudes y luego
realizan una verificación de validación para asegurarse de que la ejecución no haya comprometido la consistencia de la base de datos.
Dos primitivas fundamentales que se pueden utilizar con ambos enfoques son cierre, que se basa en el mutuo
exclusión de accesos a elementos de datos (similar a los semáforos en los sistemas operativos), y Marcando la hora, donde las
transacciones se ejecutan en algún orden. Existen variaciones de estos esquemas, así como algoritmos híbridos que intentan combinar
los dos mecanismos básicos. Los algoritmos basados en bloqueos provocan interbloqueos distribuidos que requieren
protocolos para manejarlosver Detección de interbloqueo distribuido).
Protocolos de confiabilidad distribuida

Los sistemas de bases de datos distribuidas son potencialmente más confiables ya que hay múltiples copias de cada componente del sistema, lo
que elimina los puntos únicos de falla, y los datos se pueden replicar para garantizar que se pueda proporcionar acceso en caso de fallas del
sistema. Los protocolos de confiabilidad distribuidos mantienen las propiedades de atomicidad y durabilidad (a) asegurando que
o bien todas las acciones de una transacción que se está ejecutando en diferentes sitios se completan con éxito (llamado cometer) o ninguno de
ellos se completa con éxito (llamado abo rt), y (b) asegurar que las modificaciones realizadas a la base de datos por transacciones comprometidas
sobrevivan a las fallas. El primero requiereprotocolos de compromiso atómico (ver Protocolos de confirmación), mientras que el segundo
requiere protocolos de recuperación.

El protocolo de compromiso atómico más común es el compromiso de dos fases (2PC) donde la transacción se compromete en dos pasos:
primero se sondean todos los sitios donde se ha ejecutado la transacción para asegurarse de que estén listos para comprometerse, y
luego se les indica que realicen la transacción (ver Compromiso en dos fases). El resultado es un compromiso uniforme
(o aborto) en cada sitio donde se ejecuta la transacción.

Los protocolos de recuperación son lo opuesto a los protocolos de compromiso atómico. Aseguran que el sistema pueda recuperarse a un estado
consistente después de una falla.

Protocolos de replicación

En bases de datos distribuidas replicadas cada elemento de datos lógicos tiene varias instancias físicas. Las consultas y transacciones se
refieren a elementos de datos lógicos y los protocolos de replicación reflejan sus acciones en las instancias físicas. El problema en este
tipo de sistema de base de datos es mantener cierta noción de coherencia entre las copias. El mas discutido
el criterio de coherencia es equivalencia de una copia, que afirma que los valores de todas las copias de un elemento de datos lógicos
deben ser idénticos cuando finaliza la transacción que lo actualiza [5].

Un protocolo de control de réplica típico que impone la equivalencia de una copia es el Leer una vez / escribir todo (ROWA) que mapea cada
operación de lectura de un elemento de datos lógicos a una lectura en una de las copias físicas que pueden ser determinadas por
consideraciones de rendimiento. Por otro lado, cada operación de escritura en un elemento de datos lógicos se asigna a un conjunto de escrituras
sobre todos réplicas físicas. El protocolo ROWA es simple y directo, pero la falla de un sitio puede bloquear una transacción y reducir la
disponibilidad de la base de datos. Se han propuesto varios algoritmos alternativos que reducen el requisito de que todas las copias de
un elemento de datos lógicos se actualicen antes de que la transacción pueda terminar. Relajan ROWA mapeando
cada uno escribe solo en un subconjunto de las copias físicas (ver Protocolos de control de replicación).

Referencias

[1] MT zsu y P. Valduriez, Principios de los sistemas de bases de datos distribuidas, segunda edición. Prentice Hall,
Inc., 1998.
[2] R. Orfali, D. Harkey y J. Edwards, Guía esencial de supervivencia cliente / servidor, 2.a edición. Wiley, 1996.

[3] CJ Date y H. Darwen, Una guía para el estándar SQL: una guía del usuario para el lenguaje estándar de bases de
datos SQL, 4a edición, Addison-Wesley, 1997.
[4] J. Gray y A. Reuter, Procesamiento de transacciones: conceptos y técnicas. Morgan Kaufmann, 1993.
[5] AA Helal, AA Heddaya y BB Bhargava, Técnicas de replicación en sistemas distribuidos. Editores académicos
de Kluwer, 1997.
Referencia cruzada:

Computación cliente-servidor ver Bases de datos, distribuidas.

Agrupación de bases de datos, distribuida ver Bases de datos, distribuidas.

Esquemas de bases de datos, distribuidos ver Bases de datos, distribuidas.

Detección de interbloqueo distribuido ver Bases de datos, distribuidas.

Bases de datos federadas ver Bases de datos, distribuidas.

Sistemas de archivos, distribuidos ver Bases de datos, distribuidas.

Interoperabilidad ver Bases de datos, distribuidas.

Sistemas de bases de datos múltiples ver Bases de datos, distribuidas.

Bases de datos paralelas ver Bases de datos, distribuidas.

Procesamiento de consultas, distribuido ver Bases de datos, distribuidas.

Bases de datos relacionales, distribuidas ver Bases de datos, distribuidas.

Sistemas de archivos replicados ver Bases de datos, distribuidas.

Protocolos de control de replicación ver Bases de datos, distribuidas.

Gestión de transacciones ver Bases de datos, distribuidas.

Procesamiento de transacciones ver Bases de datos, distribuidas.

Compromiso en dos fases ver Bases de datos, distribuidas.

Términos del diccionario:

Atomicidad

La propiedad del procesamiento de transacciones mediante la cual se ejecutan todas las operaciones de una transacción o ninguna de
ellas (todo o nada).

Base de datos distribuida

Una colección de múltiples bases de datos lógicamente interrelacionadas distribuidas a través de una red informática.

Sistema de gestión de bases de datos distribuidas

El sistema de software que permite la gestión de la base de datos distribuida y hace que la distribución sea transparente para los
usuarios.
Durabilidad

La propiedad del procesamiento de transacciones por la cual los efectos de transacciones completadas con éxito (es decir, comprometidas)
soportan fallas posteriores.

Aislamiento

La propiedad de ejecución de transacciones que establece que los efectos de una transacción en la base de datos están aislados de otras
transacciones hasta que la primera completa su ejecución.

Equivalencia de una copia

Política de control de réplicas que afirma que los valores de todas las copias de un elemento de datos lógicos deben ser idénticos cuando finaliza
la transacción que actualiza ese elemento.

Optimización de consultas

El proceso mediante el cual se encuentra la mejor estrategia de ejecución para una consulta determinada entre un conjunto de alternativas.

Procesamiento de consultas

Proceso mediante el cual una consulta declarativa se traduce en operaciones de manipulación de datos de bajo nivel.

Serializabilidad

El criterio de corrección del control de concurrencia que requiere que la ejecución concurrente de un conjunto de transacciones
sea equivalente al efecto de alguna ejecución en serie de esas transacciones.

Transacción

Una unidad de ejecución consistente y atómica contra la base de datos.

Transparencia

Extensión de la independencia de datos a sistemas distribuidos al ocultar la distribución, fragmentación y replicación de datos a los
usuarios.

Compromiso en dos fases

Un protocolo de compromiso atómico que garantiza que una transacción finalice de la misma manera en todos los sitios donde se
ejecuta. El nombre proviene del hecho de que se intercambian dos rondas de mensajes durante este proceso.