You are on page 1of 15

Bases de Datos Distribuidas

INTRODUCCIN. VISIN GENERAL VENTAJAS DE LA BASES DE DATOS DISTRIBUIDAS INCONVENIENTES DE LA BASES DE DATOS DISTRIBUIDAS ALMACENAMIENTO DISTRIBUIDO DE DATOS RPLICA FRAGMENTACIN DE DATOS RPLICA Y FRAGMENTACIN DE DATOS TRANSPARENCIA DE LA RED DENOMINACIN DE LOS ELEMENTOS DE DATOS PROCESAMIENTO DISTRIBUIDO DE CONSULTAS EJEMPLO DE CONSULTA DISTRIBUIDA PROCESO DISTRIBUIDO DE CONSULTAS UTILIZANDO SEMIJOIN RECUPERACIN PROTOCOLOS ACP (ATOMIC COMMITMENT PROTOCOL) 2PC (THE TWO PHASE COMMIT PROTOCOL)

2 2 3 3 4 4 4 7 8 8 9 10 12 13 14 14 15

Introduccin.
Visin general En un sistema de Bases de Datos Distribuido, los datos se encuentran en diferentes mquinas, generalmente situados en localizaciones geogrficas diferentes. Dichas mquinas pueden ser de distinto tipo atendiendo a su tamao, prestaciones y Sistema Operativo. A cada uno de los ordenadores que integran el sistema de Bases de Datos distribuido se le conoce como nodo o emplazamiento del sistema y pueden ser administrados de forma diferente. Una caracterstica importante de las Bases de Datos Distribuidas es que realizan dos tipos de transacciones bien diferenciados: Transacciones Locales: cuando se accede a los datos del nico emplazamiento donde se inici la transaccin. Transacciones Globales: Cuando se accede a datos de emplazamientos distintos al emplazamiento donde se inici la transaccin.

Las transacciones Globales sern las que requerirn un tratamiento diferenciado con respecto a las realizadas en sistemas de Bases de Datos Centralizados y sern el objeto de estudio de este tema. Un ejemplo general de un Sistema Distribuido de Bases de Datos correspondera con la siguiente figura:

Nodo EUI Alumnos


RED

Nodo EUIT Alumnos

Comunicacin a travs de la red

Nodo Rectorado Escuelas

En Este sistema, encontramos tres nodos correspondientes a la Escuela Universitaria de Informtica, La Escuela Universitaria de Telecomunicaciones y el Rectorado de la UPM. Cada nodo de las escuelas tiene, entre otras, la tabla Alumnos con el siguiente esquema: DNI Escuela Nombre Nota ingreso Beca

El nodo del Rectorado, tiene informacin respecto a las escuelas de la Politcnica. Una de las tablas de este nodo, la tabla Escuelas, tiene el siguiente esquema: Escuela Situacin Nmero alumnos

Si un nuevo alumno se matricula en la Escuela de Informtica desde la secretara del mismo centro, se considera una transaccin local. Sin embargo si un alumno se matricula a travs del Rectorado, la transaccin se considera global. Este sistema ser distribuido si cumple que: Los distintos nodos estn informados sobre los dems. Aunque algunas tablas estn almacenadas slo algunos nodos, stos comparten un esquema global comn. Cada nodo proporciona un entorno de ejecucin de transacciones tanto local como global. Generalmente, los nodos ejecutan el mismo software de gestin distribuida. En caso contrario, aumenta en gran medida la dificultad de implementacin del sistema de Bases de Datos Distribuidas. En este caso se dice que el sistema es heterogneo.

