Concepto ÁCIDO

3.1 Aparición de ACID

La abreviatura ACID apareció por primera vez en 1983 en un artículo de Theo Haerder y Andreas Reuter. Para simplificar el texto y hacerlo más convincente, daré una traducción de un fragmento de este artículo (con ligeras reducciones). Este fragmento utiliza un ejemplo de una transacción bancaria en la que se transfiere dinero de una cuenta a otra.

El concepto de transacción, que en el ejemplo incluye todas las interacciones con la base de datos entre $BEGIN_TRANSACTIONy $COMMIT_TRANSACTION, requiere que todas las acciones se realicen de forma indivisible: todas las acciones se reflejan correctamente en el estado de la base de datos o no sucede nada. Si en algún momento antes de llegar $COMMIT_TRANSACTIONal usuario ingresa una declaración ERRORque contiene $RESTORE_TRANSACTION, entonces no se refleja ningún cambio en la base de datos.

Para lograr esta indivisibilidad, una transacción debe tener las siguientes cuatro propiedades:

Atomicidad (Atomicidad). La transacción debe ser del tipo todo o nada descrita anteriormente, y pase lo que pase, el usuario debe saber en qué estado se encuentra la transacción.

Coherencia (Coherencia). Una transacción que llega a su final normal de transacción (EOT) y, por lo tanto, confirma sus resultados, mantiene la consistencia de la base de datos. En otras palabras, cada transacción exitosa, por definición, compromete solo resultados válidos. Esta condición es necesaria para respaldar la cuarta propiedad: la durabilidad.

Aislamiento (Aislamiento). Los eventos que ocurren dentro de una transacción deben ocultarse de otras transacciones que se ejecutan simultáneamente. Si esta condición no se cumpliera, entonces, por las razones mencionadas anteriormente, sería imposible que la transacción volviera a su inicio. Para lograr el aislamiento se utilizan métodos llamados sincronización...

Durabilidad (Durabilidad). Una vez que una transacción se ha completado y enviado sus resultados a la base de datos, el sistema debe asegurarse de que esos resultados sobrevivan a cualquier falla posterior. Dado que no existe un ámbito de control que abarque conjuntos de transacciones, el sistema de administración de bases de datos (DBMS) no tiene control más allá de los límites de las transacciones.

Por lo tanto, se debe garantizar al usuario que si el sistema le informa que algo ha sucedido, entonces ese "algo" realmente ha sucedido. Dado que, por definición, cualquier transacción (completada con éxito - S.K.) es correcta, los resultados de las transacciones incorrectas que aparecen inevitablemente (es decir, transacciones que contienen datos erróneos) solo pueden eliminarse mediante la transacción "contraria" correspondiente (contratransacción).

3.2 El surgimiento de las transacciones

Estas cuatro propiedades (Atomicidad, Consistencia, Aislamiento y Durabilidad (ACID)) describen las características principales del paradigma transaccional que afectan muchos aspectos del diseño del sistema de base de datos. Por lo tanto, creemos que la capacidad de cualquier sistema para admitir transacciones es la piedra de toque (prueba ACID) de la calidad de este sistema.

Un sencillo programa PL/1-SQL que transfiere fondos de una cuenta a otra.

FUNDS_TRANSFER. PROCEDURE,
 $BEGIN_TRANSACTION;
 ON ERROR DO;                                   /* in case of error */
          $RESTORE_TRANSACTION,                 /* undo all work */
          GET INPUT MESSAGE;                    /* reacquire input */
          PUT MESSAGE ('TRANSFER FAILED');      /* report failure */
          GO TO COMMIT;
          END;
 GET INPUT MESSAGE;                             /* get and parse input */
 EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
  AMOUNT FROM MESSAGE,
 $UPDATE ACCOUNTS                               /* do debit */
              SET BALANCE ffi BALANCE - AMOUNT
     WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
 $UPDATE ACCOUNTS                               /* do credit */
              SET BALANCE = BALANCE + AMOUNT
     WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
 $INSERT INTO HISTORY                           /* keep audit trail */
    <DATE, MESSAGE>;
 PUT MESSAGE ('TRANSFER DONE');                 /* report success */
