Transacciones, ACID y niveles de aislamiento

Lo que promete una transacción

Una transacción agrupa varias lecturas y escrituras en una unidad que o bien surte efecto por completo (se confirma) o bien no surte ningún efecto (se aborta y se revierte). El Capítulo 0 presentó la idea con una transferencia bancaria. Esta sección trata de la parte que la mayoría de los desarrolladores entiende mal: qué ocurre cuando se ejecutan muchas transacciones a la vez, qué garantías dan realmente las bases de datos y cómo elegir. Los ejemplos usan SQL, pero el razonamiento se aplica a cualquier almacén que ofrezca transacciones.

Las transacciones importan para la arquitectura porque deciden dónde se pueden hacer cumplir las reglas de negocio de forma barata. Dentro de una base de datos, una transacción puede mantener cuadrado un libro de cuentas o impedir que una tabla se reserve dos veces con unas pocas líneas de código. Entre servicios no existe esa herramienta, y por eso la propiedad de los datos y las sagas son tan importantes. Saber exactamente qué garantiza una sola base de datos te dice qué reglas deben quedar dentro de los límites de un único propietario.

ACID en detalle

El término ACID lo acuñaron Theo Härder y Andreas Reuter en 1983, a partir del trabajo anterior de Jim Gray. Cada letra es más restringida de lo que parece. La atomicidad tiene que ver con los fallos, no con la concurrencia: si algo sale mal a mitad de camino (una caída, la violación de una restricción, un interbloqueo, la aplicación que decide abortar), se deshace cada cambio hecho hasta ese momento, de modo que la aplicación puede reintentar con seguridad. Abortabilidad sería un nombre más preciso.

La consistencia significa que una transacción lleva la base de datos de un estado válido a otro, donde válido significa que se cumplen tus invariantes: los cargos igualan a los abonos, el stock nunca es negativo, todo pedido tiene un cliente. La base de datos puede hacer cumplir algunas invariantes por sí misma (claves, claves foráneas, restricciones CHECK, índices únicos), pero la mayoría son reglas de negocio que solo mantienen las transacciones de la aplicación. Por tanto, la consistencia es una propiedad del uso que hace la aplicación de la atomicidad y el aislamiento, no algo que la base de datos proporcione por sí sola. Tampoco tiene relación con la C de CAP, que significa linealizabilidad (Capítulo 6).

El aislamiento significa que las transacciones que se ejecutan de forma concurrente no interfieren entre sí. En su forma más estricta, la serializabilidad, el resultado de ejecutar transacciones de forma concurrente es el mismo que si se hubieran ejecutado de una en una en algún orden. Los niveles más débiles permiten cierta interferencia a cambio de rendimiento, y el resto de esta sección trata precisamente de qué interferencia. La durabilidad significa que, una vez confirmado un commit, los datos sobreviven a las caídas. Las bases de datos de un solo nodo lo consiguen con un registro de escritura anticipada (write-ahead log) que se vuelca al disco antes de que el commit retorne; las bases de datos replicadas añaden copias en otras máquinas. La durabilidad nunca es absoluta: un disco puede mentir sobre un volcado, y la replicación asíncrona puede perder las últimas escrituras confirmadas cuando falla el líder (consulta replicación).

Lo que sale mal sin aislamiento

Los bugs de concurrencia son difíciles de encontrar porque dependen del momento exacto: pasan todas las pruebas en una tranquila máquina de desarrollo y aparecen en el pico de la hora de la cena. La forma más clara de entender los niveles de aislamiento es a través de las anomalías concretas (también llamadas fenómenos) que permiten o evitan. La actualización perdida que se muestra a continuación es la más común en el código de negocio.

Los niveles de aislamiento del estándar SQL

El estándar SQL (desde SQL-92 en adelante) define cuatro niveles de aislamiento según cuáles de tres fenómenos prohíben: lecturas sucias, lecturas no repetibles y fantasmas. El estándar establece serializable como valor por defecto, pero casi ningún producto convencional lo sigue; la mayoría usa por defecto read committed o repeatable read por rendimiento.

