Versionado Optimista

Versionado Optimista: Una Visión Optimista de las Transacciones

Si imaginamos el bloqueo como un sistema de reservas muy estricto, el versionado optimista es como un sistema de autopréstamo de confianza. En lugar de reservar un libro antes de leerlo, asumes que nadie más lo modificará mientras tú lo estás leyendo. Solo al finalizar la lectura, compruebas si alguien ha hecho cambios.

¿Cómo funciona?

  1. Lectura sin bloqueo: Cuando una transacción necesita leer o modificar un dato, lo hace sin adquirir ningún bloqueo. Es decir, lee la versión actual del dato en ese momento.
  2. Escritura tentativa: Los cambios se realizan sobre una copia local de los datos.
  3. Validación: Al finalizar la transacción, se compara la versión original de los datos con la versión actual. Si no ha habido cambios, la transacción se confirma y los cambios se aplican a la base de datos. Si ha habido cambios, la transacción aborta y se debe volver a iniciar.

Ventajas del Versionado Optimista

  • Alto rendimiento: Al evitar los bloqueos, se reduce la contención y se mejora el rendimiento del sistema.
  • Escalabilidad: Es ideal para sistemas distribuidos y de alta concurrencia.

Desventajas del Versionado Optimista

  • Mayor tasa de abortos: Si hay muchos conflictos, la tasa de abortos puede ser alta, lo que puede llevar a una disminución del rendimiento.
  • Mayor complejidad: La implementación del versionado optimista es más compleja que la del bloqueo.

¿Cuándo utilizar el versionado optimista?

  • Aplicaciones de alta concurrencia: Donde se espera un gran número de transacciones simultáneas.
  • Aplicaciones donde los conflictos son poco frecuentes: Si la probabilidad de que dos transacciones modifiquen los mismos datos al mismo tiempo es baja.

Comparación con el Bloqueo

CaracterísticaBloqueoVersionado Optimista
ConcurrenciaBajaAlta
RendimientoPuede ser bajo si hay muchos bloqueosAlto
ComplejidadBajaAlta
Tasa de abortosBajaPuede ser alta


Ejemplo:

Imagina que tienes dos cuentas bancarias, una de ahorros y otra corriente. Quieres transferir 100 euros de la cuenta de ahorros a la corriente.

Versionado optimista en acción:

  1. Lectura sin bloqueo:

    • El sistema lee el saldo actual de ambas cuentas. Supongamos que la cuenta de ahorros tiene 500 euros y la corriente 200 euros.

  2. Escritura tentativa:

    • El sistema realiza los cambios en una copia local de los datos:
      • Resta 100 euros a la copia del saldo de la cuenta de ahorros (quedando en 400 euros).
      • Suma 100 euros a la copia del saldo de la cuenta corriente (quedando en 300 euros).

  3. Validación:

    • El sistema vuelve a leer los saldos actuales de ambas cuentas en la base de datos.
    • Caso 1: No ha habido cambios: Si los saldos coinciden con los que leyó al principio, significa que ninguna otra transacción ha modificado las cuentas en el ínterin. En este caso, el sistema confirma la transacción y actualiza los saldos en la base de datos con los valores de la copia local.
    • Caso 2: Ha habido cambios: Si algún otro usuario ha retirado o depositado dinero en alguna de las cuentas mientras se realizaba la transacción, los saldos actuales no coincidirán con los leídos al principio. En este caso, la transacción se aborta. Esto significa que el usuario tendrá que intentar realizar la transferencia nuevamente.

¿Por qué se aborta la transacción en el caso 2?

Si se permitiera confirmar la transacción a pesar de que otros usuarios han modificado las cuentas, podría producirse una inconsistencia en los datos. Por ejemplo, si otro usuario ha retirado 50 euros de la cuenta de ahorros mientras se realizaba la transferencia, al confirmar la transacción se estaría restando 100 euros a un saldo que ya es inferior en 50 euros, lo que llevaría a un saldo negativo.

Algoritmo General para Versionado Optimista:

  1. Inicio de Transacción:

    • Asignar un identificador único a la transacción.
    • Crear una copia local de los datos que se van a modificar.

  2. Lectura de Datos:

    • Leer los valores actuales de los datos que se necesitan modificar y guardarlos en la copia local.

  3. Modificación de Datos:

    • Realizar los cambios necesarios en la copia local de los datos.

  4. Validación de Transacción:

    • Volver a leer los valores actuales de los datos en la base de datos.
    • Comparar los valores leídos con los valores originales guardados en la copia local.
    • Si no hay diferencias, la transacción es válida y se procede al siguiente paso.
    • Si hay diferencias, la transacción aborta y se debe volver a iniciar.

  5. Confirmación de Transacción:

    • Si la validación fue exitosa, se aplican los cambios de la copia local a la base de datos, reemplazando los valores antiguos por los nuevos.

  6. Fin de Transacción:

    • Liberar los recursos utilizados por la transacción.

