Database Systems Labs
Que garantiza realmente ACID, que anomalías sobreviven en cada nivel de aislamiento y como se vuelve de una caída.
5 clases · 18 horas · 24 conceptos · 15 fuentes
Esta parte se apoya en lo trabajado antes. Si vienes de fuera del programa, revisa al menos el vocabulario de:
La parte donde el programa se pone serio con la corrección. Todo lo anterior asume implícitamente que las operaciones ocurren una detrás de otra y que la máquina no se apaga. Las cinco clases de aquí retiran esas dos suposiciones y muestran qué hace falta para que el sistema siga siendo correcto sin ellas.
ACID primero, con cuidado especial en la letra que más se malinterpreta: la consistencia es respetar las restricciones declaradas, así que lo que el motor no sabe no lo protege. Después las anomalías reales y la crítica de Berenson y otros, que demuestra que los niveles de la norma no las definen sin ambigüedad —de ahí que el nivel por defecto de tu motor no sea el que crees y haya que comprobarlo experimentalmente—. Luego los dos mecanismos que sostienen el aislamiento: bloqueo, que hace esperar, y versiones, que hacen copias. Después la recuperación, con el registro anticipado y ARIES. Y al final la parte que el motor no resuelve por ti: idempotencia, reintentos y bloqueo optimista en la aplicación.
Es la parte con más laboratorio por clase del programa, y no por casualidad: las anomalías de aislamiento se creen cuando se ven ocurrir en dos sesiones abiertas al mismo tiempo.
| # | Clase | Nivel | Horas | Fuentes |
|---|---|---|---|---|
| 043 | ACID: qué garantiza cada letra y quién la implementa | Intermedio | 3 | 3 |
| 044 | Anomalías de aislamiento y la crítica a los niveles ANSI | Avanzado | 4 | 5 |
| 045 | Bloqueo en dos fases, MVCC e instantáneas | Avanzado | 4 | 3 |
| 046 | Registro anticipado y recuperación: WAL y ARIES | Avanzado | 4 | 3 |
| 047 | Concurrencia en la aplicación: idempotencia, reintentos y bloqueo optimista | Avanzado | 3 | 3 |
Qué garantiza cada letra de ACID y quién la implementa, con especial cuidado en la que más se malinterpreta: la consistencia es respetar las restricciones declaradas, así que lo que el motor no sabe no lo protege. Deja planteado que el aislamiento es la única letra que se vende por niveles.
atomicidad consistencia aislamiento durabilidad unidad de recuperación
Las anomalías reales —lectura sucia, no repetible, fantasma y sesgo de escritura— y la crítica de Berenson y otros que demuestra que los niveles de la norma no las definen sin ambigüedad. La consecuencia práctica es que el nivel por defecto de tu motor no es el que crees y hay que comprobarlo experimentalmente.
lectura sucia lectura no repetible fantasma sesgo de escritura snapshot isolation
Las dos formas de sostener el aislamiento: bloqueo en dos fases, que hace esperar, y control de versiones, que hace copias. Explica por qué con MVCC las lecturas no bloquean, y también su factura escondida: las versiones muertas que el vacuum tiene que recoger.
2PL versión de fila instantánea interbloqueo vacuum
Cómo se vuelve de una caída. El registro anticipado escribe la intención antes que el dato, el punto de control acorta la recuperación y ARIES ordena las fases de rehacer y deshacer de modo que repetirlas sea inofensivo —lo que permite recuperarse de una caída ocurrida durante la recuperación.
WAL punto de control rehacer deshacer LSN
La parte de la concurrencia que el motor no resuelve por ti. Trata la idempotencia como la única defensa realista frente a una red que no distingue «no llegó» de «se perdió la respuesta», y el bloqueo optimista y el reintento con retroceso como los dos patrones que toda aplicación con transacciones acaba necesitando.
idempotencia clave de idempotencia bloqueo optimista reintento con retroceso
Cada uno de estos es una creencia habitual y su corrección.
Los 24 términos que esta parte introduce. Todos están también en el glosario del programa con sus términos relacionados.
| Término | Qué significa | Se trabaja en |
|---|---|---|
| 2PL | Bloqueo en dos fases: una fase en la que la transacción solo adquiere cerrojos y otra en la que solo los libera. Es la técnica clásica que garantiza serializabilidad, al precio de que los lectores bloqueen a los escritores. | 045 |
| aislamiento | Grado en que una transacción concurrente no ve los pasos intermedios de otra. Es la única letra de ACID que se vende por niveles, y el nivel por defecto de casi todos los motores no es el más fuerte. | 043 |
| atomicidad | Todo o nada: la transacción se aplica entera o no deja rastro. No promete que sea correcta ni que sea rápida, solo que no habrá estados a medias visibles para nadie. | 043 |
| bloqueo optimista | En lugar de bloquear, se lee una versión y al escribir se comprueba que no haya cambiado (`WHERE version = ?`). Si cambió, se reintenta. Rinde mejor que el bloqueo cuando los conflictos son raros, y peor cuando son frecuentes. | 047 |
| clave de idempotencia | Identificador que el cliente genera y envía con la petición para que el servidor reconozca un reintento y devuelva el resultado anterior en lugar de ejecutar dos veces. Es cómo se cobra una tarjeta una sola vez aunque el navegador reenvíe. | 047 |
| consistencia | La letra tramposa de ACID: significa que la transacción lleva la base de un estado válido a otro *según las restricciones declaradas*. Lo que el motor no sabe, no lo protege; la consistencia de negocio la pone quien declara las reglas, no el gestor. | 043 |
| deshacer | Fase que revierte las transacciones que estaban a medias en el momento de la caída, usando la información de deshacer del registro. Es la implementación concreta de la atomicidad. | 046 |
| durabilidad | Una vez confirmada la transacción, su efecto sobrevive a un corte de luz. Se consigue escribiendo el cambio en un registro secuencial y forzándolo al disco antes de responder «hecho». | 043 |
| fantasma | Repetir una consulta por rango y encontrar filas nuevas que otra transacción insertó. No es un cambio de valor sino de pertenencia al conjunto, y por eso exige bloquear el rango —o usar instantáneas— y no solo las filas leídas. | 044 |
| idempotencia | Propiedad de una operación que, repetida con la misma entrada, deja el mismo estado que ejecutarla una vez. Es la única defensa realista contra las redes: en un sistema distribuido no se puede distinguir «no llegó» de «llegó y se perdió la respuesta». | 047 |
| instantánea | El conjunto de versiones visibles para una transacción, fijado en un instante. Permite que las lecturas no bloqueen y que dos consultas de la misma transacción vean exactamente lo mismo aunque el mundo cambie alrededor. | 045 |
| interbloqueo | Dos transacciones que se esperan mutuamente porque cada una tiene el cerrojo que la otra necesita. El motor lo detecta y aborta a una; la aplicación debe estar preparada para reintentar, y ordenar siempre los accesos igual reduce la frecuencia. | 045 |
| lectura no repetible | Leer la misma fila dos veces dentro de una transacción y obtener valores distintos, porque otra confirmó un cambio en medio. Es lo que `READ COMMITTED` permite y `REPEATABLE READ` impide. | 044 |
| lectura sucia | Leer un dato que otra transacción escribió y todavía no confirmó —y que puede acabar deshaciéndose—. Solo la permite el nivel `READ UNCOMMITTED`, que casi ningún motor usa por defecto. | 044 |
| LSN | Número de secuencia del registro: identifica cada entrada del WAL en orden y se estampa en la página que modifica. Permite saber, página por página, si un cambio ya está aplicado —y por eso rehacer se puede repetir sin efectos secundarios. | 046 |
| punto de control | Marca periódica que fija hasta dónde están ya volcadas a disco las páginas modificadas. Acorta la recuperación, porque tras una caída solo hay que releer el registro desde el último punto de control y no desde el principio de los tiempos. | 046 |
| rehacer | Fase de la recuperación que reaplica desde el registro todo lo confirmado que aún no había llegado a las páginas de datos. ARIES la ejecuta antes de deshacer y de forma que repetirla sea inofensiva, lo que permite recuperarse de una caída ocurrida durante la recuperación. | 046 |
| reintento con retroceso | Reintentar tras un fallo esperando cada vez más tiempo, con una componente aleatoria. El retroceso evita hundir un sistema que ya está en apuros y la aleatoriedad evita que todos los clientes vuelvan sincronizados a la vez. | 047 |
| sesgo de escritura | Dos transacciones leen el mismo conjunto, cada una decide que puede escribir, y juntas rompen un invariante que ninguna rompía por separado —los dos médicos de guardia que se dan de baja a la vez—. Snapshot isolation lo permite; hace falta serializable o un bloqueo explícito. | 044 |
| snapshot isolation | Cada transacción ve una fotografía coherente de la base tomada al empezar. Elimina lecturas sucias, no repetibles y fantasmas, pero no el sesgo de escritura; es el nivel que PostgreSQL llama `REPEATABLE READ`. | 044 |
| unidad de recuperación | La transacción como frontera de lo que se rehace o se deshace tras una caída. Es lo que conecta ACID con el registro anticipado: sin transacción no hay nada que delimite qué debe sobrevivir. | 043 |
| vacuum | Proceso que recupera el espacio de las versiones de fila que ya nadie puede ver y actualiza los mapas de visibilidad. Sin él, MVCC crece sin límite: es el mantenimiento invisible que explica por qué una tabla ocupa el triple de lo que debería. | 045 |
| versión de fila | Copia de una fila con el rango de transacciones para las que es visible. Con MVCC un `UPDATE` no sobrescribe: crea una versión nueva, de modo que quien está leyendo la anterior no se detiene. El precio es el espacio y el trabajo de limpiarlo. | 045 |
| WAL | Registro anticipado: antes de tocar la página de datos se escribe en un registro secuencial qué se va a cambiar, y ese registro se fuerza al disco antes de confirmar. Es lo que hace posible la durabilidad sin escribir cada página en cada `COMMIT`. | 046 |
15 obras distintas sostienen lo que se afirma en estas 5 clases.