Ventajas de la Bases de Datos Distribuidas Compartimiento de datos. Los usuarios de un nodo son capaces de acceder a los datos de otro nodo. Por ejemplo, desde el Rectorado, se puede consultar los datos de los alumnos de Informtica. Autonoma. Cada nodo tiene cierto grado de control sobre sus datos, en un sistema centralizado, hay un administrador del sistema responsable de los datos a nivel global. Cada administrador local puede tener un nivel de autonoma local diferente. Disponibilidad. Si en un sistema distribuido falla un nodo, los nodos restantes pueden seguir funcionando. Si se duplican los datos en varios nodos, la transaccin que necesite un determinado dato puede encontrarlo en cualquiera de los diferentes nodos.

Inconvenientes de la Bases de Datos Distribuidas Coste de desarrollo del software. La complejidad aadida que es necesaria para mantener la coordinacin entre nodos hace que el desarrollo de software sea ms costoso.

Mayor probabilidad de errores. Como los nodos que constituyen el sistema funcionan en paralelo, es ms difcil asegurar el funcionamiento correcto de los algoritmos, as como de los procedimientos de recuperacin de fallos del sistema. Mayor sobrecarga de procesamiento. El intercambio de mensajes y ejecucin de algoritmos para el mantenimiento de la coordinacin entre nodos supone una sobrecarga que no se da en los sistemas centralizados.

Almacenamiento distribuido de datos


Para este punto, consideraremos una tabla T que se tiene que almacenar el una base de datos distribuida. Existen varias opciones: Rplica El sistema conserva varias copias o rplicas idnticas de la tabla. Cada rplica se almacena en un nodo diferente, lo que da lugar a redundancia de datos. La alternativa a la rplica es guardar la tabla en un solo nodo. La rplica presenta las siguientes ventajas e inconvenientes: Disponibilidad: Como se vio en la introduccin, la rplica permite que el sistema siga funcionando an en caso de cada de uno de los nodos. Aumento del paralelismo: En el caso de que la mayora de los accesos a la tabla T sean de lectura, varios nodos pueden realizar consultas en paralelo sobre la misma tabla. Cuantas ms rplicas existan de la tabla, mayor ser la posibilidad de que el dato buscado se encuentre en el nodo desde el que se realiza la consulta, minimizando con ello el trfico de datos entre nodos. Aumento de la sobrecarga en las actualizaciones: El sistema debe asegurar que todas las rplicas de la tabla sean consistentes, por tanto, cuando se realiza una actualizacin sobre una de las rplicas, los cambios deben propagarse a todas las rplicas de dicha tabla a lo largo del sistema distribuido. Esto hace que las actualizaciones sean ms costosas que en los sistemas centralizados.

En general, el sistema de rplica hace que las consultas sean ms eficientes, pero complica las actualizaciones debido al problema de la redundancia de datos y el mantenimiento de la consistencia. Normalmente, se elige una de las rplicas como copia principal para simplificar la administracin. Fragmentacin de datos La tabla T se puede separar en varios fragmentos que contendrn suficiente informacin para reconstruir la tabla original. La fragmentacin puede ser horizontal o vertical y se puede aplicar sucesiva y alternativamente sobre la misma tabla. Cada fragmento se encontrar en nodos diferentes.

Fragmentacin horizontal:

La tabla T se divide en subconjuntos, T1, T2, ...Tn. Cada tupla de T debe pertenecer al menos a uno de los fragmentos para poder reconstruir la tabla original a partir de los fragmentos. Los fragmentos se definen a travs de una operacin de seleccin y su reconstruccin se realizar en base a una operacin de unin de los fragmentos componentes. En el ejemplo siguiente, se ilustra una posible fragmentacin de la tabla Alumnos de dos fragmentos: uno para el nodo de la EUI y otro para el nodo de la EUIT. DNI 87633483 99855743 33887293 05399075 44343234 44543324 66553234 Escuela EUI EUI EUIT EUI EUIT EUI EUIT Nombre Concha Queta Josechu Letn Oscar Romato Bill Gates Pepe Ptamo Maite Clado Ernesto Mate Nota ingreso 5.6 7.2 6.1 5.0 8.0 7.5 6.6 Beca No Si Si No No Si No