En 1995, Hal Berenson, Phil Bernstein, Jim Gray, Jim Melton, Elizabeth O'Neil y Patrick O'Neil publicaron A Critique of ANSI SQL Isolation Levels. Demostraron que las definiciones en inglés del estándar eran ambiguas, que prohibir los tres fenómenos no proporciona por sí solo serializabilidad y que los niveles del estándar no describían los niveles de aislamiento que usaban los productos reales. Añadieron fenómenos que al estándar se le escapaban, en particular la escritura sucia, la actualización perdida, el read skew y el write skew, y definieron el aislamiento de instantánea (snapshot isolation): cada transacción lee de una instantánea coherente de los datos confirmados en el momento de su inicio, y una transacción no puede confirmar una escritura en una fila que una transacción concurrente ya ha modificado y confirmado (gana el primero que confirma). El aislamiento de instantánea evita las lecturas sucias, las lecturas no repetibles, el read skew y las actualizaciones perdidas, así como los fantasmas que afectan a las lecturas, pero permite el write skew, así que no es serializable. Encaja con dificultad entre los niveles del estándar, y por eso los productos lo etiquetan de forma distinta.

MVCC: cómo funcionan las instantáneas

La mayoría de las bases de datos modernas implementan las lecturas de instantánea con control de concurrencia multiversión (MVCC). En lugar de sobrescribir una fila en su sitio, una escritura crea una nueva versión etiquetada con el identificador de la transacción que escribe, y la versión antigua se conserva hasta que ninguna transacción en curso pueda necesitarla todavía. A cada lector se le da una instantánea, que es básicamente una lista de las transacciones que se habían confirmado cuando empezó, y solo ve las versiones que crearon esas transacciones. La gran ventaja es que los lectores nunca esperan a los escritores y los escritores nunca esperan a los lectores; solo entran en conflicto dos escritores sobre la misma fila.

El costo es el mantenimiento. Hay que limpiar las versiones antiguas: PostgreSQL las guarda en la tabla y las elimina con vacuum, mientras que Oracle y MySQL InnoDB guardan las imágenes previas en registros de deshacer (undo logs). Una transacción que se deja abierta durante horas retiene versiones antiguas, de modo que las tablas y los registros de deshacer se inflan y el rendimiento se degrada. Por eso las transacciones de larga duración son una mala señal operativa en cualquier base de datos MVCC, y un motivo para mantener las consultas analíticas fuera de la base de datos operativa. En read committed con MVCC, cada sentencia obtiene una instantánea nueva; en el aislamiento de instantánea, toda la transacción usa una sola.

Los valores por defecto reales, y por qué engañan los nombres

Los nombres de los niveles de aislamiento no son portables. La misma palabra puede significar garantías distintas en productos distintos, y los valores por defecto difieren. El proyecto Hermitage de Martin Kleppmann probó el comportamiento real de muchas bases de datos frente a las anomalías anteriores; la documentación de los fabricantes confirma los valores por defecto. Toma esta tabla como punto de partida y consulta la documentación de la versión que uses.

Cómo lograr la serializabilidad

Las bases de datos que ofrecen verdadera serializabilidad usan una de tres técnicas. La ejecución realmente en serie ejecuta las transacciones de una en una en un único hilo, lo cual es rápido si cada transacción es corta y los datos están en memoria (VoltDB, y los scripts y transacciones de Redis, funcionan así). El bloqueo en dos fases (2PL), que usan los niveles serializables de SQL Server y de MySQL, hace que los lectores tomen bloqueos compartidos y los escritores bloqueos exclusivos, incluidos bloqueos sobre rangos para impedir los fantasmas, y los mantiene hasta el final de la transacción; es correcto, pero lectores y escritores se bloquean entre sí, el throughput cae cuando hay contención y los interbloqueos son frecuentes. El aislamiento de instantánea serializable (SSI), descrito por Michael Cahill, Uwe Röhm y Alan Fekete en 2008 y usado en PostgreSQL desde la versión 9.1 (CockroachDB usa una técnica optimista relacionada), ejecuta las transacciones sobre instantáneas sin bloquear, registra las dependencias de lectura-escritura entre ellas y aborta una transacción cuando aparece un patrón peligroso.

