Introducción a los niveles de aislamiento de transacciones

Imagina que curras en una cafetería donde un camarero revisa cuántas tartas quedan en la cocina y otro está tomando el pedido de tarta de un nuevo cliente. En un mundo ideal, los dos deberían trabajar con los mismos datos sobre el número de tartas, para evitar errores tipo "doble reserva". Pero en el mundo real pueden aparecer problemas por la ejecución en paralelo de operaciones.

Aquí tienes tres movidas principales que pueden pasar:

1. Dirty Read (lectura sucia): Una consulta ve cambios hechos por otra, pero que aún no han sido confirmados. Si esos cambios se deshacen, la primera consulta queda más perdida que un estudiante en su primera entrevista.

2. Non-Repeatable Read (lectura no repetible): Una consulta lee los mismos datos dos veces, pero entre esas lecturas alguien más los cambia. Es como ir a la estación, mirar el horario de trenes, volver al minuto — y ver que el tren fue cancelado. O que te han comprado el billete mientras buscabas la cartera :)

3. Phantom Read (lectura fantasma): Una consulta ve un subconjunto de filas, pero entre dos ejecuciones alguien mete nuevas filas que afectan al resultado. Es como si tu empresa perdiera una licitación, y luego todas las solicitudes menos la tuya y la de la esposa del alcalde fueran canceladas.

Niveles de aislamiento de transacciones

Ahora que ya sabemos de los problemas, toca mirar la herramienta que PostgreSQL nos da para solucionarlos — niveles de aislamiento de transacciones. Es como poner reglas para cómo interactúan las transacciones en paralelo. Cuanto más alto el nivel de aislamiento, más garantías de que las transacciones no se pisan entre sí. Pero ojo, esto se paga con menos "velocidad de servicio", o sea, menos rendimiento.

Niveles de aislamiento en PostgreSQL

1. Read Uncommitted (Lectura de datos no confirmados):

   • Permite leer cambios que aún no han sido confirmados (sí, esto es lectura sucia en todo su esplendor).
   • En PostgreSQL este nivel en realidad se implementa como Read Committed, así que no está soportado tal cual. PostgreSQL pasa de implementarlo porque es demasiado poco fiable.

2. Read Committed (Lectura de cambios confirmados):

   • Evita la lectura sucia.
   • La transacción solo ve los datos que han sido confirmados en el momento de ejecutar su comando.
   • Aun así pueden pasar Non-Repeatable Read y Phantom Read.

3. Repeatable Read (Lectura repetible):

   • Garantiza que los datos que lees no cambian durante la transacción.
   • Evita la lectura sucia y la lectura no repetible.
   • Pero las filas fantasma aún pueden aparecer.

4. Serializable (Serializable):

   • Garantiza que las transacciones se ejecutan como si fueran una detrás de otra, en orden.
   • Evita los tres problemas: lectura sucia, lectura no repetible y filas fantasma.
   • Es el nivel más estricto — y el más lento — de aislamiento.

¿Por qué es importante el aislamiento de transacciones?

Ahora imagina la base de datos de una tienda online donde mil usuarios intentan hacer un pedido a la vez. Sin un nivel de aislamiento bien ajustado puedes acabar con un montón de conflictos: desde productos "desaparecidos" hasta pedidos duplicados.

Elegir el nivel de aislamiento adecuado ayuda a manejar la ejecución concurrente de transacciones, equilibrando el rendimiento y la integridad de los datos. Por ejemplo:

• En sistemas de analítica suelen elegir los niveles mínimos de aislamiento (por ejemplo, Read Committed), porque la precisión de los datos no siempre es crítica.
• En sistemas financieros se prefiere el nivel Serializable, para evitar errores en cálculos o duplicados de operaciones.

Ejemplos de uso de los niveles de aislamiento

1. Read Committed

Este nivel asegura que nunca vas a leer datos que podrían haber sido deshechos.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
BEGIN;

-- Leer los datos de la cuenta.
SELECT balance FROM accounts WHERE account_id = 1;

-- Si otra transacción actualiza el balance, estos datos se actualizan al momento.
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;

COMMIT;

2. Repeatable Read

Este nivel garantiza que si lees datos, se quedan igual para ti durante toda la transacción.

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
BEGIN;

-- Leer los datos de la cuenta.
SELECT balance FROM accounts WHERE account_id = 1;

-- Incluso si otra transacción actualiza este balance, tú no verás el cambio.
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;

COMMIT;

3. Serializable

En este nivel la transacción funciona como si fuera la única en el sistema.

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
BEGIN;

-- Leer los datos de la cuenta.
SELECT balance FROM accounts WHERE account_id = 1;

-- Cualquier otra transacción que intente cambiar estos datos se quedará bloqueada hasta que termines la tuya.
UPDATE accounts SET balance = balance - 100 WHERE account_id = 1;

COMMIT;

¿Cómo elegir el nivel de aislamiento?

La elección del nivel de aislamiento depende de lo que necesites:

• Si la velocidad es más importante que la precisión, y no te importa tener filas fantasma — elige Read Committed.
• Si la precisión importa, pero aún quieres buen rendimiento — usa Repeatable Read.
• Si necesitas garantía total de que los datos son correctos, aunque sea más lento — te va Serializable.

¡Ojo! Los niveles estrictos de aislamiento pueden causar bloqueos y bajar el rendimiento del sistema. Lo sensato es buscar un equilibrio entre rendimiento y consistencia de los datos.

1

Cuestionario/control

Introducción a las transacciones, nivel 39, lección 4

No disponible

Introducción a las transacciones

Introducción a las transacciones

Abrir