Escuela="EUI"(T)
DNI 87633483 99855743 05399075 44543324 Escuela EUI EUI EUI EUI Nombre Concha Queta Josechu Letn Bill Gates Maite Clado Nota ingreso 5.6 7.2 5.0 7.5 Beca No Si No Si

Escuela="EUIT"(T)
DNI 33887293 44343234 66553234 Escuela EUIT EUIT EUIT Nombre Oscar Romato Pepe Ptamo Ernesto Mate Nota ingreso 6.1 8.0 6.6 Beca Si No No

En algunos casos, puede ser necesario que los fragmentos no sean disjuntos, consiguiendo as combinar la tcnica de replicacin con la de fragmentacin. La recuperacin de la relacin original se realizar a partir de la unin de cada uno de los fragmentos: T= T1 T2...Tn
En nuestro caso: ALUMNOS=ALUMNOS_EUI ALUMNOS_EUIT

Fragmentacin vertical:

La fragmentacin vertical implica la definicin de subconjuntos de atributos de la relacin de partida mediante la operacin de proyeccin. Cada fragmento se define como Ti=a1..an(T). Para poder recomponer la relacin original, cada fragmento debe incluir la clave primaria de T. La relacin inicial se recompondr en base a unin natural de los fragmentos resultantes: T=T1T2*..*Tn. Como ejemplo, supongamos que en el rectorado existen dos departamentos ubicados en distinto lugares y con necesidades distintas de informacin. El departamento de infraestructuras que maneja la informacin referente a las escuelas y su situacin. Adems est en departamento de ordenacin acadmica que utiliza la informacin de las escuelas y el nmero de alumnos. En sta situacin se podra plantear una fragmentacin vertical de la relacin original en dos fragmentos de la siguiente manera: Escuela EUI EUIT TOPOGRAFIA ETSIT FI Situacin Campus sur Campus sur Campus sur Ciudad Universitaria Campus Montegancedo Nmero alumnos 3000 2800 800 2500 2100

Escuela,Situacin(T)
Escuela EUI EUIT TOPOGRAFIA ETSIT FI Situacin Campus sur Campus sur Campus sur Ciudad Universitaria Campus Montegancedo

Escuela,Nmero_alumnos(T)
Escuela EUI EUIT TOPOGRAFIA ETSIT FI Nmero alumnos 3000 2800 800 2500 2100

Fragmentacin mixta:

La fragmentacin mixta puede surgir como la aplicacin combinada de la fragmentacin horizontal y vertical. Como ejemplo, podemos partir de la relacin resultante de la fragmentacin horizontal en la tabla de alumnos. Supongamos que en la EUI existen dos nodos dedicados a distintas funciones. Uno de ellos sera el de secretara que maneja la informacin referente a los alumnos y sus becas. Otro podra ser el de Jefatura de Estudios que utiliza la informacin referente a las notas de ingreso de los distintos alumnos. Tendramos el siguiente esquema:

DNI 87633483 99855743 05399075 44543324

Escuela EUI EUI EUI EUI

Nombre Concha Queta Josechu Letn Bill Gates Maite Clado

Nota ingreso 5.6 7.2 5.0 7.5

Beca No Si No Si

DNI,Escuela,Nombre,Beca(T)
DNI 87633483 99855743 05399075 44543324 Escuela EUI EUI EUI EUI Nombre Concha Queta Josechu Letn Bill Gates Maite Clado Beca No Si No Si

DNI,Escuela,Nombre,Nota_ingreso(T)
DNI 87633483 99855743 05399075 44543324 Escuela EUI EUI EUI EUI Nombre Concha Queta Josechu Letn Bill Gates Maite Clado Nota ingreso 5.6 7.2 5.0 7.5

