Autor: Wonder , ingeniero senior de desarrollo de base de datos de la nube Ali

El rol del control de concurrencia de la base de datos

1.1 El concepto de asuntos

Antes de introducir el control de concurrencia, primero debe comprender las transacciones. La base de datos proporciona varias operaciones básicas, como la adición, eliminación, modificación y verificación, y los usuarios pueden combinar de manera flexible estas operaciones para lograr una semántica compleja. En muchos escenarios, los usuarios desean que un grupo de operaciones surtan efecto en conjunto, esta es una transacción. Una transacción es la unidad básica de los cambios de estado de la base de datos y contiene una o más operaciones (como múltiples sentencias SQL).

La transacción de transferencia clásica incluye tres operaciones: (1) Verifique si el saldo de una cuenta es suficiente. (2) Si es suficiente, deduzca 100 yuanes de A. (3) Agregue 100 yuanes a la cuenta B.

La transacción tiene una característica básica: este grupo de operaciones surtirá efecto en conjunto o no lo hará . Si se encuentra un error durante la ejecución de la transacción, todas las operaciones que se han realizado deben retirarse. Esta es la atomicidad de la transacción .

Si después de la falla, las transacciones parcialmente efectivas no pueden retirarse, entonces la base de datos entra en un estado inconsistente, lo cual es contrario a los hechos del mundo real. Por ejemplo, la transacción de transferencia falla después de deducir 100 yuanes de la cuenta A, y la cuenta B aún no ha aumentado la cantidad. Si la operación de deducción de la cuenta A no se ha retirado, el mundo perderá inexplicablemente 100 yuanes. La atomicidad se puede lograr mediante el inicio de sesión (el valor antes del cambio) y algunas operaciones de transacciones de la memoria caché de bases de datos localmente y, en caso de falla, descartar directamente las operaciones en la memoria caché.

Mientras se confirme la transacción, sus resultados no se pueden cambiar. Incluso si el sistema está inactivo, el estado de la base de datos después del reinicio es el mismo que antes del tiempo de inactividad. Esta es la durabilidad de la transacción .

Mientras los datos se almacenen en medios de almacenamiento no volátiles, el tiempo de inactividad no causará pérdida de datos. Por lo tanto, la base de datos puede usar los siguientes métodos para garantizar la durabilidad: (1) Antes de que se complete la transacción, se garantiza que todos los cambios se almacenarán en el disco. O (2) Antes de que se complete la confirmación, la información de cambio de la transacción se almacena en el disco en forma de registro, y el estado de la memoria del sistema de base de datos se restaura de acuerdo con el registro durante el proceso de reinicio. En términos generales, la base de datos elegirá el método (2), la razón se deja al lector para pensar.

Para mejorar la utilización de recursos y la eficiencia de ejecución de transacciones y reducir el tiempo de respuesta, la base de datos permite que las transacciones se ejecuten simultáneamente. Sin embargo, si varias transacciones operan en el mismo objeto al mismo tiempo, inevitablemente habrá conflictos. El estado intermedio de la transacción puede estar expuesto a otras transacciones, haciendo que algunas transacciones escriban un valor incorrecto en la base de datos en función del estado intermedio de otras transacciones. Existe la necesidad de proporcionar un mecanismo para garantizar que la ejecución de las transacciones no se vea afectada por las transacciones concurrentes, de modo que los usuarios sientan que actualmente solo se ejecutan las transacciones iniciadas por ellos mismos, lo cual es aislamiento .

El aislamiento permite a los usuarios centrarse en la lógica de una sola transacción, independientemente del impacto de la ejecución concurrente. La base de datos garantiza el aislamiento a través de un mecanismo de control de concurrencia. Debido a que el aislamiento requiere un mayor orden de ejecución de transacciones, muchas bases de datos ofrecen diferentes opciones, y los usuarios pueden sacrificar cierto aislamiento para mejorar el rendimiento del sistema. Estas diferentes opciones son niveles de aislamiento de transacciones .

La base de datos refleja el mundo real. Hay muchas restricciones en el mundo real. Por ejemplo: no importa cómo se transfiera la cuenta, el monto total no cambiará y otras restricciones prácticas; la edad no puede ser negativa, y el género solo puede tener tres tipos: masculino, femenino y transgénero Restricciones de integridad, como las opciones. La ejecución de la transacción no puede romper estas restricciones y garantizar que la transacción se transfiera de un estado correcto a otro estado correcto. Esto es coherencia .

