Ir al contenido

¿Qué puede salir mal al usar transacciones en una base de datos?

·614 palabras·3 mins
Bases De Datos
Alejandro Duarte
Autor
Alejandro Duarte
Alejandro Duarte es Ingeniero de Software, escritor, Ingeniero de Relaciones con Desarrolladores en MariaDB y consultor en desarrollo de software. Ha programado computadores desde mediados de los 90s. Comenzando con BASIC, Alejandro transitó a C, C++ y Java durante sus años académicos en la Universidad Nacional de Colombia. Se mudó primero al Reino Unido y luego a Finlandia para profundizar su participación en la industria del código abierto. Alejandro es reconocido en círculos de Java y MariaDB.
Tabla de contenido

Nota: Este es un extracto de una versión sin editar de mi libro MariaDB for Developers.

Hasta este punto, hemos comprendido el concepto de atomicidad: o todas las operaciones se completan correctamente, o ninguna lo hace. ¿Qué puede salir mal? Parece que todo está cubierto. Y lo está. Hasta que introducimos concurrencia en nuestro sistema. MariaDB es uno de los sistemas de bases de datos más eficientes y trata de paralelizar el procesamiento para aumentar el rendimiento. Paralelizar significa que MariaDB puede ejecutar transacciones de diferentes sesiones al mismo tiempo intercalando operaciones de diferentes transacciones, en lugar de esperar a que una termine para empezar la siguiente. Cada transacción tiene su propia secuencia de operaciones, pero MariaDB las ejecuta en orden superpuesto. La figura 8-2 muestra dos transacciones (A y B) y múltiples operaciones intercaladas a lo largo del tiempo.

Figura 8-2
Figura 8-2: Intercalado de operaciones de base de datos para lograr paralelismo.

Este intercalado permite que MariaDB use los recursos de CPU y E/S de manera más eficiente que sin paralelismo. Sin embargo, esto abre la puerta a problemas sutiles cuando las transacciones paralelas leen y escriben datos que se sobrelapan. Estudiemos algunos de estos problemas conocidos como fenómenos de concurrencia.

Lecturas sucias
#

¡Viernes por la tarde y tenemos un ganador! Nuestra aplicación de tareas—que para el capítulo 6 ya se había convertido más en una herramienta de gestión de proyectos que en una simple lista de pendientes—es tan central para el negocio que se otorgan premios a los usuarios que se destacan reportando errores o ayudando en su desarrollo. Nuestra aplicación permite al equipo de RRHH otorgar premios a usuarios, y este caso de uso implica reducir la cantidad del premio otorgado en la tabla prizes.

Janet y Moe, ambos del equipo de RRHH, están usando la aplicación al mismo tiempo. Janet está a punto de otorgar el premio del día (llamado “Bagelers” en nuestra base de datos), mientras Moe está viendo un panel que muestra un resumen del inventario de premios. Janet selecciona al ganador y el premio, y hace clic en “Otorgar premio”. Nuestra aplicación inicia una nueva transacción que reduce la cantidad de Bagelers de 8 a 7. En ese momento, Moe actualiza el panel y ve que hay 7 Bagelers. Sin embargo, el sistema se cae y, como la transacción nunca fue confirmada, la nueva cantidad no se guarda en disco. Janet recibe un error, pero Moe no. Para él, hay 7 Bagelers. Está viendo datos incorrectos. Esto se llama una lectura sucia. La figura 8-3 muestra una secuencia de operaciones que llevan a una lectura sucia en el tiempo t3.

Figura 8-3
Figura 8-3: Ejemplo del fenómeno de lectura sucia.

Lecturas no repetibles
#

Una situación similar puede ocurrir cuando una transacción lee un valor dos veces, pero dicho valor es modificado entre las lecturas por otra transacción. En este caso, la segunda lectura obtendría un valor distinto. Este fenómeno se llama lectura no repetible y puede llevar a resultados incorrectos si los valores son usados para otros cálculos dentro de la misma transacción. La figura 8-4 muestra una lectura no repetible en el tiempo t5.

Figura 8-4
Figura 8-4: Ejemplo del fenómeno de lectura no repetible.

Lecturas fantasma
#

Si la operación de escritura en el ejemplo anterior implica insertar filas, obtenemos lo que se conoce como el fenómeno de lectura fantasma. La figura 8-5 muestra una lectura fantasma en el tiempo t5.

Figura 8-5
Figura 8-5: Ejemplo del fenómeno de lectura fantasma.


¿Quieres profundizar más en temas como este sobre bases de datos? Estoy escribiendo un libro sobre MariaDB que cubre SQL, transacciones, índices, y muchos otros temas prácticos que los desarrolladores deben conocer. Échale un vistazo aquí si te interesa.

¿Te gustó este artículo? Puedo ayudar a tu equipo a implementar soluciones similares. Contáctame para saber más.

Relacionados

¿Qué es un vector en IA y RAG?
·926 palabras·5 mins
Bases De Datos IA
¿Qué son exactamente las incrustaciones vectoriales en aplicaciones de IA y cómo usarlas en arquitecturas RAG?
Construyendo aplicaciones con IA generativa localmente
·1278 palabras·6 mins
Bases De Datos IA
Aprende a configurar y ejecutar embedders y LLMs localmente para almacenar y consultar vectores de manera eficiente en MariaDB.

comments powered by Disqus