En este caso, las dos relaciones resultantes surgen de la fragmentacin mixta: primero se ha aplicado una fragmentacin horizontal por centros y luego una fragmentacin vertical por departamentos del centro. Rplica y fragmentacin de datos Las tcnicas de rplica y fragmentacin se pueden aplicar sucesivamente a la misma relacin de partida. Un fragmento se puede replicar y a su vez esa rplica ser fragmentada, para luego replicar alguno de esos fragmentos.

Transparencia de la red
Desde el punto de vista del usuario de la base de datos distribuida, los detalles de cmo y donde se encuentran almacenados fsicamente los datos. A la capacidad de ocultar estos detalles por parte del sistema distribuido se le denomina transparencia de la red. La transparencia de la red tiene que apoyarse en los siguientes aspectos: La denominacin de los elementos de datos. La rplica de los elementos de datos. La fragmentacin de los elementos de datos. La ubicacin de los fragmentos y las rplicas.

Denominacin de los elementos de datos Entenderemos como elementos de datos dentro de un sistema de bases de datos distribuido los siguientes: relaciones, fragmentos y rplicas. En un sistema distribuido, los elementos de datos tienen que tener un nombre nico. Una posible solucin al problema de la duplicidad de nombres es exigir que todos los nombre se registren en un servidor de nombres central que controle la asignacin correcta de nombres a los elementos de datos. Otra posible solucin es utilizar el servidor de nombres para ubicar un elemento de datos, dando el nombre del mismo. Con sta solucin aparecen, sin embargo, dos problemas: El servidor de nombres puede llegar a convertirse en un cuello de botella cuando se localizan los elementos de datos por sus nombre, lo que da lugar a un bajo rendimiento. Si el servido de nombres se queda fuera de servicio, pude que ningn nodo del sistema distribuido siga funcionando.

La alternativa al servidor central de nombre es exigir a cada nodo que aada como prefijo al elemento de datos su propio identificador de nodo. sta solucin asegura que no haya dos emplazamientos que generen el mismo nombre para dos elementos de datos distintos. Sin embargo se pierde la transparencia de la red dado que los identificadores de los nodos estn ligados a los nombres. Por ejemplo, se tendra que hacer referencia a la relacin ALUMNO como, por ejemplo, EUI,ALUMNO. Para recuperar la transparencia, se puede crear un conjunto de alias para los elementos de datos. De sta manera el sistema puede traducir nombres sencillos en los nombres con referencia a los nodos de forma automtica, transparente para el usuario. La correspondencia entre alias y nombres de elementos se almacenar en todos los nodos. Con esto se consigue, adems, que si el administrador cambia de ubicacin los elementos de datos de un nodo a otro, ste cambio no ser percibido por el usuario. Cada rplica y cada fragmento de un elemento de datos debe ser nico. Es importante que el sistema pueda determinar las rplicas y fragmentos que son rplicas y fragmentos del mismo elemento de datos. Cada rplica se identifica mediante el sufijo .r1, .r2,..., .rn. Cada fragmento mediante el sufijo .f1, .f2,..., .fn. Por ejemplo:

EUI.ALUMNOS.f3.r2 hace referencia a la rplica 2 del fragmento 3 del elemento ALUMNOS del nodo EUI. Los usuarios no conocern cmo estn fragmentados o replicados los elementos de datos. Existir una tabla en el catlogo que permita al sistema determinar en qu fragmentos o rplicas estn los datos que el usuario solicita y mantendr las rplicas actualizadas cuando se produzca una sentencia que modifique los datos. Para traducir los alias en nombres, el sistema utiliza el siguiente algoritmo: if nombre aparece en la tabla de alias Then expresin := correspondencia(nombre) else expresin := nombre; Function correspondencia (n) if n aparece el la tabla rplica then resultado := nombre de la rplica de n; if n aparece en la tabla de fragmentacin then begin resultado := expresin para generar fragmentacin foreach n in resultado do begin sustituir n en resultado por correspondencia (n); end end return resultado;

Procesamiento distribuido de consultas