La implementación de la base de datos garantiza por completo la diferencia y las tres primeras propiedades.

1.2 Cómo garantizar el aislamiento de la transacción

Para garantizar el aislamiento, una forma es ejecutar todas las transacciones en serie para que las transacciones no interfieran entre sí. Sin embargo, la eficiencia de la ejecución en serie es muy baja. Con el fin de aumentar el rendimiento y reducir el tiempo de respuesta, la base de datos generalmente permite ejecutar múltiples transacciones simultáneamente. Por lo tanto, el módulo de control de concurrencia debe garantizar que el efecto de la ejecución concurrente de las transacciones sea exactamente el mismo que el efecto de la ejecución en serie de las transacciones (serialización) para cumplir con los requisitos de aislamiento.

Para facilitar la descripción de cómo el control de concurrencia garantiza el aislamiento, simplificamos el modelo de transacción. Una transacción se compone de una o más operaciones, y todas las operaciones pueden dividirse en una serie de lecturas y escrituras. Un lote de transacciones simultáneas, todas las órdenes de ejecución de lectura y escritura, se define como una programación, por ejemplo:

T1 y T2 se ejecutan al mismo tiempo, un posible horario:

T1.read (A), T2.read (B), T1.write (A), T1.read (B), T2.write (A)

Si el efecto de programación de la ejecución concurrente de transacciones es equivalente a la ejecución en serie (programación en serie), se puede satisfacer la serialización. Una programación cambia continuamente el orden de las operaciones de lectura y escritura, y siempre se convertirá en una programación serializable, pero algunos intercambios pueden dar como resultado diferentes resultados de la ejecución de la transacción. En un cronograma, la posición de dos operaciones adyacentes cambia el resultado de la transacción, luego estas dos operaciones están en conflicto . El conflicto debe cumplir las siguientes condiciones al mismo tiempo:

Estas dos operaciones provienen de diferentes transacciones.
Al menos uno es una operación de escritura
Operar lo mismo

Por lo tanto, los conflictos comunes incluyen:

Leer y escribir conflictos. La transacción A primero lee una fila de datos, la transacción B cambia la fila de datos y la transacción B primero modifica una fila de transacciones y la transacción A lee el registro de la fila. La transacción A lee resultados diferentes. Este conflicto puede conducir a una visión de lectura no repetible y una visión de lectura sucia.
Escribir y leer conflictos. La misma razón que el conflicto de lectura-escritura. Este conflicto puede conducir a una visión de lectura sucia.
Escribe conflicto. Dos operaciones escriben un objeto en secuencia, y el resultado de la última operación determina el resultado final de la escritura. Este conflicto puede causar actualizaciones para perder la visión.

Siempre y cuando la base de datos garantice que la programación de transacciones concurrentes mantiene el orden de ejecución de las operaciones en conflicto sin cambios, solo el intercambio de operaciones no en conflicto puede convertirse en una programación en serie, y pueden considerarse equivalentes.

Este método de juicio de equivalencia se llama conflicto equivalente: la secuencia conflictiva de los dos programas es la misma . Por ejemplo, en el siguiente ejemplo, la escritura T1 (A) entra en conflicto con la lectura T3 (A), y T1 ocurre antes que T3. T1 lee (B) y T2 escribe (B) en conflicto, y T2 precede a T1, por lo que la programación ejecutada por la transacción a la izquierda es equivalente a la programación en serie (derecha) ejecutada por T2, T1 y T3. La secuencia de ejecución en la figura izquierda satisface la serialización del conflicto.

imagen

imagen .png ")

Analicemos un contraejemplo: T1 read (A) entra en conflicto con T2 write (A) y T1 precede a T2, y T2 write (A) entra en conflicto con T2 write (A) y T2 precede a T1. La siguiente programación no puede ser equivalente a ninguna programación en serie. Es una secuencia de ejecución que no cumple con la serialización del conflicto y hará que se pierda la actualización.

imagen .png ")

En general, la serialización es un requisito relativamente estricto. Con el fin de mejorar el rendimiento concurrente de los sistemas de bases de datos, muchos usuarios están dispuestos a reducir los requisitos de aislamiento para buscar un mejor rendimiento. Los sistemas de bases de datos a menudo implementan múltiples niveles de aislamiento para que los usuarios elijan con flexibilidad. Para el nivel de aislamiento de la transacción, consulte este artículo .

