La diferencia entre atomicidad y coherencia en las transacciones de bases de datos

Lo interesante de esta pregunta no es la pregunta en sí ("¿Cuáles son los mecanismos para lograr la atomicidad y la consistencia?"), sino otra cuestión reflejada en el desacuerdo entre los encuestados: la atomicidad ¿Cuál es la relación entre consistencia y consistencia?

Presté especial atención a la respuesta de @我在心修

. Señaló correctamente que para garantizar la atomicidad de las operaciones de transacción, es necesario implementar un registro. Mecanismo REDO/UNDO basado en Pero esta respuesta aún está incompleta porque la atomicidad no garantiza completamente la coherencia.

Según mi entendimiento personal, entre los atributos ACID del procesamiento de transacciones, la coherencia es el atributo más básico y los otros tres atributos existen para garantizar la coherencia.

Primero revise la definición de coherencia. Por coherencia queremos decir que los datos se encuentran en un estado significativo, que es más semántico que sintáctico. El ejemplo más común es la transferencia de dinero. Por ejemplo, si transfiere una suma de dinero de la cuenta A a la cuenta B y el dinero en la cuenta A disminuye pero el dinero en la cuenta B no aumenta, entonces consideramos que los datos son inconsistentes en este momento.

En

escenarios de implementación de bases de datos, la coherencia se puede dividir en coherencia fuera de la base de datos y coherencia dentro de la base de datos. Lo primero está garantizado por la codificación de la aplicación externa, es decir, la aplicación que realiza una operación de base de datos en la transferencia debe llamar la operación en la Cuenta A y la Cuenta B en la misma transacción. Si algo sale mal en este nivel, la base de datos por sí sola no puede solucionarlo, y eso está más allá del alcance de lo que necesitamos discutir. Esto último está garantizado por la base de datos, es decir, un conjunto de operaciones en la misma transacción deben tener éxito (o todas fallar). Ésta es la atomicidad del procesamiento de transacciones.

Para lograr la atomicidad, es necesario registrar:

Todas las operaciones de actualización de los datos se escribirán en el registro si parte de una transacción se ha ejecutado con éxito, pero. las operaciones posteriores se interrumpen debido a Si un corte de energía/caída del sistema/otros errores de software y hardware impiden que el usuario continúe, entonces a través del registro de rastreo, las operaciones ejecutadas exitosamente se pueden retirar

para que "las operaciones más comunes La situación es que el sistema de la base de datos se debe a un corte de energía/caída del sistema. La situación más común es que el sistema de la base de datos falla y se reinicia debido a otros errores de software y hardware. En este momento, la base de datos se encuentra en un estado inconsistente y debe hacerlo. Primero realice el proceso de recuperación de fallas: lea el registro de REDO (reproduzca todas las operaciones que se ejecutaron exitosamente pero que aún no se escribieron en el disco para garantizar la durabilidad) y luego lea todas las transacciones que no se confirmaron exitosamente en el momento de la falla.

DESHACER (deshacer todas las operaciones parcialmente ejecutadas pero aún no confirmadas para garantizar la durabilidad) para garantizar la atomicidad

Al final de la recuperación, la base de datos se restaura a un estado consistente y puede continuar.

Administrar y volver a ejecutar el registro es la parte más compleja de la implementación de la base de datos 1. Si se trata de procesamiento paralelo y sistemas distribuidos (la replicación y reproducción del registro son la base de la alta disponibilidad de la base de datos). , Puede ser mucho más complicado que la situación anterior.

Sin embargo, la atomicidad no garantiza completamente la coherencia. En el caso de que se ejecuten múltiples transacciones en paralelo, incluso si cada transacción garantiza la atomicidad, aún puede generar resultados. a resultados de datos inconsistentes, por ejemplo, la transacción 1 necesita transferir $100 a la cuenta A: primero lee el valor de la cuenta A y luego agrega $100 a este valor. El resultado final debería ser que la cuenta A haya aumentado en $200. de hecho, cuando la Transacción 1 finalmente se completa, la Cuenta A solo ha aumentado $100 porque las modificaciones de la Transacción 2 fueron sobrescritas por la Transacción 1.