En el procesamiento distribuido de consultas se estudia el coste de las comunicaciones. Las consultas distribuidas se realizarn, ante todo, con la operacin de semijoin para poder optimizar dichas consultas. En un sistema distribuido hay varios factores adicionales que complican el proceso de consulta en comparacin con los sistemas centralizados. El primero de estos factores es el coste de transferencia de datos a travs de la red. Los datos son enviados a ficheros intermedios que a su vez se envan a otros nodos para nuevos procesos. Los ficheros resultantes deben enviarse de vuelta al nodo que lanz la consulta. Los algoritmos de consulta deben, por tanto, tener como objetivo la reduccin de la cantidad de datos transferidos.

Ejemplo de consulta distribuida Partiremos de la siguiente situacin: NODO1: EMPLEADO Nombre Apellido COD Dir Sexo Sueldo fecha Nac. Dpto.

El contenido de la relacin EMPLEADO es el siguiente: 10.000 tuplas. Cada tupla tiene 100 bytes de longitud. El campo COD tiene 9 bytes de longitud. El campo Depto tiene 4 bytes de longitud. El campo Nombre tiene 15 bytes de longitud. El campo Apellido tiene 15 bytes de longitud.

NODO 2: DEPARTAMENTO NombreDpto NDpto Responsable Edificio

100 tuplas. Cada tupla tiene 35 bytes de longitud. El campo NDpto tiene 4 bytes de longitud. El campo Responsable tiene 9 bytes de longitud. El campo Edificio tiene 10 bytes de longitud.

Supondremos que no existe ningn tipo de fragmentacin. El tamao de la relacin EMPLEADO es 100 * 10.000 = 106 bytes y el tamao de la relacin DEPARTAMENTO es 35 * 100 = 3500 bytes. Consideremos la consulta Por cada empleado, obtener el nombre del empleado y el nombre del departamento al que pertenece. La expresin de sta consulta en lgebra relacional ser: Q: Nombre,Apellido,NombreDPto (EMPLEADO * DEPARTAMENTO) El resultado de sta consulta constar de 10.000 tuplas. Cada tupla resultante ser de una longitud de 40 bytes. El tamao del resultado ser por tanto de 400.000 bytes. Supongamos que el resultado viaja al nodo 3, denominado nodo respuesta ya que ser el lugar donde se requiera el resultado de dicha consulta. Sin embargo, ni la relacin EMPLEADO ni DEPARTAMENTO residen en dicho nodo. Existen tres estrategias para resolver sta consulta: 1. Transferir tanto la relacin EMPLEADO como la del DEPARTAMENTO al nodo respuesta (nodo 3) y realizar all mismo la operacin de join. En ste caso se transfieren 1.000.000 + 3.500 = 1.003.500 bytes.