Los requisitos del control de concurrencia son claros, ¿cómo lograrlo? El siguiente artículo presentará los métodos comunes de implementación del control de concurrencia uno por uno de acuerdo con el optimismo de la detección de conflictos.

Control de concurrencia basado en bloqueo de dos etapas

2.1
Dado que 2PL tiene que garantizar que las operaciones se realicen en el orden correcto, la forma más fácil de pensar es bloquear y proteger el objeto de acceso. El módulo administrador de bloqueos del sistema de base de datos es específicamente responsable de bloquear y liberar bloqueos para acceder a los objetos, asegurando que solo la transacción que mantiene el bloqueo pueda operar el objeto correspondiente . Los bloqueos se pueden dividir en dos categorías: S-Lock y X-Lock. S-Lock es un bloqueo compartido utilizado para solicitudes de lectura, y X-Lock es un bloqueo exclusivo utilizado para solicitudes de escritura. Su compatibilidad es la siguiente: al operar en el mismo objeto, solo dos solicitudes de lectura son compatibles entre sí y se pueden ejecutar al mismo tiempo, y las operaciones de lectura y escritura se ejecutarán en serie debido a conflictos de bloqueo. imagen 2PL (bloqueo de dos fases) es el protocolo de control de concurrencia basado en bloqueo más común para bases de datos. Como su nombre lo indica, contiene dos fases:

Fase uno: creciendo, la transacción solicita todos los bloqueos que necesita del administrador de bloqueos (puede haber un error al bloquear).
Fase 2: Reducción, la transacción libera el bloqueo adquirido en la fase de Crecimiento, y no se permiten nuevos bloqueos.

¿Por qué las cerraduras de bloqueo y liberación deben dividirse claramente en dos etapas? El propósito del control de concurrencia 2PL es lograr serializable. Si el control de concurrencia no aplica todos los bloqueos requeridos por adelantado, pero después de liberar el bloqueo, se le permite solicitar el bloqueo nuevamente. Puede haber dos operaciones dentro de la transacción entre el mismo objeto, otras transacciones modifican esto Un objeto (como se muestra en la figura a continuación), y luego no puede alcanzar el conflicto serializable, hay inconsistencia (el siguiente ejemplo es una actualización perdida). imagen 2PL puede garantizar la serialización del conflicto, porque la transacción debe obtener todos los bloqueos necesarios para ejecutarse. Por ejemplo , la transacción A que se está ejecutando entra en conflicto con la transacción B, y la transacción B ya está ejecutada o todavía está esperando. Por lo tanto, el orden de ejecución de esas operaciones en conflicto es el mismo que el orden de ejecución de las operaciones en conflicto cuando BA o AB se ejecutan en serie. Entonces, ¿mientras la base de datos use 2PL para garantizar la consistencia y el aislamiento? Echemos un vistazo a este ejemplo: el imagen orden de ejecución anterior está en línea con 2PL, pero T2 lee datos no confirmados. Si T1 se revierte en este momento, provocará una reversión en cascada (ninguna transacción puede ver los cambios de T1). Por lo tanto, la base de datos a menudo usa una versión mejorada de S (trong) S (trict) 2PL, que es un poco diferente de 2PL: en la fase de reducción, el bloqueo solo se puede liberar después de que se complete la transacción, eliminando por completo los datos no confirmados de la transacción Fue leído.

2.2 Manejo de punto muerto

Bloquear y liberar bloqueos para transacciones concurrentes inevitablemente evitará un punto muerto problemático: la transacción 1 contiene bloqueos B, como el bloqueo A, y la transacción 2 mantiene bloqueos A, como el bloqueo B. Actualmente hay dos soluciones al problema de punto muerto:

Detección de punto muerto:

El sistema de base de datos registra la relación de espera de la transacción de acuerdo con el gráfico de espera, donde el punto representa la transacción y el borde dirigido representa que la transacción está esperando que otra transacción libere el bloqueo. Cuando aparece un anillo en el gráfico de espera, significa que se ha producido un punto muerto. El fondo del sistema detectará periódicamente el gráfico de espera. Si se encuentra un anillo, se debe seleccionar una cancelación de transacción adecuada. imagen

Prevención de punto muerto:

