Sunteți pe pagina 1din 10

2.

1 Introduccin
Una base de datos distribuida (BDD) es un conjunto de mltiples bases de datos
lgicamente relacionadas que se encuentran distribuidas entre diferentes sitios
interconectados por una red de comunicaciones. La informacin que constituye la
base de datos est almacenada en diferentes sitios de la red, y las aplicaciones
que se ejecutan acceden a estos datos en lugares distintos. Por lo tanto, una base
de datos es una coleccin de datos que pertenecen lgicamente a un slo
sistema, pero que fsicamente se encuentra "distribuido" en varios lugares de la
red.
Hay que tener en cuenta que cada sitio anteriormente mencionado es un sistema
de base de datos en s mismo pero que con el resto de sitios que conforman la
base de datos distribuida han decidido trabajar juntos con el fin de que un usuario
de cualquier lugar pueda obtener acceso a los datos de cualquier punto de la red
tal como si todos los datos estuvieran siendo accedidos de forma local.
En consecuencia, la llamada base de datos distribuida es en realidad una especie
de objeto virtual, cuyas partes componentes se almacenan fsicamente en varias
bases de datos "reales" distintas, ubicadas en diferentes sitios. Es una unin
lgica de esas bases de datos.
Se asume que cada localidad ejecuta el mismo software de control de base de
datos distribuida. Si no se cumple esta premisa, ser muy difcil manejar
transacciones globales.

2.2 Diseo de la base de datos distribuida


En el diseo de bases de datos distribuidas se debe considerar el problema de
cmo distribuir la informacin entre diferentes sitios. Existen razones
organizacionales las cuales determinan en gran medida lo anterior. Sin embargo,
cuando se busca eficiencia en el acceso a la informacin, se deben abordar dos
problemas relacionados. Primero, como fragmentar la informacin. Segundo,
como asignar cada fragmento entre los diferentes sitios de la red. En el diseo de
la BDD tambin es importante considerar si la informacin esta replicada, es decir,
si existen copias mltiples del mismo dato, y en este caso, como mantener la
consistencia de la informacin. Finalmente, una parte importante en el diseo de
una BDD se refiere al manejo del directorio. Si existen nicamente usuarios
globales, se debe manejar un solo directorio global. Sin embargo, si existen
tambin usuarios locales, el directorio combina informacin local con informacin
global.
Un sistema distribuido de base de datos consiste en un conjunto de localidades,
cada una de las cuales mantiene un sistema de base de datos local. Cada
localidad puede procesar transacciones locales, o bien transacciones globales
entre varias localidades, requiriendo para ello comunicacin entre ellas.
Las localidades pueden conectarse fsicamente de diversas formas, las principales
son:
Red totalmente conectada
Red prcticamente conectada
Red con estructura de rbol
Red de estrella
Red de anillo
Las diferencias principales entre estas configuraciones son:
Coste de instalacin: El coste de conectar fsicamente las localidades del
sistema
Coste de comunicacin: El coste en tiempo y dinero que implica enviar un
mensaje desde la localidad A a la B.
Fiabilidad: La frecuencia con que falla una lnea de comunicacin o una
localidad.
Disponibilidad: La posibilidad de acceder a informacin a pesar de fallos en
algunas localidades o lneas de comunicacin.

Las localidades pueden estar dispersas, ya sea por un rea geogrfica extensa (a
lo largo de un pas), llamadas redes de larga distancia; o en un rea reducida (en
un mismo edificio), llamadas redes de rea local. Para las primeras se utilizan en
la comunicacin lneas telefnicas, conexiones de microondas y canales de
satlites; mientras que para las segundas se utiliza cables coaxiales de banda
base o banda ancha y fibra ptica.
Una posible clasificacin para organizar los DBMS distribuidos segn su
Arquitectura se base en tres aspectos fundamentales:
Anatoma: El trmino autonoma se refiere a la distribucin del control, y no a la
distribucin de los datos, indicando el grado en el cual un DBMS individual puede
operar independientemente. Se encuentran (entre otros) los siguientes tipos de
sistemas:
Integracin estricta (tight integration): una nica imagen de la base de
datos est disponible para cualquier usuario que quiera obtener
informacin, la cual podra residir en mltiples bases de datos. A vista del
usuario, los datos estn lgicamente centralizados en una base de datos.
Semiautnomos: aquellos DBMS que pueden operar independientemente,
pero que han decidido participar en una federacin para compartir sus
datos. Cada DBMS de dicha federacin determina que partes de su propia
base de datos establece como accesible a usuarios de otros DBMS. No son
totalmente autnomos pues necesitan ser modificados para permitirles el
intercambio de informacin con otros.
Aislamiento total (total isolation): donde el sistema es un DBMS aislado,
que no sabe nada sobre la existencia de otros DBMSs o sobre cmo
comunicarse con ellos. En estos sistemas el procesamiento de las
transacciones que acceden a varias bases de datos es especialmente
difcil, debido a que no existe un control global sobre la ejecucin de los
DBMSs individuales.
Distribucin
Si la autonoma trataba la distribucin del control, la distribucin se centra en la
distribucin propiamente dicha de los datos. Se presentan dos tipos clases de
distribucin:
Cliente/Servidor: concentra la manipulacin de datos en una mquina
servidor que responde a las peticiones de una cliente, que es la encargada
de mostrar la informacin y presentar una interfaz visual.