2. Transferir la relacin EMPLEADO al nodo 2, ejecutar el join en este nodo y enviar el resultado al nodo 3. Esto implicara transferir 1.000.000 bytes de EMPLEADO + 400.000 bytes del resultado, es decir: 1.400.000 bytes. 3. Transferir la relacin DEPARTAMENTO al nodo 1, ejecutar el join en este nodo y enviar el resultado al nodo 3. En este caso, los bytes transferidos sern: 3.500 de la relacin DEPARTAMENTO ms 400.000 del resultado. Es decir 403.500 bytes. Como se observa, la tercera opcin es la que implica menos transferencia de datos por la red. Supongamos ahora la consulta: para cada departamento, obtener el nombre del departamento y el de su director. Su expresin algebraica sera: Q: NombreDPto,Nombre,Apellido(DEPARTAMENTO * EMPLEADO) Supondremos de nuevo que la respuesta va dirigida al nodo 3. En este caso slo tendremos 100 tupas en la respuesta, es decir 4.000 bytes. Estudiamos las tres posibles soluciones: 1. Transferimos las relaciones DEPARTAMENTO y EMPLEADO al nodo 3. Se transfieren 3.500 + 1.000.000 = 1.003.500 bytes. 2. Transferimos la relacin EMPLEADO al nodo 2 y enviamos el resultado del join al nodo 3. Se transfieren 1.000.000 + 4.000 = 1.004.000 bytes. 3. Transferimos la relacin DEPARTAMENTO al nodo 1 y enviamos el resultado del join al nodo 3. Se transfieren en este caso 3.500 + 4.000 = 7.500 bytes. En este caso, la mejor alternativa el tercer supuesto. Sin embargo, se puede plantear el caso en el que le nodo respuesta contenga parte de la informacin necesaria para resolver la consulta. Supongamos que en este caso el nodo respuesta es el nodo 2. Tendramos entonces dos opciones: 1. Transferir la relacin EMPLEADO al nodo 2, realizar el join y presentar el resultado al usuario del nodo 2. De sta manera se transferirn el mismo nmero de bytes para la consulta Q y la Q: 1.000.000 bytes. 2. Transferir la relacin DEPARTAMENTO al nodo 1, realizar el join y enviar el resultado al nodo 2. En este caso se transfieren para la consulta Q, 3.500 de DEPARTAMENTO y 400.00 de resultado: 403.500 bytes. Para la consulta Q, 3.500 de DEPARTAMENTO y 4.000 de resultado: 7.500 bytes. Como puede observarse, la segunda estrategia, aunque aparentemente es ms compleja, es mejor que la primera para los dos casos. sta estrategia se conoce como semijoin.

Proceso distribuido de consultas utilizando semijoin El resultado de utilizar en el proceso distribuido la operacin semijoin, es la reduccin de el nmero de tuplas antes de ser transferidas a otro nodo. Intuitivamente consiste en enviar la columna con la que se va a realizar el join de una relacin R al nodo donde se encuentra la otra relacin, all se realiza el join con la otra relacin S. Despus de realizar el join, se envan las columnas implicadas en el resultado al nodo inicial y se vuelve a realizar el join con R. De sta manera slo se transfieren las columnas de R que intervienen en la realizacin del join en una direccin y el subconjunto de columnas de S resultantes en la otra. Veamos como funciona en detalle para las consultas Q y Q del ejemplo anterior: 1. Para la consulta Q, proyectamos los atributos de DEPARTAMENTO que van a intervenir en la operacin de join y los transferimos al nodo 1: F: NDpto(DEPARTAMENTO), cuyo tamao resultante es 4 bytes del atributo NDpto por 100 tuplas de DEPARTAMENTO = 400 bytes transferidos. Para la consulta Q, F: Responsable(DEPARTAMENTO), cuyo tamao resultante es 9 bytes del atributo Responsable por 100 tuplas de DEPARTAMENTO = 900 bytes transferidos. 2. Para la consulta Q realizamos el join de los tuplas transferidas en el paso anterior. Del resultado de sta operacin de join, transferiremos de nuevo al nodo 1 los atributos necesarios para realizar el join final: R: Dpto,Nombre,Apellido(F * EMPLEADO) Cuyo tamao es (4 + 15 + 15) * 10.000. Es decir, 34.000 bytes transferidos. En el caso de Q, tendremos R: Responsable(F * EMPLEADO) Cuyo tamao es 9 * 100. Es decir, 900 bytes transferidos. 3. Ejecutamos los join finales para Q y Q en el nodo 2 y presentamos el resultado al usuario. Usando sta estrategia, hemos transferido un total de 340.000 bytes para Q y 1.800 bytes para Q.