Cuando una transacción solicita un bloqueo que ya está retenido, el sistema de base de datos elimina una de las transacciones para evitar puntos muertos (generalmente, cuanto más dura la transacción, mayor es la prioridad de reserva). Este enfoque de precaución no requiere gráficos de espera, pero aumenta la velocidad a la que se cancelan las transacciones.

2.3 Bloqueo de intención

Si solo hay bloqueos de fila, entonces si una transacción necesita actualizar 100 millones de registros, necesita adquirir 100 millones de bloqueos de fila, lo que consumirá muchos recursos de memoria. Sabemos que los bloqueos se utilizan para proteger los objetos de acceso interno de la base de datos. Estos objetos pueden ser: Atributo, Tupla, Página, Tabla. Los bloqueos correspondientes se pueden dividir en bloqueos de fila y páginas. Bloqueos, bloqueos de tabla (nadie implementa bloqueos de atributos. Para bases de datos OLTP, la unidad de operación más pequeña es una fila). Por supuesto, para las transacciones, es mejor obtener el menor número de bloqueos, como actualizar 100 millones de registros, tal vez agregar un bloqueo de tabla sea suficiente. Los bloqueos de nivel superior (como los bloqueos de tabla) pueden reducir efectivamente el uso de recursos y reducir significativamente el número de comprobaciones de bloqueo, pero limitarán severamente la concurrencia. Los bloqueos de nivel inferior (como los bloqueos de fila) conducen a la ejecución concurrente, pero en el caso de muchos objetos de solicitud de transacción, se requiere una gran cantidad de comprobaciones de bloqueo. Para resolver el problema de la concurrencia de limitación de bloqueo de alto nivel, el sistema de base de datos introduce el concepto de bloqueo de intención:

Intención compartida (IS): indica que uno o más objetos están protegidos por S-Lock. Por ejemplo, una tabla más IS, al menos una fila de la tabla está protegida por S-Lock.
Exclusión intencional (IX): indica que uno o más objetos están protegidos por X-Lock. Por ejemplo, una tabla más IX, al menos una fila de la tabla está protegida por X-Lock.
Shared + Intention-Exclusive (SIX): indica que al menos un objeto en el interior está protegido por X-Lock, y en sí está protegido por S-Lock. Por ejemplo, una operación requiere un escaneo completo de la tabla, y cambia algunas filas en la tabla, puede agregar SIX a la tabla. Los lectores pueden pensar por qué no hay XIX o XIS

La relación de compatibilidad entre los bloqueos de intención y los bloqueos normales es la siguiente: imagen La ventaja de los bloqueos de intención es que cuando IX se agrega a la tabla, significa que hay filas en la tabla que se están modificando. (1) En este momento, la operación DDL se inicia en la tabla y se debe solicitar el bloqueo X de la tabla. Luego, cuando la tabla contiene IX, espera directamente sin verificar si las filas en la fila de retención de la tabla se bloquean una por una, reduciendo efectivamente la sobrecarga de inspección . (2) En este momento, hay otras transacciones de lectura y escritura. Dado que la tabla se agrega IX en lugar de X, no impedirá las solicitudes de lectura y escritura para la fila (primero agregue IX a la tabla y luego agregue S / X al registro) Si la transacción no involucra la fila bloqueada en X, se puede ejecutar normalmente, aumentando la concurrencia del sistema. 03

Control de concurrencia basado en el orden de tiempo (T / O)

Asigne una marca de tiempo a cada transacción y úsela para determinar el orden de ejecución de la transacción. Cuando la marca de tiempo de la transacción 1 es menor que la transacción 2, el sistema de base de datos debe garantizar que la transacción 1 se ejecute antes de la transacción 2. Los métodos de distribución de marca de tiempo incluyen: (1) reloj físico; (2) reloj lógico; (3) reloj mixto.

3.1 T / O básico

Basado en el control de concurrencia de T / O, no se requiere bloqueo para leer y escribir, y cada fila de registro marca la marca de tiempo de la transacción que se modificó y leyó por última vez . Cuando la marca de tiempo de la transacción es menor que la marca de tiempo registrada (no puede leer los datos "futuros"), debe anularse y volver a ejecutarse. Suponga que el registro X está marcado con dos marcas de tiempo de lectura y escritura: WTS (X) y RTS (X), la marca de tiempo de la transacción es TTS y el juicio de visibilidad es el siguiente: leer:

