La replicación optimista , también conocida como replicación perezosa , [1] [2] es una estrategia de replicación en la que se permite que las réplicas diverjan. [3]
Los sistemas de replicación pesimistas tradicionales intentan garantizar desde el principio que todas las réplicas sean idénticas entre sí, como si hubiera una única copia de los datos desde el principio. La replicación optimista elimina esto en favor de la consistencia final , lo que significa que se garantiza que las réplicas convergerán solo cuando el sistema haya estado inactivo durante un período de tiempo. Como resultado, ya no es necesario esperar a que todas las copias se sincronicen al actualizar los datos, lo que ayuda a la concurrencia y el paralelismo . La desventaja es que las diferentes réplicas pueden requerir una conciliación explícita más adelante, lo que podría resultar difícil o incluso insoluble.
Un algoritmo de replicación optimista consta de cinco elementos:
Hay dos estrategias de propagación: transferencia de estado, donde los sitios propagan una representación del estado actual, y transferencia de operación, donde los sitios propagan las operaciones que se realizaron (esencialmente, una lista de instrucciones sobre cómo llegar al nuevo estado).
La programación y la resolución de conflictos pueden ser sintácticas o semánticas. Los sistemas sintácticos se basan en información general, como cuándo o dónde se envió una operación. Los sistemas semánticos pueden utilizar información específica de la aplicación para tomar decisiones más inteligentes. Tenga en cuenta que los sistemas de transferencia de estado generalmente no tienen información sobre la semántica de los datos que se transfieren, por lo que deben utilizar la programación sintáctica y la resolución de conflictos.
Un ejemplo conocido de un sistema basado en la replicación optimista es el sistema de control de versiones CVS , o cualquier otro sistema de control de versiones que utilice el paradigma de copia-modificación-fusión. CVS cubre cada uno de los cinco elementos:
Un caso especial de replicación es la sincronización , en la que solo hay dos réplicas. Por ejemplo, los asistentes digitales personales (PDA) permiten a los usuarios editar datos en el PDA o en una computadora y luego fusionar estos dos conjuntos de datos. Sin embargo, tenga en cuenta que la replicación es un problema más amplio que la sincronización, ya que puede haber más de dos réplicas.
Otros ejemplos incluyen:
Las aplicaciones creadas sobre bases de datos replicadas optimistas deben tener cuidado de garantizar que las actualizaciones retrasadas observadas no afecten la corrección de la aplicación.
Como ejemplo simple, si una aplicación contiene una forma de ver una parte del estado de la base de datos y una forma de editarlo, los usuarios pueden editar ese estado pero no ver que cambia en el visor. Alarmados porque su edición "no funcionó", pueden intentarlo de nuevo, posiblemente más de una vez. Si las actualizaciones no son idempotentes (por ejemplo, incrementan un valor), esto puede llevar al desastre. Incluso si son idempotentes, las actualizaciones falsas de la base de datos pueden llevar a cuellos de botella en el rendimiento, especialmente cuando los sistemas de base de datos están procesando cargas pesadas; esto puede convertirse en un círculo vicioso.
Las pruebas de aplicaciones suelen realizarse en un entorno de prueba de menor tamaño (quizás un solo servidor) y con menos carga que el entorno "en vivo". El comportamiento de replicación de una instalación de este tipo puede diferir del de un entorno en vivo de tal forma que es poco probable que se observe un retraso en la replicación durante las pruebas, lo que enmascara errores sensibles a la replicación. Los desarrolladores de aplicaciones deben ser muy cuidadosos con las suposiciones que hacen sobre el efecto de una actualización de la base de datos y deben asegurarse de simular el retraso en sus entornos de prueba.
Las bases de datos replicadas de manera optimista deben tener mucho cuidado con ofrecer características tales como restricciones de validez de los datos. Si una actualización dada puede o no aceptarse en función del estado actual del registro, entonces dos actualizaciones (A y B) pueden ser legales individualmente en relación con el estado inicial del sistema, pero una o más de las actualizaciones pueden no ser legales en relación con el estado del sistema después de la otra actualización (por ejemplo, A y B son legales, pero AB o BA son ilegales). Si A y B se inician aproximadamente al mismo tiempo dentro de la base de datos, entonces A puede aplicarse con éxito en algunos nodos y B en otros, pero tan pronto como A y B "se encuentran" y se intenta una en un nodo que ya ha aplicado la otra, se encontrará un conflicto. El sistema debe, en este caso, decidir qué actualización "gana" finalmente, y hacer que los nodos que ya han aplicado la actualización perdedora la reviertan. Sin embargo, algunos nodos pueden exponer temporalmente el estado con la actualización revertida, y puede que no haya manera de informar al usuario que inició la actualización sobre su falla, sin requerir que espere (potencialmente para siempre) la confirmación de aceptación en cada nodo.