Recuperacin
Vamos a estudiar ahora algunos de los problemas ms comunes que se presentan en los sistemas de bases de datos distribuidas. En los entornos distribuidos de datos podemos encontrar lo siguientes: Fallo de los nodos. Cuando un nodo falla, el sistema deber continuar trabajando con los nodos que an funcionan. Si el nodo a recuperar es una base de datos local, se debern separar los datos entre los nodos restantes antes de volver a unir de nuevo el sistema. Copias mltiples de fragmentos de datos. El subsistema encargado del control de concurrencia es el responsable de mantener la consistencia en todas las copias que se realicen y el subsistema que realiza la recuperacin es el responsable de hacer copias consistentes de los datos de los nodos que han fallado y que despus se recuperarn. Transaccin distribuida correcta. Se pueden producir fallos durante la ejecucin de una transaccin correcta si se plantea el caso de que al acceder a alguno de los nodos que intervienen en la transaccin, dicho nodo falla. Fallo de las conexiones de comunicaciones. El sistema debe ser capaz de tratar los posibles fallos que se produzcan en las comunicaciones entre nodos. El caso mas extremo es el que se produce cuando se divide la red. Esto puede producir la separacin de dos o ms particiones donde las particiones de cada nodo pueden comunicarse entre si pero no con particiones de otros nodos.

Para implementar las soluciones a estos problemas, supondremos que los datos se encuentran almacenados en un nico nodo sin repeticin. De sta manera slo existir un nico catlogo y un nico DM (Data Manager) encargados del control y acceso a las distintas partes de los datos. Para mantener la consistencia de los datos en el entorno distribuido contaremos con los siguientes elementos: Catlogo (scheduler). Programa o conjunto de programas encargados de controlar la ejecucin concurrente de las transacciones. CM (Cache Manager). Subsistema que se encarga de mover los datos entre las memorias voltiles y no voltiles, en respuesta a las peticiones de los niveles ms altos del sistema de bases de datos. Sus operaciones son Fetch(x) y Flush(x). RM (Recovery Manager). Subsistema que asegura que la base de datos contenga los efectos de la ejecucin de transacciones correctas y ninguno de incorrectas. Sus operaciones son Start, Commit, Abort, Read, Write, que utilizan a su vez los servicios del CM. DM (Data Manager). Unifica las llamadas a los servicios del CM y el RM. TM (Transaction Manager). Subsistema encargado de determinar que nodo deber realizar cada operacin a lo largo de una transaccin.

Las operaciones de transaccin que soporta una base de datos son: Start, Commit y Abort. Para comenzar una nueva transaccin se utiliza la operacin Start. Si aparece una operacin commit, el sistema de gestin da por terminada la transaccin con normalidad y sus efectos permanecen en la base de datos. Si, por el contrario, aparece

una operacin abort, el sistema de gestin asume que la transaccin no termina de forma normal y todas las modificaciones realizadas en la base de datos por la transaccin deben de ser deshechas. Una transaccin distribuida T tiene un nodo casa (el nodo en el que se origina). T es una operacin del TM del nodo casa, el cual dirigir una secuencia de operaciones a los nodos apropiados. Las operaciones Read(x) y Write(x) sern enviadas al nodo donde se encuentre x y sern procesadas por el catlogo y el DM de dicho nodo. Es resultado ser devuelto al TM del nodo casa de la transaccin T. Si consideramos el caso de una operacin commit. La terminacin de una transaccin mediante sta operacin puede involucrar varios nodos, en consecuencia, el TM del nodo casa de la transaccin deber pasar la operacin commit a todos los nodos donde la transaccin haya accedido a datos. De la misma forma, una operacin abort, puede propagarse a varios nodo de la base de datos distribuida. Por lo tanto, un proceso de transaccin, ya sea correcto o no (commit o abort), debe ser procesado en todos los nodos involucrados asegurando que la base de datos distribuida mantiene la consistencia. Protocolos ACP (Atomic Commitment Protocol) Para explicar este protocolo, asumiremos que por cada transaccin distribuida T hay un proceso en cada nodo donde T se ejecuta. Cada uno de estos procesos sern los que realizarn el ACP para T. Denominaremos coordinador al proceso del nodo casa de T y participantes a los procesos de los restantes nodos implicados. El coordinador conoce el nombre de todos los participantes y puede enviarles mensajes. Los participantes conocen el nombre del coordinador pero no necesariamente los nombres del resto de los participantes. Cada nodo contar con un DT log (Distributed Transaction log) donde tanto el coordinador como los participantes pueden recabar informacin acerca de las transacciones distribuidas. El DT log debe ser mantenido en un almacenamiento seguro porque su contenido debe sobrevivir al fallo de los nodos. En la prctica, el DT log forma parte del nodo de DM log, aunque a efectos tericos, lo consideraremos como una entidad separada. En el algoritmo de ACP, cada proceso debe emitir un voto afirmativo o negativo con lo que se podrn alcanzar una de estas dos soluciones: commit o abort. Los procesos seguirn las siguientes reglas: AC1. Todos los procesos que han tomado una decisin, han tomado la misma. AC2. Un proceso no puede dar marcha atrs en su decisin una vez tomada. AC3. La solucin commit, slo podr alcanzarse si todo los procesos votan afirmativamente.