Para garantizar la coherencia en situaciones concurrentes, se introduce aislamiento, lo que garantiza que los datos visibles para cada transacción es siempre el mismo que si no existieran otras transacciones concurrentes. Esto significa que el estado después de que se ejecutan múltiples transacciones al mismo tiempo es equivalente al estado después de que se ejecutan en serie. Muchas personas han dado respuestas sobre cómo implementar el aislamiento. En principio, solo existen dos tipos de bloqueos:

Uno.

Es un bloqueo pesimista, es decir, la transacción actual bloquea todos los objetos involucrados en la operación y luego los libera. objetos para uso de otros objetos una vez completada la operación.

Para maximizar el rendimiento, la gente ha inventado varias granularidades (nivel de base de datos/nivel de tabla/nivel de fila)/varias

propiedades (***disfrutar de bloqueos/bloqueos exclusivos/***disfrutar de bloqueos de intención/intención exclusiva lock/*** Un candado que disfruta de un bloqueo de intención exclusivo). Para resolver el problema del punto muerto, la gente ha inventado una serie de tecnologías, como el protocolo de bloqueo de dos fases/detección de punto muerto.

Uno es el bloqueo optimista, lo que significa que diferentes transacciones pueden ver diferentes versiones históricas del mismo objeto (generalmente una fila de datos) al mismo tiempo. Si dos transacciones modifican la misma fila de datos al mismo tiempo, la detección de conflictos se realizará cuando se confirme la transacción posterior. También hay dos métodos de implementación, uno es obtener la versión histórica de la fila de datos a través del registro UNDO y el otro es simplemente mantener múltiples versiones históricas de la misma fila de datos en la memoria y distinguirlas por marcas de tiempo.

Los bloqueos son también una de las partes más complejas de la implementación de una base de datos. De manera similar, cuando se trata de sistemas distribuidos (los bloqueos distribuidos y el compromiso de dos fases son la base de las transacciones distribuidas), la complejidad puede exceder con creces los escenarios de aplicación anteriores.

@

Practico desde el corazón

Mencione que otros entrevistados en realidad estaban hablando sobre la comprensión del sistema operativo sobre la atomicidad, es decir, el control de concurrencia. No puedo estar completamente de acuerdo con esta afirmación. Las bases de datos tienen sus propios problemas de control de concurrencia y bloqueo, y aunque en principio son muy similares a las de los sistemas operativos, no están al mismo nivel. Los bloqueos en una base de datos son completamente diferentes en granularidad/tipo/implementación que los bloqueos en un sistema operativo. Los bloqueos en los sistemas operativos se denominan pestillos en las implementaciones de bases de datos. La pregunta respondida por otros encuestados fue en realidad "Cómo garantizar la coherencia de los datos en transacciones paralelas".

Finalmente, volveré a la pregunta original ("¿Cuál es el mecanismo para lograr atomicidad y consistencia?"). Tengo un libro "Base de datos

Sistema

Concepts" (4ed, un poco antiguo), donde el Capítulo 15 comienza con una introducción concisa a los conceptos de ACID y sus relaciones. Si desea comprender su implementación conceptualmente, debería poder obtener uno leyendo los capítulos relevantes de este libro. Concepto aproximado Si desea saber cómo se implementa realmente, puede encontrar el código fuente de un motor de código abierto como innodb y leerlo. Sin embargo, incluso una implementación de código abierto muy aproximada (que no tiene en cuenta lo demasiado complejo). procesamiento paralelo) Sistemas distribuidos, sin tener en cuenta la optimización de los sistemas operativos y hardware, etc.), puede que no lleve uno o dos años entenderlo básicamente.