Peer-to-peer: no existe distincin de mquinas cliente o servidor ya que


todas las maquinas tienen una funcionalidad completa y puedes
comunicarse con otras mquinas que ejecuten consultas y transacciones.
Estos sistemas tambin son llamados completamente distribuidos.
Heterogeneidad
La heterogeneidad se puede dar de varias formas en los sistemas distribuidos,
desde las diferencias entre el hardware y los protocolos de red hasta las
variaciones en la gestin de datos. La representacin de datos con diferentes
herramientas de modelado da pie a heterogeneidad debido al poder o limitaciones
de cada sistema de datos individual. As mismo no solo se presentan diferencias
en la definicin de los datos, pues aun teniendo una definicin igual o similar de
datos, podra darse que las operaciones sobre estos se realizaran de formas muy
diferentes para conseguir un mismo resultado.

2.3 Procesamiento de consultas distribuidas


Objetivos
Transformar consulta de alto nivel en lgebra relacional en otra consulta
expresada en lenguaje de bajo nivel que consta de una extensin del lgebra
relacional con operaciones de comunicacin:
Consulta lgebra relacional de alto nivel => Consulta en lenguaje de bajo
nivel + Operaciones de comunicacin
Hacerlo de forma optimizada, para lo cual tenemos en cuenta el uso de los
siguientes recursos:
CPU + I/O + costes de comunicacin (el ms costoso en BBDD
distribuidas)

Caracterizacin de consultas
Lenguaje: Gran parte del trabajo de procesamiento tiene que ver con el lenguaje,
pues los lenguajes relacionales proporcionan muchas oportunidades para la
optimizacin. En BBDD distribuidas se cuenta con un lenguaje relacional ms
primitivas de comunicacin.
Optimizacin: La optimizacin de consultas se suele decantar por minimizar el
tamao de las relaciones intermedias.

Estadsticas: Necesarias para decidir en el proceso de optimizacin. Se recopilan


datos de consultas anteriores y dems artefactos y se toma la decisin en funcin
de estos datos.
Lugar de decisin: Varios sitios puede participar en la seleccin de la estrategia
ms adecuada para responder a la consulta, aunque tambin es comn que esta
decisin se haga de forma centralizada, pero en ese caso es necesario que quien
tome la decisin tenga conocimiento completo de la base de datos distribuida.
Topologa de red: La optimizacin de consultas distribuidas puede dividirse en
dos problemas: seleccin de la estrategia global de ejecucin basada en las
comunicaciones entre sitios y seleccin de cada estrategia local de ejecucin,
basada en un algoritmo de procesamiento centralizado, como si la BD no estuviera
distribuida.
Fragmentos replicados: El procesador de consultas debe localizar los lugares
donde se encuentran los datos que busca. Para optimizacin, se suele jugar con el
hecho de que a veces hay datos que estn replicados, lo cual puede ser
beneficioso para aprovechar unos caminos u otros en la topologa de red.
Uso de semijoins: El uso de semijoins reduce el tamao de los datos
intercambiados entre los sitios, por lo cual en redes lentas su uso est bastante
extendido. No obstante, esto implica aumento en el nmero de mensajes
intercambiados y aumento tambin del tiempo de proceso local.
Capas de las consultas distribuidas
El problema de procesamiento de consultas distribuidas puede ser descompuesto
en subproblemas a los que se refieren las siguientes capas. Algunos problemas
son resueltos mediante informacin global mientras que otros son resueltos en los
mdulos locales:
a) Usan informacin global
1- Descomposicin de consultas: Consta de las siguientes fases:
La consulta es reescrita en forma normalizada usando reglas de
equivalencia para operaciones lgicas. Tenemos dos alternativas: forma
normal conjuntiva y forma normal disjuntiva.
Se analiza semnticamente la consulta detectando aquellas que sean
errneas para comunicrselo al usuario.
Se simplifica la consulta para eliminar predicados redundantes mediante el
uso de equivalencias para operaciones lgicas.

