Conclusiones

La investigación en áreas de BD es una actividad muy activa en el desarrollo informático. Esto se debe básicamente a que las aplicaciones de software actuales y las futuras requieren controlar el acceso a los datos con un índice de fiabilidad siempre creciente, a pesar de problemas de concurrencia, fallos o disponibilidad de esta información.

Los DBMS deberán seguir garantizando las propiedades de ACID de una transacción ante las posibles situaciones de fallos y operando de manera cada vez más eficiente minimizando o eliminando los problemas que puedan surgirá a partir de actualización de la información en la BDD.

La tendencia actual, además, tiende a administrar sistemas que aparecen “desconectados” o careciendo de una conexión full-time, lo que agrega un conjunto nuevo de problemas que no pueden ser tratados con los métodos clásicos empleados anteriormente.

Un objetivo con las BDD es aumentar la disponibilidad de la información, colocando la misma “cerca” del usuario. Esto significa que la replicación de la información tiende a aumentar generando más inconvenientes potenciales al momento de su actualización. Conceptos como seguridad, performance, optimización, casos de uso deben ser tenidos en cuenta cuando se plantea el esquema de distribución, y en particular el de replicación de este esquema.

Si se combinan los conceptos de replicación y aseguramiento de integridad de datos por medio de transacciones y protocolos de cometido, se puede observar que el tiempo de respuesta de estos últimos está en directa dependencia de la

cantidad de sitios de la red que contienen réplica de datos, más allá de la performance en sí del protocolo.

A continuación se describen las conclusiones generales y particulares obtenidas respecto de los esquemas de actualización y del trabajo protocolos de cometido.

Sobre los esquemas de actualización

Realizando un análisis de los resultados obtenidos y presentados en el capítulo anterior, se puede concluir que los sistemas de actualización de réplicas con esquema de propagación Lazy tienden a ser superiores en performance que los Eager. De esta forma, la escalabilidad del sistema estaría asegurada, dado que con esquemas Lazy se pueden incorporar nuevas réplicas de datos, y no afectar en demasía la performance final del sistema.

Sin embargo, no se debe perder de vista que los esquema lazy en general y utilizando el método propietario Group en particular, introducen una nueva situación posible de inconsistencia al no mantener actualizada la información “en línea”. En estos esquemas se cambia la situación de esperas e interbloqueos (deadlock) por posibilidad de inconsistencia y mecanismos de reconciliación.

Se puede argüir que bajo este esquema se contradicen las propiedades ACID definidas para una transacción. Las condiciones de atomicidad, consistencia y durabilidad son conceptos que, o bien son difíciles de lograr. o bien es directamente imposible alcanzarlos en el caso-problema real. Para analizar esto en detalle se debe repasar la idea de una transacción cometida bajo este entorno. Así, de acuerdo a las definiciones presentadas en los capítulos iniciales, una transacción cometida es aquella que ha finalizado su ejecución y que ha dejado la BD de manera consistente. Entonces, no se puede considerar una transacción como terminada hasta que no haya actualizado todas las réplicas de la BD. Bajo el esquema de actualización Lazy-Group esta condición puede demorarse, lo que obligará a mantener el bloqueo exclusivo de los datos involucrados. Este último análisis contradice las bases del esquema.

Se podría concluir de esta manera que un esquema Lazy-Group no presenta una alternativa válida para actualizar una BD (al no asegurar la preservación de consistencia y entrar en contradicción con los protocolos de metidos), sin embargo es el que mejor se adapta en performance (ver capítulo 6). Este tipo de esquema de actualización necesita de condiciones “más relajadas” para poderse llevar adelante. Es un tema de investigación abierta poder encontrar mecanismos que concilien o minimicen las situaciones de incompatibilidad que, a priori, se presentan como incompatibles.

Siguiendo con el análisis de los esquemas de actualización, Lazy- MasterSlave es ligeramente superior al esquema Eager-Master. Ambos sufren un importante incremento de situaciones de interbloqueos a medida que el grado de replicación aumenta.

Por último, e independientemente de los resultados obtenidos, el esquema

Lazy-MasterSlave parece carecer de sentido en su propia definición. A pesar que fuera analizado en el capítulo 6 para observar su performance experimental, no resulta lógico combinar una política de “actualizar al resto después” (Lazy) cuando de por sí la política propietaria trabaja de esta manera (primero el maestro y luego el resto).

Para finalizar el análisis de los mecanismos de actualización, se puede concluir que los esquemas de propagación Eager y propietario MasterSlave