Ejemplo en pseudo-código:

función versionado_optimista(transacción)
    identificador_transacción = generar_identificador()
    copia_local = leer_datos(transacción.datos_a_modificar)

    // Modificar la copia local
    modificar_datos(copia_local)

    valores_actuales = leer_datos(transacción.datos_a_modificar)

    si valores_actuales == copia_local.valores_originales
        escribir_datos(copia_local)
        return ÉXITO
    sino
        return FALLO
    fin_si
fin_función

Consideraciones Importantes:

  • Identificador de Transacción: Se utiliza para rastrear la transacción y detectar conflictos.
  • Copia Local: Es esencial para realizar los cambios sin afectar los datos originales hasta que se confirme la transacción.
  • Validación: La comparación entre los valores leídos y los originales es crucial para garantizar la consistencia de los datos.
  • Confirmación: Si la validación es exitosa, se deben aplicar los cambios de manera atómica para evitar que otra transacción interfiera.
  • Aborto: Si la validación falla, la transacción debe abortarse y se debe informar al usuario o al sistema.


En resumen, el versionado optimista es una técnica muy útil para mejorar el rendimiento de las bases de datos en entornos de alta concurrencia, pero es importante evaluar cuidadosamente si es la mejor opción para tu aplicación, ya que puede aumentar la tasa de abortos si los conflictos son frecuentes.


Comentarios

Publicar un comentario

Entradas más populares de este blog

Procedimientos almacenados, manejo de excepciones

¿Qué son las excepciones? Las excepciones son eventos que interrumpen el flujo normal de ejecución de un procedimiento almacenado. Pueden ser causadas por diversos motivos, como: Errores de sintaxis: Errores en la escritura del código SQL. Violaciones de integridad: Intentar insertar datos duplicados o violar restricciones de clave foránea. Conexiones fallidas: Problemas al conectar con la base de datos. Errores de autorización: No tener los permisos necesarios para realizar una operación. ¿Por qué es importante manejar las excepciones? Prevención de errores: Al manejar las excepciones, puedes evitar que el procedimiento se detenga abruptamente y cause daños en la base de datos. Información útil: Puedes proporcionar mensajes de error personalizados al usuario, lo que facilita la depuración y resolución de problemas. Continuidad del sistema: Puedes implementar lógica para recuperar de errores y continuar con la ejecución del procedimiento. Cómo manejar excepciones en pro...
Leer más

Procedimiento almacenado, manejo de transacciones

¿Qué son las transacciones? Una transacción es una secuencia de operaciones de base de datos que se tratan como una unidad de trabajo atómica. Esto significa que todas las operaciones dentro de una transacción se completan con éxito o ninguna se completa. Las transacciones garantizan la integridad de los datos, ya que evitan que la base de datos quede en un estado inconsistente. ¿Por qué son importantes las transacciones en procedimientos almacenados? Integridad de los datos: Aseguran que los datos se mantengan consistentes, incluso en caso de fallas del sistema. Atomicidad: Todas las operaciones dentro de una transacción se ejecutan como un todo único. Aislamiento: Las transacciones se ejecutan de forma aislada, evitando conflictos con otras transacciones. Durabilidad: Una vez que una transacción se confirma (commit), los cambios se hacen permanentes. Cómo administrar transacciones en procedimientos almacenados: La forma de administrar transacciones varía ligeramente entre lo...
Leer más

Procedimiento almacenado recuperación de información

SQL Server SQL CREATE PROCEDURE ObtenerTodosLosClientes AS BEGIN SELECT * FROM Clientes END Para ejecutar: SQL EXEC ObtenerTodosLosClientes PostgreSQL SQL CREATE OR REPLACE FUNCTION ObtenerTodosLosClientes() RETURNS TABLE ( id INTEGER , nombre VARCHAR , apellido VARCHAR , -- Agrega aquí el resto de las columnas de tu tabla ) AS $$ BEGIN RETURN QUERY SELECT * FROM clientes; END ; $$ LANGUAGE plpgsql; Para ejecutar: SQL SELECT * FROM ObtenerTodosLosClientes(); Oracle SQL CREATE OR REPLACE PROCEDURE ObtenerTodosLosClientes IS BEGIN FOR registro IN ( SELECT * FROM clientes) LOOP DBMS_OUTPUT.PUT_LINE(registro.id || ' ' || registro.nombre || ' ' || registro.apellido); -- Agrega aquí el resto de las columnas de tu tabla END LOOP; END ; / Para ejecutar: SQL SET SERVEROUTPUT ON ; EXECUTE ObtenerTodosLosClientes; Explicación de los ejemplos: SQL Server: El procedimiento ObtenerTodosLos...
Leer más