El control de concurrencia multiversión ( MCC o MVCC ), es un método de control de concurrencia sin bloqueo comúnmente utilizado por los sistemas de gestión de bases de datos para proporcionar acceso concurrente a la base de datos y en los lenguajes de programación para implementar la memoria transaccional . [1]
Sin control de concurrencia, si alguien lee una base de datos al mismo tiempo que otra persona escribe en ella, es posible que el lector vea un dato a medio escribir o inconsistente . Por ejemplo, al realizar una transferencia bancaria entre dos cuentas bancarias, si un lector lee el saldo en el banco cuando el dinero se retiró de la cuenta original y antes de ser depositado en la cuenta de destino, parecería que el dinero ha desaparecido de la cuenta. banco. El aislamiento es la propiedad que proporciona garantías en los accesos concurrentes a los datos. El aislamiento se implementa mediante un protocolo de control de concurrencia . La forma más sencilla es hacer que todos los lectores esperen hasta que el escritor termine, lo que se conoce como bloqueo de lectura-escritura . Se sabe que los bloqueos crean contención , especialmente entre transacciones de lectura larga y transacciones de actualización. MVCC tiene como objetivo resolver el problema manteniendo múltiples copias de cada elemento de datos. De esta manera, cada usuario conectado a la base de datos ve una instantánea de la base de datos en un instante particular. Cualquier cambio realizado por un escritor no será visto por otros usuarios de la base de datos hasta que se hayan completado (o, en términos de la base de datos: hasta que se haya confirmado la transacción ).
Cuando una base de datos MVCC necesita actualizar un dato, no sobrescribirá el elemento de datos original con datos nuevos, sino que creará una versión más nueva del elemento de datos. Por tanto, hay múltiples versiones almacenadas. La versión que ve cada transacción depende del nivel de aislamiento implementado. El nivel de aislamiento más común implementado con MVCC es el aislamiento de instantáneas . Con el aislamiento de instantáneas, una transacción observa el estado de los datos desde el momento en que comenzó la transacción.
MVCC proporciona vistas consistentes en un momento dado . Las transacciones de lectura en MVCC suelen utilizar una marca de tiempo o un ID de transacción para determinar qué estado de la base de datos leer y leer estas versiones de los datos. De este modo, las transacciones de lectura y escritura quedan aisladas entre sí sin necesidad de bloquearlas. Sin embargo, a pesar de que los bloqueos son innecesarios, algunas bases de datos MVCC como Oracle los utilizan. Las escrituras crean una versión más nueva, mientras que las lecturas simultáneas acceden a una versión anterior.
MVCC presenta el desafío de cómo eliminar versiones que quedan obsoletas y nunca serán leídas. En algunos casos se implementa un proceso para barrer y eliminar periódicamente las versiones obsoletas. Suele ser un proceso de parada mundial que recorre una tabla completa y la reescribe con la última versión de cada elemento de datos. PostgreSQL puede utilizar este enfoque con su proceso VACUUM FREEZE. Otras bases de datos dividen los bloques de almacenamiento en dos partes: la parte de datos y un registro de deshacer. La parte de datos siempre mantiene la última versión confirmada. El registro de deshacer permite la recreación de versiones anteriores de datos. La principal limitación inherente de este último enfoque es que cuando hay cargas de trabajo que requieren mucha actualización, la parte del registro de deshacer se queda sin espacio y luego las transacciones se cancelan porque no se les puede proporcionar su instantánea. Para una base de datos orientada a documentos, también permite que el sistema optimice los documentos al escribir documentos completos en secciones contiguas del disco; cuando se actualiza, el documento completo se puede reescribir en lugar de recortar fragmentos o mantener en una base de datos vinculada, no estructura de base de datos contigua.
MVCC utiliza marcas de tiempo ( TS ) e ID de transacciones incrementales para lograr coherencia transaccional . MVCC garantiza que una transacción ( T ) nunca tenga que esperar para leer un objeto de base de datos ( P ) manteniendo varias versiones del objeto. Cada versión del objeto P tiene una marca de tiempo de lectura ( RTS ) y una marca de tiempo de escritura ( WTS ) que permite que una transacción particular Ti lea la versión más reciente del objeto que precede a la marca de tiempo de lectura RTS ( T i ) de la transacción.
Si la transacción Ti quiere escribir en el objeto P , y también hay otra transacción T k sucediendo al mismo objeto, la marca de tiempo de lectura RTS ( T i ) debe preceder a la marca de tiempo de lectura RTS ( T k ), es decir, RTS ( T i ) < RTS ( T k ) [ se necesita aclaración ] , para que la operación de escritura del objeto ( WTS ) tenga éxito. Una escritura no se puede completar si hay otras transacciones pendientes con una marca de tiempo de lectura ( RTS ) anterior al mismo objeto. Al igual que hacer cola en la tienda, no puede completar su transacción de pago hasta que los que están frente a usted hayan completado la suya.
Para reafirmar; cada objeto ( P ) tiene una marca de tiempo ( TS ), sin embargo, si la transacción Ti quiere escribir en un objeto y la transacción tiene una marca de tiempo ( TS ) anterior a la marca de tiempo de lectura actual del objeto, TS ( T i ) < RTS ( P ), luego la transacción se cancela y se reinicia. (Esto se debe a que una transacción posterior ya depende del valor anterior). De lo contrario, Ti crea una nueva versión del objeto P y establece la marca de tiempo de lectura/escritura TS de la nueva versión en la marca de tiempo de la transacción TS ← TS ( T i ). [2]
El inconveniente de este sistema es el costo de almacenar múltiples versiones de objetos en la base de datos. Por otro lado, las lecturas nunca se bloquean, lo que puede ser importante para cargas de trabajo que implican principalmente la lectura de valores de la base de datos. MVCC es particularmente hábil en implementar un verdadero aislamiento de instantáneas , algo que otros métodos de control de concurrencia frecuentemente hacen de manera incompleta o con altos costos de rendimiento.
En Tiempo = 1, el estado de una base de datos podría ser:
T0 escribió el Objeto 1="Foo" y el Objeto 2="Bar". Después de eso, T1 escribió el Objeto 1="Hola" dejando el Objeto 2 en su valor original. El nuevo valor del Objeto 1 reemplazará el valor en 0 para todas las transacciones que comiencen después de la confirmación T1, momento en el que la versión 0 del Objeto 1 se puede recolectar como basura.
Si una transacción T2 de larga ejecución inicia una operación de lectura del Objeto 2 y el Objeto 1 después de que T1 se comprometa y hay una transacción de actualización concurrente T3 que elimina el Objeto 2 y agrega el Objeto 3="Foo-Bar", el estado de la base de datos se verá así en tiempo 2:
Hay una nueva versión a partir del momento 2 del Objeto 2 que está marcado como eliminado y un nuevo Objeto 3. Dado que T2 y T3 se ejecutan simultáneamente, T2 ve la versión de la base de datos anterior a 2, es decir, antes de las escrituras confirmadas de T3, como tal, T2 lee el Objeto 2. ="Barra" y Objeto 1="Hola". Así es como el control de concurrencia multiversión permite lecturas de aislamiento de instantáneas sin ningún bloqueo.
El control de concurrencia multiversión se describe con cierto detalle en el artículo de 1981 "Concurrency Control in Distributed Database Systems" [3] de Phil Bernstein y Nathan Goodman, entonces empleados de Computer Corporation of America . El artículo de Bernstein y Goodman cita una disertación de 1978 [4] de David P. Reed que describe con bastante claridad MVCC y lo afirma como un trabajo original.
El primer producto de software de base de datos comercial de envío con MVCC fue VAX Rdb/ELN , lanzado en 1984, [5] y creado en Digital Equipment Corporation por Jim Starkey . Starkey continuó [6] creando la segunda base de datos MVCC comercialmente exitosa: InterBase . [7]