Se reestructura la consulta escogiendo una equivalente pero que se


comporte mejor.
2- Localizacin de datos: Se deben de localizar los datos usando la informacin
de distribucin de stos. Las relaciones estn divididas en fragmentos guardados
en diferentes lugares. En este paso se averigua cules de estos fragmentos estn
involucrados en esta consulta y se transforma la consulta global en consultas a
cada uno de los fragmentos.
3- Optimizacin global de consultas: La optimizacin que se realiza en este
apartado ordena la forma en que se van a ejecutar las consultas para que los
recursos de computacin como discos, comunicaciones, etc. puedan ser utilizados
de manera eficiente. Debemos tener en cuenta las cardinalidades de los
resultados intermedios, las estadsticas de la base de datos y tener presente el
modelo de coste que se expresa de la siguiente forma:
Coste_total=Coste_cpu*#instr+C_I/O*#I/Os+C_mensaje*#mensajes+C_t
ransm*#bytes

C_mensaje es el coste de enviar o recibir un mensaje.


C_transm es el coste de transmitir unidades de un lugar a otro.
Se aplican varios algoritmos de optimizacin. Muchos son genricos de las bases
de datos relacionales y otros como INGRES, R*, SSD-1 o AHY son especficos de
las bases de datos distribuidas
b) Usan informacin local
4. Optimizacin local de consultas: Usando el schema de cada lugar se optimiza la
consulta local que se nos ha realizado.

2.4 Transacciones distribuidas


A la hora de hablar de transacciones, en primer lugar, se deben aclarar dos
conceptos:
Consistencia de una transaccin: se referido a la accin concurrente de
transacciones. Nos gustara que la base de datos permaneciera en un
estado consistente incluso si varios usuarios estas realizando un acceso
concurrente (leyendo o actualizando) a la base de datos.

Confiabilidad: con este trmino se hace referencia tanto a la resistencia


del sistema frente a diferentes fallos como a su capacidad de recuperacin.
Un sistema resistente es tolerante a fallos del sistema y puede continuar
proporcionando servicio incluso si estos ocurren. Ademas un DBMS es
recuperable si puede alcanzar un estado de consistencia tras la ocurrencia
de varios fallos.
Una transaccin debe funcionar como sigue; toma una base de datos, realiza un
accin sobre ella, y genera una nueva versin de la base de datos, causando una
transicin de estado. Teniendo en cuenta que si la base de datos era consistente
antes de la transaccin, se debe garantizar la consistencia tras la misma,
pensando tambin, que la transaccin puede ejecutarse concurrentemente con
otras, y que podran producirse errores en su curso.
Propiedades de las transacciones (ACID)
La consistencia y confiabilidad de una transaccin viene dada por cuatro
propiedades ACAD o ACID (del ingls atomicity, consistency, isolation, durability):
1- Atomicidad: una transaccin es tratada como una unidad, esto es, o se
realizan todas las acciones de la transaccin o no se realiza ninguna.
2- Consistencia: una transaccin debe llevar a una base de datos de un
estado consistente, a otro estado tambin consistente una vez ha
finalizado.
3- Aislamiento: una transaccin no puede revelar su resultado a otras
transacciones concurrentes antes de haber realizado su commit.
4- Durabilidad: propiedad de una transaccin que asegura que una vez esta
finalice correctamente, su resultado sea permanente y no pueda ser
eliminado de la base de datos (por ejemplo por algn fallo en el sistema).
Tipos de transacciones
Con el tiempo, se han propuesto muchos modelos de transacciones. Sin embargo
uno de los principales problemas es el cumplimiento de las cuatro propiedades
anteriormente mencionadas. En algunos de los casos, la solucin ha sido la
relajacin sobre alguno de los puntos, evitando as algunos problemas, pero por
tanto dando lugar a otros nuevos.
Las transacciones han sido clasificadas de acuerdo a diferentes criterios:
Duracin:
* On-line: caracterizadas por un tiempo de respuesta y ejecucin muy corto
y por un acceso a una pequea porcin de la base de datos. Este tipo de

transaccin cubre la mayora de las transacciones de los programas


actuales.
* Batch: caracterizadas por un gran tiempo de ejecucin (del orden de los
minutos, horas o das) y por acceder a grandes volmenes de datos.
Organizacin de Lectura/Escritura:
* General: las lecturas y escrituras se realizan sin orden determinado.
* Dos-pasos (two-step): si todas las lecturas son realizadas antes de las
escrituras.
* Restringida (restricted o read-before-write): si la transaccin est
restringida de forma que un dato debe ser ledo antes de poder ser
actualizado (escrito).
* Restringida de dos pasos (restricted two-step): si es cumple las dos
anteriores.
* Accin: consistente en la ejecucin de parejas de operaciones atmicas
<lectura,escritura>.
Estructura:
* Transaccin plana (flat transaction): aquella transaccin que tiene un nico
punto de inicio y un nico punto de terminacin.
* Transacciones anidadas (nested transaction): permite que una transaccin
incluya otras transacciones con sus propios puntos de inicio y fin, que
suelen recibir el nombre de subtransacciones.