Sea cual sea la técnica, las transacciones serializables pueden fallar con un error de serialización (SQLSTATE 40001 en PostgreSQL y CockroachDB) o con un interbloqueo, y la aplicación debe reintentar la transacción completa. Este es el costo oculto del nivel más fuerte: cada ruta de código transaccional necesita un bucle de reintentos que sea seguro repetir, lo que significa que no puede haber efectos secundarios, como enviar correos electrónicos o llamar a proveedores de pago, dentro de la transacción.

Control de concurrencia pesimista y optimista

En la práctica, la mayoría de las aplicaciones se ejecutan en read committed o repeatable read y protegen explícitamente rutas concretas de lectura-modificación-escritura. Hay tres herramientas. La mejor, cuando es posible, es una actualización atómica que deja a la base de datos hacer la aritmética y la comprobación en una sola sentencia, como UPDATE accounts SET balance = balance - 30 WHERE id = 7 AND balance >= 30, y después comprobar que ha cambiado exactamente una fila. Con read committed en PostgreSQL, una actualización concurrente hace que la segunda sentencia espere y después vuelva a evaluar su condición contra la fila nueva, así que no se pierde ninguna actualización.

Cuando la decisión necesita una lógica que la base de datos no puede expresar, usa el bloqueo pesimista: bloquea las filas que lees con SELECT ... FOR UPDATE, de modo que las transacciones concurrentes que las quieran esperen hasta que confirmes. Es sencillo y se adapta a operaciones cortas y con mucha contención (asignar un repartidor a un pedido). Los costos son la espera, el riesgo de interbloqueos (bloquea las filas en un orden coherente, por ejemplo por id ascendente) y un menor throughput. Entre las variantes están NOWAIT, que falla de inmediato en lugar de esperar, y SKIP LOCKED, que se salta las filas ya bloqueadas y es la forma habitual de construir una cola de trabajos fiable sobre una tabla relacional.

BEGIN;
-- Lock the row: other FOR UPDATE readers and writers must wait
SELECT balance FROM accounts WHERE id = 7 FOR UPDATE;
-- application checks: balance (100) >= 30, so allow it
UPDATE accounts SET balance = 70 WHERE id = 7;
INSERT INTO ledger (account_id, amount, kind)
  VALUES (7, -30, 'withdrawal');
COMMIT;  -- lock released; the waiting transaction now sees 70

El control de concurrencia optimista no toma ningún bloqueo mientras el usuario o el código está pensando. Cada fila lleva un número de versión (o una marca de tiempo o un hash). El escritor solo actualiza si la versión sigue siendo la que leyó, y la incrementa. Si no cambia ninguna fila, alguien se le adelantó, y la aplicación recarga y reintenta o se lo comunica al usuario. Esto se adapta a datos con poca contención y a un tiempo de reflexión largo: el gerente de un restaurante que edita una carta en un navegador durante cinco minutos no debe mantener un bloqueo de base de datos todo ese tiempo. HTTP incorpora la misma idea, con los ETag y la cabecera If-Match.

-- Read (no lock); remember version = 12
SELECT id, name, price, version FROM menu_items WHERE id = 501;

-- Later, write only if the version is unchanged
UPDATE menu_items
   SET price = 11.00, version = version + 1
 WHERE id = 501 AND version = 12;

-- Rows affected = 1: success.
-- Rows affected = 0: a concurrent edit won; reload and retry
-- or show the user the other change.

Cómo elegir una estrategia de aislamiento

No existe un único nivel correcto; existe un nivel correcto para cada fragmento de lógica. Un enfoque práctico parte de las invariantes, no de los ajustes.

Como regla general, read committed con bloqueo explícito o comprobaciones de versión es un valor por defecto sólido y rápido para la mayoría de las aplicaciones de negocio, siempre que el equipo sea disciplinado a la hora de encontrar las rutas de lectura-modificación-escritura. Serializable es el valor por defecto más seguro cuando las reglas son complejas, el equipo es grande o el costo de una invariante incumplida es alto (dinero, medicina, seguridad), y muchos equipos lo usan ahora en las rutas críticas, aceptando los reintentos. Los profesionales discrepan de verdad en este punto: unos sostienen que serializable por defecto evita toda una clase de bugs que la revisión de código nunca detectará; otros sostienen que sus reintentos y su contención cuestan demasiado y que el bloqueo explícito hace visible la intención. Ambas posturas son defendibles si la elección es deliberada y está probada.