COMMIT:                                         /* commit updates */
 $COMMIT_TRANSACTION;
 END;                                           /* end of program */

Proporcioné un ejemplo de este código para recordarle que, de hecho, las propiedades de ACID, por un lado, pueden considerarse requisitos para cualquier DBMS que pretenda admitir transacciones y, por otro lado, como la definición de una transacción en un sistema de base de datos . Esta definición es totalmente consistente con la práctica mundana. Es difícil imaginar, por ejemplo, que un cliente que realiza una transacción bancaria (ya sea con la asistencia de un cajero humano en vivo o utilizando la banca por Internet) no espere que el banco satisfaga todas las propiedades de ACID. Un banco que no apoye las propiedades de ACID para sus transacciones, en el mejor de los casos, perderá clientes y, en el peor de los casos, quebrará.

3.3 Conectividad ÁCIDO

Es muy importante que las propiedades ACID sean inseparables, descartar cualquiera de ellas hace que la combinación restante no tenga sentido. En particular, si descartamos la propiedad de consistencia (en el sentido en que se usó en la cita anterior), perderemos el criterio de corrección de una transacción. El sistema de la base de datos no podrá decidir de manera significativa si las transacciones están permitidas o no, y todas las comprobaciones de la corrección de las operaciones realizadas en el estado actual de la base de datos deberán realizarse en el código de la aplicación.

Debe comprender que en este caso estamos hablando de coherencia lógica. El cliente del banco necesita que el banco funcione de acuerdo con las reglas establecidas por él y conocidas por los clientes, de modo que sea imposible realizar cualquier transacción que viole estas reglas, para que la próxima transacción del mismo cliente se ejecute en un medio ambiente acordado de acuerdo con estas reglas.

El cliente de la tienda en línea necesita que los productos solicitados y pagados por él le sean entregados de manera oportuna (de acuerdo con las reglas establecidas y conocidas por el cliente). De lo contrario, no confiará en esta tienda. Al mismo tiempo, ni el cliente del banco ni el cliente de la tienda de Internet se preocupan por la cocina interna de la empresa, qué acciones internas se toman para completar su transacción. Al cliente no le importa cómo se mantiene la consistencia física de esta empresa, cómo se realizan las operaciones en la capa física.

Si el DBMS se encarga de mantener la consistencia lógica de las transacciones (y la base de datos), las aplicaciones se vuelven más simples, más comprensibles y más confiables. Toda la lógica del área de la aplicación (banco, tienda, almacén, etc.) en cuanto a las transacciones y el estado válido de los datos va al sistema de base de datos. Y los requisitos para este sistema son muy simples: soporte para transacciones ACID, teniendo en cuenta las reglas de consistencia proporcionadas en la base de datos por la aplicación. Desde mi punto de vista, el rechazo de las transacciones ACID crea dificultades desmesuradas para los desarrolladores de aplicaciones, quienes, les guste o no, tendrán que implementar algo similar ellos mismos para satisfacer las necesidades naturales de sus clientes.

Y una vez más observo que las propiedades ACID, de hecho, definen el concepto de una transacción. En mi opinión, para tener al menos alguna posibilidad de hablar de un sistema de gestión de datos transaccionales en el que no se admita la propiedad de consistencia transaccional, es absolutamente necesario definir qué se entiende por el término transacción en este caso.

Desafortunadamente, hoy en muchos casos (en particular, esto es característico de la dirección NoSQL), las personas hablan sobre el soporte de aplicaciones OLTP sin especificar en absoluto a qué tipo de transacciones se refieren. Por lo tanto, en este artículo, usaré la combinación transacción ACID para referirme a transacciones reales, y el término transacción sin calificar se usará en un sentido informal, diferente en diferentes contextos.

Tratemos ahora con el "teorema" de CAP y tratemos de averiguar qué significa consistencia en el sentido de Brewer.