TTS <WTS (X): el objeto no es visible para la transacción, cancela la transacción, toma una nueva marca de tiempo y comienza de nuevo.
TTS> WTS (X): este objeto es visible para la transacción, actualice RTS (X) = max (TTS, RTS (X)). Para satisfacer la lectura repetible, la transacción copia el valor de X.
Para evitar que se lean datos sucios, se pueden hacer marcas especiales en el registro. La solicitud de lectura debe esperar a que se envíe la transacción antes de leer.

Escribir:

TTS <WTS (X) || TTS <RTS (X): cancelar transacción, reiniciar.
TTS> WTS (X) && TTS> RTS (X): Actualización de transacción X, WTS (X) = TTS.

La razón por la cual se requiere TTS> RTS (X) aquí es para evitar la siguiente situación: la marca de tiempo de la solicitud de lectura es rts, X se ha leído y la marca de tiempo se establece en RTS (X) = rts. ), Y la actualización es exitosa, la solicitud de lectura rts se lee nuevamente para ver los nuevos cambios, lo que viola la lectura repetible, por lo que esto es para evitar conflictos de lectura y escritura. El último tiempo de lectura y escritura se almacena en el registro, lo que puede garantizar que el conflicto serializable también pueda evitar el sesgo de escritura.Por ejemplo: el estado inicial, los registros X e Y, X = -3, Y = 5, X + Y> 0, RTS (X) = RTS (Y) = WTS (X) = WTS (Y) = 0. La marca de tiempo de la transacción T1 es TTS1 = 1, y la marca de tiempo de la transacción T2 es TTS2 = 2. imagen .png ") Sus defectos incluyen:

Las transacciones largas son propensas a morir de hambre, porque la marca de tiempo de las transacciones largas es demasiado pequeña, y existe una alta probabilidad de que los datos actualizados se lean después de un período de ejecución, lo que resulta en aborto.
Las operaciones de lectura también generan escrituras (escribir RTS).

Control de concurrencia basado en validación (OCC)

Durante el proceso de ejecución, cada transacción mantiene su propia operación de escritura (T / O básico escribe datos en la base de datos durante la ejecución de la transacción) y el RTS / WTS correspondiente, y juzga si se envían sus cambios y los existentes en la base de datos Conflictos de datos, escriba a DB si no hay conflicto. OCC se divide en tres etapas:

Fase de lectura y escritura: la fase de lectura y escritura, la transacción mantiene los resultados de lectura y los próximos cambios, así como los registros escritos de RTS y WTS.
Fase de validación: compruebe si la transacción entra en conflicto con los datos de la base de datos.
Fase de escritura: escriba sin conflicto, conflicto, aborto, reinicio.

La fase de lectura y escritura ha terminado, e ingresar a la fase de validación es equivalente a completar la preparación de la transacción e ingresar a la fase de confirmación. El tiempo para ingresar a la fase de validación se selecciona como la marca de tiempo de la línea de registro para secuenciar. La razón por la cual no se usa el tiempo de inicio de la transacción es que: el tiempo de ejecución de la transacción puede ser más largo, y la transacción que comienza más tarde se puede enviar primero, lo que aumentará la probabilidad de conflicto de la transacción. Las transacciones con marcas de tiempo más pequeñas se escribirán en la base de datos después de la transacción, y definitivamente abortarán.

Proceso de validación

Suponiendo que solo hay dos transacciones T1 y T2, y se modifica la misma fila de datos, la marca de tiempo de T1 <la marca de tiempo de T2 (es decir, el orden de validación: T1 <T2, para los usuarios, T1 ocurre primero en T2), hay Situación: (1) T1 está en la fase de validación, y T2 todavía está en la fase de lectura y escritura. En este momento, siempre que no haya conflicto entre la lectura y la escritura que se haya producido en T1 y T2, puede enviar.

Si WS (T1) ∩ (RS (T2) ∪ WS (T2)) = ∅, significa que no hay conflicto entre los registros escritos por T2 y T1, y la verificación se puede escribir.
De lo contrario, hay un conflicto de lectura-escritura o un conflicto de escritura-escritura entre T2 y T1, y T1 necesita revertirse. Conflictos de lectura y escritura: T2 lee la versión anterior a la escritura de T1. Después de que T1 se compromete, puede leer la versión escrita por T1, que no puede leerse repetidamente. Conflictos de escritura y escritura: T2 puede actualizarse según la versión anterior y volverse a escribir, lo que hace que se pierda la actualización de T1.

