Diseño de aplicaciones con uso intensivo de datos, 2nd Edición
by Martin Kleppmann, Chris Riccomini
capítulo 8. Transacciones
Algunos autores han afirmado que la confirmación en dos fases general es demasiado costosa de mantener, debido a los problemas de rendimiento o disponibilidad que conlleva. Creemos que es mejor que los programadores de aplicaciones se ocupen de los problemas de rendimiento debidos al uso excesivo de transacciones cuando surgen cuellos de botella, en lugar de codificar siempre en torno a la falta de transacciones.
James Corbett et al., “Spanner: Google’s Globally-Distributed Database” (2012)
En la dura realidad de los sistemas de datos, pueden salir mal muchas cosas:
-
El software o el hardware de la base de datos pueden fallar en cualquier momento (incluso en medio de una operación de escritura).
-
La aplicación puede bloquearse en cualquier momento (incluso en medio de una serie de operaciones).
-
Las interrupciones en la red pueden cortar inesperadamente la aplicación de la base de datos, o un nodo de la base de datos de otro.
-
Varios clientes pueden escribir en la base de datos al mismo tiempo, sobrescribiendo los cambios de los demás.
-
Un cliente puede leer datos que no tienen sentido porque solo se han actualizado parcialmente.
-
Las condiciones de carrera entre clientes pueden provocar errores inesperados.
Para ser confiable, un sistema debe lidiar con todos estos tipos de fallas y garantizar que no causen fallas catastróficas. Sin embargo, implementar mecanismos de tolerancia a fallas es mucho trabajo. Requiere pensar cuidadosamente en ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access