2.5 Control de concurrencia


El nivel de concurrencia es probablemente el parmetro ms importante en
sistemas distribuidos, pues ejecutar una transaccin tras otra sin que hagan
trabajo simultneo degradara enormemente el rendimiento del sistema. Al
ejecutar transacciones de forma concurrente, intercalamos operaciones de las
distintas transacciones entre s, lo cual puede lugar a interferencias que violen las
reglas ACID. Para evitarlo, se deben de controlar estas intercalaciones de forma
que permitamos solo aquellas ejecuciones que tengan el mismo resultado que si
una transaccin se ejecutase tras la otra. Estas ejecuciones se llaman
serializables y para llegar a ellas nos servimos de la teora de la seriabilidad.

Teora de la seriabilidad:
Es una herramienta matemtica que permite encontrar conflictos en la ejecucin
concurrente de transacciones. Desde el punto de vista de la teora de la
seriabilidad una transaccin es una representacin de una ejecucin de
operaciones de lectura y escritura en donde se indica el orden en que se deben
ejecutar estas operaciones. Adems, la transaccin contiene un Commit o un
Abort como la ltima operacin para indicar si la ejecucin que representa termin
con xito o no.
Algoritmos de control de concurrencia
Pesimistas: Asumen que los conflictos entre transacciones son frecuentes.
Sincronizan las transacciones desde el principio de su ejecucin.
Bloqueantes: Los datos compartidos que se encuentran en conflicto son
accedidos por una operacin cada vez. Se aade un cerrojo a los datos
compartidos que se activa cuando el dato va a ser accedido y se desactiva al
abandonarlo. Normalmente de esta activacin y desactivacin se encarga el
DBMS. Si una transaccin quiere acceder a un dato con el cerrojo activado, debe
esperar. Tenemos cerrojos de lectura y escritura.
* Centralizado: El manejo de los cerrojos es responsabilidad de un solo
sitio. A este lugar llegan las peticiones de bloqueo que se responden
positiva o negativamente.
* Copia primaria: Los manejadores de cerrojos se implementan en varios
sitios que se responsabilizan de un conjunto de cerrojos. Ahora cada
localizacin debe saber a qu manejador pedir el bloqueo de cada dato,
pues ya no est todo centralizado.
* De voto: Cada nodo opina sobre si el bloqueo debe ser concedido.
Timestamp: Se selecciona una ejecucin serializable y se ejecuta las
transacciones en consecuencia. Se asigna un timestamp a la lectura de cada
recurso por parte de una transaccin. Lo mismo con las escrituras, de forma que
tenemos tw(x), tr(x), tw(y), tr(y) si una transaccin lee y escribe los recursos x e y.
Los timestamps identifican a las transacciones y permiten su ordenacin. En la
existencia de conflictos, se da prioridad a la transaccin con el timestamp que
indique que es ms antigua.
* Bsico: El manejador de transacciones asigna timestamps a cada
transaccin, determina los lugares donde los datos estn guardados y enva
las operaciones pertinentes a cada uno de los sitios. Si una operacin es

rechazada por el planificador, el manejador de transacciones la reinicia


asignndole un nuevo timestamp.
* Conservador: Pretende evitar los reinicios del algoritmo bsico pero
aadiendo esperas.
* Multiversin: Las actualizaciones no modifican la base de datos sino que
crean nuevas versiones de los datos modificados que despus se
actualizarn. Se aprovecha de que la ejecucin es serializable.
Optimistas: Asumen que los conflictos entre transacciones son infrecuentes.
Retrasan la sincronizacin de las transacciones hasta el final de su ejecucin. Las
etapas de lectura, computacin y escritura de cada transaccin son procesadas
sin actualizar la base de datos. Cada transaccin inicialmente hace sus copias
locales de datos. La etapa de validacin consiste en comprobar si las copias
locales sobre las que se trabaja mantienen la consistencia de la base de datos. Si
esto es cierto, los cambios se realizan globalmente. Si no, la transaccin es
abortada.

Links
https://basesdedatosavanzadas.wikispaces.com/Distribuidas
https://lihectortorres.files.wordpress.com/2010/09/base_de_datos_distribuidas.pdf

S-ar putea să vă placă și