(2) T1 completa la fase de validación y entra en la fase de escritura hasta que se completa el envío, que ya es irreversible. La lectura y escritura de T2 antes de que T1 entre en la fase de escritura no debe entrar en conflicto con la operación de T1 (porque la validación de T1 pasó). Las operaciones de lectura y escritura continuadas después de que T2 pueden entrar en conflicto con la operación que debe enviar T1, por lo que T2 ingresa a la etapa de validación:

Si WS (T1) ∩ RS (T2) = ∅, significa que T2 no ha leído el registro escrito por T1, se pasa la verificación y T2 puede escribir. (¿Por qué no verificar WS (T2)? WS (T1) se ha enviado y su marca de tiempo es menor que WS (T2). No debe haber conflicto en la parte anterior de WS (T2) y en la siguiente, porque no se ha leído El objeto escrito por T1 está bien para escribir, y no sobrescribirá la escritura de WS (T1))
De lo contrario, hay un conflicto de lectura y escritura y un conflicto de escritura y escritura entre T2 y T1, y T2 debe revertirse. Conflictos de lectura y escritura: T2 lee la versión anterior a la escritura de T1. Después de que T1 se compromete, puede leer la versión escrita por T1, que no puede leerse repetidamente. Conflictos de escritura y escritura: T2 puede actualizarse según la versión anterior y volverse a escribir, lo que hace que se pierda la actualización de T1.

Control de concurrencia basado en MVCC

La base de datos mantiene múltiples versiones físicas de un registro. Cuando se escribe una transacción, se crea una nueva versión de los datos escritos, y la solicitud de lectura obtiene la última versión de los datos que ya existe en ese momento en función de la información de la instantánea al comienzo de la transacción / extracto. Los beneficios más directos que trae son: la escritura no bloquea la lectura, la lectura no bloquea la escritura y las solicitudes de lectura nunca fallarán debido a conflictos (como la versión única T / O) o esperar (como la versión única 2PL). Para las solicitudes de base de datos, a menudo hay más solicitudes de lectura que solicitudes de escritura. Casi todas las bases de datos principales usan esta tecnología de optimización. MVCC es una tecnología de optimización para solicitudes de lectura y escritura. No resuelve completamente el problema de concurrencia de la base de datos. Debe combinarse con las varias tecnologías de control de concurrencia antes mencionadas para proporcionar capacidades completas de control de concurrencia. Los tipos comunes de tecnologías de control de concurrencia incluyen: MV-2PL, MV-T / O y MV-OCC, sus características son las siguientes: imagen .png ") MVCC también tiene dos puntos clave a considerar: almacenamiento de datos de múltiples versiones y redundante Reciclaje de los datos de la versión. Los métodos de almacenamiento de datos de múltiples versiones se pueden dividir aproximadamente en dos categorías: (1) Método de solo anexar, las versiones antiguas y nuevas se almacenan en el mismo espacio de tabla, como el motor de almacenamiento basado en el árbol LSM. (2) Espacio de tabla principal Registre la última versión de los datos, la imagen anterior se registra en otros espacios de tablas o segmentos de datos, como la información de múltiples versiones de InnoDB se registra en el registro de deshacer. La recopilación de datos de múltiples versiones también se conoce como recolección de basura (GC), aquellas que no tienen posibilidad de ser recuperadas por ninguna solicitud de lectura las versiones anteriores de los registros, se deben extirpar inmediatamente. 06

Resumen

Este artículo presenta transacciones basadas en bloqueos (evitando conflictos antes del inicio de las transacciones), T / O (juzgando conflictos durante la ejecución de la transacción) y Validación (verificando conflictos cuando se confirman las transacciones) en función del momento del manejo del conflicto (optimismo) Mecanismo de control de concurrencia. Las diferentes implementaciones son adecuadas para diferentes cargas de trabajo, y las cargas de trabajo con bajos conflictos de concurrencia ciertamente son adecuadas para métodos de control de concurrencia más optimistas. MVCC puede resolver el problema del bloqueo mutuo entre transacciones de solo lectura y transacciones de lectura-escritura, mejorar la lectura concurrente de transacciones y es adoptado por la mayoría de los sistemas de bases de datos convencionales.