3.1.2 Control de concurrencia distribuido
Transparencia en la concurrencia
En un DBMS centralizado, esto significa que todas las transacciones que se ejecuten concurrentemente deben ejecutarse independientemente y deben estar consistentes con los resultados que se obtuvieran si las transacciones se ejecutaran una a un tiempo, en cualquier oren arbitrario. Sin embargo, el DDBMS debe asegurar la consistencia de todas las substracciones de una transacción global.
El control de concurrencia distribuido es muy importante en los ambientes de base de datos distribuidos porque las operaciones entre múltiples sitios y múltiples procesos tienen a generar inconsistencias en los datos y problemas de abrazos mortales (deadlocks) en las transacciones mas que en los ambientes de un solo sistema . Pos ejemplo, un procesador de transacciones TP Componente de un DDBMS debe asegurarse que todas las partes de la transacción en todos los sitios, se terminen satisfactoria mente antes que el COMMIT final se ejecute para comprometer la transacción
Suponga que cada operación de la transacción se compromete por cada procesador de datos DP local pero uno no puede comprometer los resultados de la transacción . Este escenario generaría un estado inconsistente. La solución a este problema se da con el Protocolo de Compromiso de dos fases
3.2.3 Protocolo Commit de dos fases Transaparencia a Fallas
En una DBMS centralizado este debe proporcionar un mecanismo de recuperación que asegure que en caso de fallas,
las transacciones deben ser atómicas y durables (ACID properties). Sin embargo en un DDBMS, este debe de poder
recuperarse en caso de fallas como perdidas de mensajes, fallas en ligas de comunicación , falla de un sitio , particionado
de red, etc . Y asegurar la atomicidad y durabilidad de transacciones globales
Las bases de datos centralizadas requieren solamente un procesador de datos (DP), todas las operaciones de base de
datos se realizan en un solo sitio , y los resultados de las operaciones en la base de datos se realizan en un solo sitio, y
los resultados de las operaciones en la base de datos son conocidas de inmediato por el DBMS . En contraste , las
base de datos distribuidas hacen posible esto a traves de que la transacción acceso a los datos en diversos sitios, un COMMIT final no debe darse hasta que todos los sitios han comprometido sus partes de la transacción
El protocolo de dos fases garantiza que si una porcion de una operación de la transaccion no pudo ser comprometida,
todos los cambios realizados en los otros sitios participantes en la transaccion seran deshechos para mantener la consistencia en el estado de la base de datos.
Cada procesador de datos tiene su propia bitaciora de transacciones (transactions log). El protocolo de dos fases requiere registrar una entrada en cada bitacora de transacciones de su procesador de datos (DP) antes de que el fragmente sea realmente actualizado. Por tanto, el protocolo requiere usar el protocolo (hacer-deshacer y rehacer) DO-UNDO-REDO y el protocolo (escritura anticipada) write-ahead
Protocolo DO-UNDO-REDO
a)Do ejecuta la correpsondiente operación y registra sus valores antes y despues de la operación (before and after
image) en la bitacora de transacciones
UNDO deshace la operación aplicando los valores anteriores guardados en la bitacora de transacciones por la fase
DO
REDOdeshace la operación aplicando los valores posteriores guardados en la bitacora de transacciones por la fase
DO
Para asegurar que las operaciones (hacer- deshacer y rehacer) puedan recuperar de una falla en el sistema cuando
requieran ejecutarse, se usa el protocolo write-ahead. Este protocolo forza que las entradas en el log de transacciones
Se guarden en disco antes que la operación tome lugar
El protocolo commits de dos fases define las operaciones entre dos tipos de nodo, el coordinador y uno o mas subordinados o conjuntos. El protocolo es implementados en dos fases
Fase de Preparacion
El coordinador manda un mensaje PREPARE COMMIT a todos los subordinados
Los subordinados reciben el mensaje , escriben en su bitacora de transacciones, usando el protocolo Writeahead y mandan un mensaje de confirmacion (acknowledge) YES o PREPARED TO COMMIT) o (NO o NOT PREPARED ) al coordinador
El coordinador se asegura que todos los nodos esten listos para comprometer la trasaccion (commit) o este abortara la transaccion .
Si todos los nodos estan preparados para comprometer su parte de la transaccion se iniciara la fase 2 . Si uno o mas
nodos no estan preparados el coordinador mandara un mensaje a todos (BROADCAST) los subordinados de
ABORT
Fase EL COMMIT FINAL
El coordinador anda mensaje a todos (BROADCAST) los subordinados de COMMIT y espera por las respuestas
Cada Subordinado recibe el mensaje COMMIT y procede a actualizar la base de datos usando el protocolo DO (hacer)
Los subordinados responden con un mensaje COMMITED o un NOT COMMITED al cordinador
Si uno o mas subordinados no comprometen su parte de la trasaccion , el coordinador manda mensaje de
ABORT , forzandolos a UNDO (deshacer) los cambios.
El objetivo del commit de dos fases es asegurarse que todos los nodos comprometieron su parte de la transaccion o la
transaccion se aborta
3.3 Transparencia de desempeño y optimizacion de consultas
Estas caracteristicas permiten al sistema tener un rendimiento como si fuera un DBMS centralizado. El sistema no
sufrira ninguna segradacion en su rendimiento derivado de su uso en una red o derivado de las diferencias en la plataforma de red. Esto aseguro que el sistema encontrara la ruta mas efectiva en costos para accesar datos remotos
Uno de las funciones de base de datos mas importantes es la disponibilidad de los datos . Si todos los datos residen
un solo sitio en una base de datos centralizada el DBMS debe evaluar todos los requerimientos de daos y encontrarla
mejor ruta de acceso a los datos locales. En contraste , los sistemas de base de datos distribuidas hacen posible
la
particion de una base de datos en varios fragmentos, entonces la traduccion de la consulta es mas complicada porque
los DDBMS deben decidir en que fragmento de la base de datos deben accesar . Ademas los datos pueden tambien
estar replicados en diferentes sitios. La replicacion de datos accesa el problema de acceso a los datos mas complejo,
porque ahora la base de datos debe decidir cual copia de los datos accesar . El DDBMS usa tecnicas de optimizacion
de consultas para lidiar con tales problemas y asegurar rendimiento en la base de datos aceptable
El Objetivo de la optimizacion de consultas es minimizar los costos totales asociados con la ejecucion de un requerimiento . Los costos asociados con el requerimiento son una funcion de:
EL costo del tiempo de acceso (I/O) requerido en accesar los datos fisicamente en disco
El costo de uso de red asociado con la transmision de los datos
El costo tiempo de procesamiento (CPU)
Dado que los costos son clasificados ya sea por comunicación o por procesamiento, no todos los algoritmos de optimizacion de consultas usan los mismos parametros para la evaluacion de costos .
Para evaluar la optimizacion de consultas, debemos tener en mente que el procesador de transacciones TP debe recibir los datos del procesador de datos DP , sincronizarlos generar la respiesta a partir de las consultas en cada sitio y presentarlas al usuario final o a la aplicación . A pesar de que este proceso es esandar, debemos considerar que una consulta en particular puede ser ejecutada en uno de los diferente sitios. El tiempo de respuesta asociado con los sitios remotos no puede ser facilmente predeterminado porque algunos nodos pueden terminar suparte de la consulta mas rapido que otros
La optimizacion de consultas en base de datos distribuidas debe ofrecer transparencia de sdistribuidas debe ofrecer transparencia de distribucion y transparencia de replica
Transparencia de replica se refiere a la habilidad del DDBMS de ocultar al usuario la existencia de multiples copias de datos
La mayoria de los algoritmos propuestos por la optimizacion de consultas estan basados en dos principios a) La selección del orden de ejecución y b) la selección de los sitios a ser accesados para minimizar los costos de uso de red . Dentro
de estos dos principios , el algoritmo de optimizacion de consultas debe ser evaluado con base de su modo de operación o el tiempo de su optimizacion.
Los modos de operación pueden se clasificados como manuales o automaticos
La optimizacion de consulta automatica significativa que el DDBMMS tiene cuidado de encontrar la ruta de acceso con el costo mas efectivo sin intervencion del usuario
La optimizacion de consulta manual requiere que la optimizacion sea selecciona y calendarizada por el usuario final o el programados
Otra clasificacion de optimizacion de consulta puede ser de acuerdo a cual optimizacion se realiza clasificacion de optimizacion dependiendo del momento en que se realiza el algoritmmo de optimizacion de consulta ser estatico o dinamico
La optimizacion de consulta estatica tiene lugar al tiempo de compilacion . Este tipo de optimizacion es comun cuando las sentencias SQL estan inmersas e un lenguaje de programacion procedural. Cuando el programa se compila, este crea el plan de acceso necesario para accesar a la base de datos. Cuando el programa es ejecutado , el DBMS usa el plan de acceso para accesar la base de datos
La optimizacion de consulta dinamica toma lugar al tiempo de ejecucion . La estrategia de acceso es definida cuando el programa es ejecutado . Por tanto la estrategia de acceso es dinamicamente determinada por el DBMS al tiempo de ejecucion usando la informacion mas actualizada acerca de la base de datos. A pesar de que la optimizacion de consultas dinamica puede ser eficiente, su costo es medido por el tiempo de ejcucion (run time processing overead). La ejor estrategia es determinada cada vez que la consulta es ejecutada, esto puede
pasar varias veces en el mismo programa
Otra clasificacion de optimizacion de consultas es dada de acuerdo al tipo de informacion que es usada para optimizar la consulta . Por ejemplo las consultas pueden estar basadas en algoritmos basados en estadisticas o en reglas
Los algoritmos basados en estadisticas usan informacion estadistica de la base datos, como el numero de registro en las tablas, tiempo de acceso promedio etc Las estadisticas pueden ser actualizadas automaticamente o manualmente
El algoritmo basado en reglas esta basado en un conjunto de reglas definidas por el usuario o el administrados de la base datos
CONCLUSIÓN: Este tipo de sistemas está formado por procesos y recursos / servicios que son
compartidos por los mismos. Para el correcto funcionamiento de los procesos es
necesario contar con mecanismos que sincronicen los procesos cooperantes, o que
controlen la utilización de recursos / servicios que sólo un número acotado de
procesos pueden utilizar en un determinado momento.
Por ende, el desarrollo de sistemas distribuidos es muy complejo, es por eso que tiene demasiada importancia este apartado.
Comentarios
Publicar un comentario