transactions - transacciones - ¿Qué constituye una capa de transacción cuando se habla de sistemas de bases de datos?

transacciones en base de datos ejemplos (2)

Dado que su base de datos tiene un solo hilo, puede hacer lo siguiente:

Uso de la característica de lote leveldb: en lugar de anular la clave anterior, cree una nueva. También registre el valor antiguo y nuevo de la clave.
Si la base de datos se bloquea en este punto, busque los registros y deshaga la transacción reafirmando las claves que formaban parte de la transacción a su valor anterior. Eliminar el registro para completar la reversión.
Si la transacción se confirma, elimine las claves antiguas y elimine las entradas de registro para completar la confirmación.

Luego tiene una transacción para el almacén de clave / valor de un solo subproceso que utiliza múltiples versiones.

Si la base de datos es multihilo, debe usar MVCC (vea Omid de Yahoo, PostgreSQL, Wiredtiger, bsddb ...) y algo así como Aislamiento instantáneo Serializable (PSSI).

Por ejemplo, LevelDB no admite transacciones de extractos múltiples. Leí en alguna parte que tendrías que tratar con aquellos en una "capa transaccional".

¿Qué tendría que hacer esta capa para agregar soporte de transacciones a una biblioteca de nivel inferior que no admite transacciones?

Hay varias formas de definir transacciones y hay varias formas de implementarlas. Una propiedad común de una transacción es que es ACID:

Atomicidad : todo o nada. Todas las tareas de una transacción de base de datos deben completarse; Si está incompleto debido a posibles razones, la transacción de la base de datos debe abortarse.
Consistencia - serializabilidad e integridad. La base de datos debe estar en un estado consistente o legal antes y después de la transacción de la base de datos. Significa que una transacción de base de datos no debe romper las restricciones de integridad de la base de datos.
Los datos de aislamiento utilizados durante la ejecución de una transacción de base de datos no deben ser utilizados por otra transacción de base de datos hasta que se complete la ejecución. Por lo tanto, los resultados parciales de una transacción incompleta no deben ser utilizables para otras transacciones hasta que la transacción se haya comprometido con éxito. También significa que la ejecución de una transacción no se ve afectada por las operaciones de la base de datos de otras transacciones simultáneas.
Durabilidad Todas las modificaciones de la base de datos de una transacción se harán permanentes, incluso si se produce una falla del sistema después de que se haya completado la transacción.

Una transacción puede tener varios estados:

Estado activo : se divide en dos fases. Fase inicial: una transacción de base de datos se encuentra en esta fase mientras se comienzan a ejecutar sus declaraciones. Fase Parcialmente Comprometida: una transacción de base de datos entra en esta fase cuando se ha ejecutado su declaración final. En esta fase, la transacción de la base de datos ha finalizado su ejecución, pero aún es posible abortar la transacción porque la salida de la ejecución puede permanecer temporalmente en la memoria principal, un evento como un fallo de hardware puede borrar la salida.
Estado fallido : una transacción de base de datos ingresa el estado fallido cuando su ejecución normal ya no puede continuar debido a errores de hardware o programa).
Estado anulado : una transacción de base de datos, si el SGBD ha determinado que ha fallado, entra en el estado cancelado. Una transacción abortada no debe tener ningún efecto en la base de datos, y por lo tanto, cualquier cambio que realice en la base de datos tiene que deshacerse, o en términos técnicos, retrotraerse. La base de datos volverá a su estado coherente cuando la transacción anulada se haya retrotraído. El esquema de recuperación del DBMS es responsable de administrar cancelaciones de transacciones.
Estado comprometido : una transacción de base de datos ingresa al estado comprometido cuando se ha escrito suficiente información en el disco después de completar su ejecución con éxito. En este estado, se ha escrito tanta información en el disco que los efectos producidos por la transacción no pueden deshacerse mediante el aborto; incluso cuando se produce una falla del sistema, los cambios realizados por la transacción confirmada se pueden volver a crear cuando el sistema se reinicia.

LevelDB no admite transacciones , sin embargo, tiene algunas de las propiedades ACID:

Las escrituras en lote son atómicas.
La consistencia depende de usted.
Hay un apoyo de aislamiento limitado.
La durabilidad es una opción configurable.

Entonces ... de vuelta a tu pregunta:

¿Qué tendría que hacer esta capa para agregar soporte de transacciones a una biblioteca de nivel inferior que no admite transacciones?

R: Depende de cómo definas una transacción. Si define una transacción con las propiedades mencionadas anteriormente y si desea que sus transacciones sean ACID, entonces tendría que averiguar si eso es posible con LevelDB (la mayoría de las propiedades ACID están integradas) y entonces tendría que escriba un contenedor alrededor de LevelDB que garantice que los estados de las transacciones se mantengan correctamente. Sin embargo, no estoy del todo seguro de que un wrapper solo lo haga, por lo que es posible que tenga que tomar el código fuente y modificarlo para que sea compatible con las transacciones.