Empezado por Transacciones
Arquitectura Multi-Generacional
En entornos de bases de datos, el control de la concurrencia de múltiples usuarios
a los mismos datos se ha resuelto tradicionalmente con mecanismos de bloqueos[9].
Los bloqueos se basan en establecer una prohibición de acceso (bien de escritura, o
de escritura y lectura) sobre la información que queremos proteger. El bloqueo puede
hacerse a varios niveles: a nivel de tabla, el menos selectivo, ya que bloquea todos los
registros de la tabla; a nivel de página, bloqueando varias filas de una tabla, todas las
que entren en la(s) página(s) bloqueada(s); a nivel de registro, el más selectivo y menos
restrictivo de todos. El momento en que se establece el bloqueo determina su tipo:
pesimista, si se establece en el mismo momento que accedemos a los datos a proteger;
optimista, si se establece en el momento que realmente realizamos los cambios sobre
los datos a proteger. Los bloqueos han sido, y son, utilizados por muchos gestores de
bases de datos con éxito.
InterBase adopta23 otro enfoque para enfrentarse a la situación. Este enfoque es
el denominado multiversión de registro, llamado pomposamente ”Arquitectura Multi-
Generacional” (MGA) por Borland. La multiversión[10] se basa en generar nuevas
versiones de los registros ”tocados” por cada operación de modificación o eliminación.
23 InterBase no es el primer gestor de bases de datos que lo utiliza.
Cada vez que se inserta un registro en una base de datos InterBase se almacena,
junto con los datos, una referencia a la transacción a la que está asociada la operación
de escritura. A su vez, cada transacción que tiene lugar en la base de datos, sea de es-
critura o lectura, se asocia con un identificador, un número entero. Este identificador
sigue una secuencia ascendente, de tal forma que las transacciones más antiguas tienen
identificadores más bajos que las más recientes. Cuando se modifica un registro, se ge-
nera una nueva versión del registro asociada a la transacción que lo ha modificado. Esta
nueva versión mantiene un enlace24 a la versión antigua del registro y, recíprocamente,
la versión antigua mantiene un enlace a la nueva, formando una especie de cadena.
Cuando se genera la nueva versión del registro, se compara con la versión antigua para
generar un bloque con las diferencias encontradas, denominado BDR25 . Este registro
con las diferencias entre versiones se almacena en una nueva localización en la base
de datos, y la versión nueva del registro se sitúa en el lugar que ocupada la antigua
versión. De esta forma se garantiza que el versionado de registros sólo afectará a los
campos que se han cambiado realmente, de tal forma que no se almacena por cada
versión una copia completa del registro, sólo de los campos que hayan sido cambiados
por la operación de actualización. En las eliminaciones, el BDR almacena la versión
antigua del registro, mientras que la nueva versión simplemente almacena la referencia
a la transacción que eliminó el registro y una marca de borrado.
La ventaja fundamental del mecanismo de multiversión es que permite ”proteger”
un registro sin necesidad de bloquear explícitamente el acceso al mismo. Los redactores
no impiden el acceso a los lectores, y a otros redactores sólo lo hacen en el caso de
cambios en el registro. Veamos un ejemplo:
Supongamos que hemos abierto una transacción con identificador 100 (desde ahora
t100), con la intención de modificar (update) un registro. Otro usuario, antes de apli-
car nuestros cambios al registro, inicia una transacción (t101) con el mismo objeto.
Este usuario es más rápido y aplica sus cambios antes de que lo hagamos nosotros;
su transacción (t101) se termina y queda confirmada. En la práctica esto significa que
la versión más moderna del registro tiene el identificador de la transacción t101. Pos-
teriormente, nosotros intentamos aplicar nuestros cambios y nos encontramos con un
mensaje de error del servidor, indicándonos la imposibilidad de llevar a cabo la modi-
ficación, debido a que el registro ha sufrido una alteración desde el inicio de nuestra
transacción. A esta conclusión se llega comparando nuestro identificador de transac-
ción (t100), que es menor que el indetificador de la transacción de la última versión
del registro (t101). Sin haber utilizado un bloqueo explícito del registro, la transacción
t101 ha conseguido proteger sus cambios, incluso ante una transacción iniciada con
anterioridad a ella misma. Solución: nuestra transacción (t100) debe cerrarse e iniciar
una nueva (t102) para poder aplicar sus cambios.
Las reglas[10] que siguen el comportamiento de la concurrencia visto en el ejemplo
anterior son:
Si el identificador de la transacción es menor que el indetificador de la transac-
ción de la última versión del registro, entonces la transacción no puede ver o
modificar el registro.
Si el identificador de la transacción es igual que el indetificador de la transac-
ción de la última versión del registro, entonces la transacción sí puede ver y/o
modificar el registro.
24 Puntero.
25 Back Difference Record.
Si el identificador de la transacción es mayor que el identificador de la tran-
sacción de la última versión del registro, y además esta última fue confirmada
(commit) antes de que la transacción comenzará, entonces ésta sí puede ver y/o
modificar el registro.
Siguiendo el mismo razonamiento deducimos el mecanismo empleado para dar soporte
a los diferentes niveles de aislamiento de las transacciones. Este se basa en comparar
el identificador de nuestra transacción con el de las transacciones de cada una de las
versiones de los registros. En función de que sean menores, iguales, o menores, del
estado en el que se encuentren (obtenido de las páginas TIP), y el nivel de aislamiento
de nuestra transacción, se podrá acceder a unas, u otras, versiones de cada uno de los
registros.
Las características vistas hasta ahora en el mecanismo de multiversión son realmen-
te interesantes, y constituyen un método elegante y eficaz para resolver el problema de
la concurrencia de múltiples usuarios y los diferentes niveles de aislamiento de las tran-
sacciones en bases de datos InterBase. ¿ Demasiado bonito para ser verdad ? ... cierto,
la multiversión también tiene su lado oscuro, y está precisamente ahí, en la generación
de múltiples versiones de los registros. Aunque hemos visto que en cada nueva versión
de un registro sólo se registran los cambios reales aplicados, estas nuevas versiones
pueden llegar a ocupar mucho espacio innecesariamente, además de someter a los pro-
cesos que acceden a la base de datos a una sobrecarga al tener que recorrer las cadenas
de las versiones de cada registro, seguramente muchas de estas versiones ya obsoletas.
Esta basura que genera el mecanismo de multiversión es responsable de una pérdida
gradual del rendimiento en el acceso a la base de datos, que debe ser recuperada a
través de mecanismos de limpieza, como veremos en la siguiente sección.
|