resultan poco interesantes si se tiene un modelo de red donde determinados sitios aparecen parcialmente conectados (lo que comúnmente se denomina sitios o nodos móviles). El primero de ellos debido a que si una réplica reside en un nodo móvil no podrá ser actualizada “en línea” y esto demorará innecesariamente (y eventualmente por un tiempo no conocido a priori) el cometido de la transacción. El segundo aspecto en tanto, obligará a que un sitio móvil no pueda contener la copia maestra de algún dato, dado que si se encontrara desconectado no se podrían realizar actualizaciones, obligando a fallar a todas aquellas transacciones que actualicen esa información cuando el sitio no se encuentra accesible. Los problemas que surgen a partir de la utilización de sitios móviles son muy interesantes. En la sección de trabajos futuros y en el apéndice A se describen en más detalle estas situaciones con algunas consideraciones propuestas.

Sobre los protocolos de cometido

A partir de los estudios realizados y evaluados (capítulos 4 y 6) se puede concluir que los protocolos de cometido en general influyen directamente sobre la performance final del sistema de BDD. De aquí, entonces, que es necesario desarrollar protocolos que desarrollen una alta performance sobre la ejecución de las transacciones, explotando en particular, las características generales de las mismas en su entorno de utilización.

La primera comparación que se puede realizar es entre aquellos protocolos de cometido que son bloqueantes respecto de los no bloqueantes. La ventaja presentada por estos últimos no tiene relación con el overhead extra de procesamiento. En condiciones libre de fallo agregan dos mensajes extras por cada localidad donde una transacción se ejecuta. En caso de fallos del coordinador se requieren mensajes extras para seleccionar a un suplente y las ventajas solo se observan cuando el fallo de éste se produce en una situación particular. Además, por las condiciones previas del 3PC se requiere que la mitad más uno de las localidades involucradas permanezcan activas. Esta condición puede ser complicada de lograr en caso de particionamiento de la red por lo que el protocolo continuaría siendo bloqueante en esos casos.

A partir de todas las experiencias realizadas y evaluadas, alguna de ellas presentadas en el capítulo 4 y 6, y de lo expuesto anteriormente, se puede asumir que los casos de bloqueo eventual de una transacción no justifican la implementación de 3PC respecto de 2PC o sus variantes.

Los protocolos PA y PC reducen el overhead de mensajes bajo situaciones particulares. Estos protocolos han sido incorporados a DMBS comerciales para garantizar la consistencia de datos durante el procesamiento de las transacciones. Sin embargo, las situaciones analizadas permiten argumentar que PC y PA proveen beneficios tangibles respecto de 2PC solamente en algunas situaciones. PC aumenta su performance solamente cuando el grado de distribución de datos aumenta, pero en general el grado de distribución se mantiene bajo [Stamos et al., 1990]. PA, por otro lado, obtiene mejoras ante situaciones donde las transacciones fallas tienden a aumentar, en situaciones de 30% o más de fallos [Gupta et al., 1997], pero estas situaciones no son las más comunes de encontrar en casos prácticos.

Entonces, los protocolos bloqueantes surgen como ganadores contra una comparación contra protocolos no bloqueantes y el protocolo 2PC resulta en una buena opción de trabajo para ser implementada en la práctica. Ante situaciones

puntuales, el protocolo PA y PC pueden obtener mejoras potenciales ante determinadas aplicaciones y, en particular, aquellos casos donde las transacciones de solo lectura (consulta) son mayoría. [Özsu et al., 1991].

A partir de los modelos estudiados, la variante de 2PC conocida como IYV resulta mejor en performance de trabajo que PC y PA y a partir de [Chrysanthis et al., 1998] se puede concluir que IYV resultará en la mejor elección como protocolo de cometido para BDD con GBytes de información.

Para finalizar, un protocolo interesante resulta el OPT. En este, bajo suposiciones que la mayoría de las transacciones que alcanzan el estado de parcialmente cometida realmente cometen, se logra liberar los datos antes para que sean accedidos por otra transacción. De esta manera, se logra aumentar el paralelismo de las consultas permitiendo, en general, una mejor performance final del sistema.

Se considera que el ambiente de experimentación generado como parte de esta tesis representa un aporte interesante que permite evaluar bajo determinadas condiciones mecanismos de actualización de réplicas y mecanismos que aseguren integridad de la información contenida en una BDD. De esta forma se pueden simular el comportamiento del modelo de replicación y ver como afecta el mismo a la performance final del sistema.