AC4. Si no se producen fallos y todos los votos son afirmativos, la solucin ser commit. AC5. Consideremos una ejecucin de T que slo contiene fallos que el algoritmo puede subsanar. En algn punto de la sta ejecucin, si todos los fallos existentes son reparados y no se dan fallos nuevos durante el suficiente tiempo, entonces todos los procesos emitirn su decisin.

2PC (The two phase commit protocol) El 2PC es el ACP ms simple y extendido. Se basa, asumiendo que no existen fallos, en la siguiente lgica. 1. El coordinador enva una solicitud de voto (vote request) a los nodos participantes en la ejecucin de la transaccin. 2. Cuando los participantes reciben la solicitud de voto, responden enviando al coordinador un mensaje con su voto (Si o No). Si un participante vota No, la transaccin se aborta (abort). 3. El coordinador recoge los mensajes con los votos de todos los participantes. Si todos han votado Si, entonces el coordinador tambin vota si y enva un mensaje commit a todos los participantes. En otro caso, el coordinador decide abandonar y enva un mensaje abort a todos los participantes que han votado afirmativamente. 4. Cada participante que ha votado si, espera del coordinador un mensaje commit o abort para terminar la transaccin de forma normal o abortarla. El algoritmo 2PC recibe ste nombre porque se distinguen dos fases distintas, la fase de los votos (pasos 1 y 2) y la fase de decisin (pasos 3 y 4). Los participantes tienen un periodo de incertidumbre que comienza cuando envan al coordinador el voto afirmativo (paso 2) y termina cuando reciben del coordinador los mensajes de commit o abort (paso 4), sin embargo, este periodo no existe para el coordinador que vota tan pronto como decide. El algoritmo 2CP cumple con las cuatro primeras condiciones del Atomic Commitment Protocol, sin embargo, la quinta condicin no se cumple por las siguientes razones: En varios puntos del protocolo, los procesos deben esperar a recibir el correspondiente mensaje antes de continuar con sus acciones. El problema se plantea cuando un mensaje no llega debido a un fallo; en este caso los procesos se quedaran esperando indefinidamente. Para solucionar est situacin se recurre al timeout: cuando un proceso en espera es interrumpido por un timeout, dicho proceso deber realizar una accin especial, la accin timeout. De ste modo, para satisfacer la condicin quinta del ACP se deber aadir una determinada accin timeout en cada paso del protocolo en el que se espere recibir un mensaje. Cuando un proceso se recupera de un fallo, la condicin quinta de ACP requiere que el proceso intente alcanzar una decisin coherente con las decisiones de los otros procesos involucrados en la ejecucin de la transaccin. Para ello, los procesos deben guardar cierta informacin en un lugar seguro, concretamente en el DT log. Deberemos indicar qu informacin se guarda y como se puede recuperar.

You might also like