CC BASES DE DATOS OTOÑO Clase 10: Transacciones y ACID. Aidan Hogan

Transcripción

1 BASS D DATOS OTOÑO 2017 lase 10: Transacciones y AID Aidan Hogan aidhog@gmail.com

2 Una cuenta bancaria

3 Una cuenta bancaria integridad

4 Restricciones sobre varias tablas (!!) A. P. A.? A. S.?

5 TRANSAIONS

6 Transacciones Una transacción es un conjunto de operaciones que se ejecutan de manera atómica (es decir, como fueran una sola operación)

7 Vacaciones

8 Transacciones: START TRANSATION/OMMIT START TRANSATION (o a veces BGIN) inicia la transacción OMMIT realiza/guarda los cambios

9 Transacciones (por defecto) Si no hay una transacción explicita, por defecto, Postgres hace un OMMIT después de cada sentencia (pero se puede cambiar la configuración)

10 Transacciones: ROLLBAK ROLLBAK deshace/borra los cambios desde el inicio de la transacción

11 Transacciones: SAVPOINT ROLLBAK puede deshacer/borrar los cambios desde un punto especifico con SAVPOINT

12 Una transacción con valores dinámicos Valor final de saldo_usd en uenta?

13 Una transacción con valores dinámicos Valor final de saldo_usd en uenta? 344,94! Leemos un valor de uenta que no hemos guardado

14 Transacciones / Restricciones: IMMDIAT Por defecto, se aplica la restricción inmediatamente después de cada sentencia

15 Transacciones / Restricciones: DFRRABL DFRRABL define una restricción que se puede diferir hasta un OMMIT DFRRD difiere la restricción hasta el OMMIT en la transacción actual

16 Transacciones / Restricciones: DFRRABL DFRRABL INITIALLY DFRRD define una restricción que sea diferido por defecto hasta un OMMIT

17 Restricciones diferibles son estándares Pero Postgres no permite diferir restricciones usando ni HK ni NOT NULL

18 Atomicidad, onsistencia, Aislamiento, Durabilidad (Atomicity, onsistency, Isolation, Durability) LAS GARANTIAS D AID apítulo 8.1 Ramakrishnan / Gehrke

19 No hay un solo usuario hay que tener cuidado con la concurrencia

20 Una cuenta con varios usuarios Qué será el resultado final?

21 aos

22 sta vez con transacciones Qué será el resultado final? Se rechazará una transacción.

23 Garantías de AID Atomicidad: La ejecución de cada transacción es atómica: Se realizan todas las acciones o no se realiza ninguna onsistencia: ada transacción debe preservar la integridad La base de datos satisfacen todas las restricciones después de una transacción Aislamiento (Isolation): Una transacción no puede afectar otra Durabilidad: Una vez que haya un OMMIT, la base de datos debe persistir los cambios

24 AID: Un ejemplo más limpio Usaré restricciones con HK porque dan ejemplos más claros pero es importante tener en cuenta que postgres no suporte HKs diferibles.

25 AID: Atomicidad No se puede actualizar el saldo sin actualizar el gasto directamente después. (Si alguna actualización falla, ambas fallan.)

26 AID: onsistencia Si el resultado de la transacción no satisface todas las restricciones, fallará.

27 AID: Aislamiento (Isolation) Una transacción no puede interferir con otra transacción. n (4), hay que tener cuidado con el ROLLBAK: no se puede restaurar el valor de saldo antes del paso (1) porque el valor ya fue cambiado por (2).

28 AID: Durabilidad Una vez que haya un OMMIT exitoso, se persisten los cambios. (Normalmente la persistencia aquí significa en el disco duro. Sin persistencia, en el caso de que la máquina falla y toda la evidencia de los cambios está en memoria principal, el sistema de base de datos olvidaré los cambios silenciosamente.)

29 ntonces con las garantías de AID todo está tranquilo.

30 pero si uno tiene que implementar AID es más difícil...

31 uando no tenemos AID Atomicidad: Una transacción se ejecutan sólo a medias pero afecta el estado de la base de datos onsistencia: Al ejecutar la transacción, la base de datos no satisface las restricciones de integridad Aislamiento (Isolation): l resultado final de dos transacciones no es equivalente a correr cada transacción en serie Durabilidad: La base de datos se actualiza momentáneamente y luego vuelve al estado anterior.

32 Modelando una transacción

33 uando no tenemos AID Atomicidad: Una transacción se ejecutan sólo a medias pero afecta el estado de la base de datos onsistencia: Al ejecutar la transacción, la base de datos no satisface las restricciones de integridad Aislamiento (Isolation): l resultado final de dos transacciones no es equivalente a correr cada transacción en serie Durabilidad: La base de datos se actualiza momentáneamente y luego vuelve al estado anterior. ómo puede una implementación evitar estos tipos de problemas?

34 Modelando una transacción Atomicidad: Una transacción se ejecutan sólo a medias pero afecta el estado de la base de datos onsistencia: Al ejecutar la transacción, la base de datos no satisface las restricciones de integridad Aislamiento (Isolation): l resultado final de dos transacciones no es equivalente a correr cada transacción en serie Durabilidad: La base de datos se actualiza momentáneamente y luego vuelve al estado anterior.

35 IMPLMNTANDO UNA BAS D DATOS ON AID: RGISTROS (LOGGING)

36 Mantener un registro de la transacción

37 Si hay un problema, revertir el registro

38 Registros ayudan con Atomicidad: Una transacción se ejecutan sólo a medias pero afecta el estado de la base de datos onsistencia: Al ejecutar la transacción, la base de datos no satisface las restricciones de integridad Aislamiento (Isolation): l resultado final de dos transacciones no es equivalente a correr cada transacción en serie Durabilidad: La base de datos se actualiza momentáneamente y luego vuelve al estado anterior. uáles problemas podemos evitar con alguna forma de registro?

39 oncurrencia/aislamiento: un problema abierto Una transacción no puede interferir con otra transacción. n (4), hay que tener cuidado con el ROLLBAK: no se puede restaurar el valor de saldo antes del paso (1) porque el valor ya fue cambiado por (2).

40 oncurrencia/aislamiento: un problema abierto Una transacción no puede interferir con otra transacción. n (4), hay que tener cuidado con el ROLLBAK: no se puede restaurar el valor de saldo antes del paso (1) porque el valor ya fue cambiado por (2).

41 IMPLMNTAIÓN D AID: SUNIABILIDAD (SRIALIZABILITY) apítulo 8.3 (es)/16.3 (en) Ramakrishnan / Gehrke

42 Registros no ayudan con Atomicidad: Una transacción se ejecutan sólo a medias pero afecta el estado de la base de datos onsistencia: Al ejecutar la transacción, la base de datos no satisface las restricciones de integridad Aislamiento (Isolation): l resultado final de dos transacciones no es equivalente a correr cada transacción en serie Durabilidad: La base de datos se actualiza momentáneamente y luego vuelve al estado anterior. entonces que podemos hacer con respecto a aislamiento/concurrencia?

43 La solución más simple: ejecución serial Hay un problema aquí? jecución serial es lenta! Se pueden ejecutar partes de T 1 y T 2 en paralelo? J U I Ó N uánto es A + B después? = 600

44 jecución paralela? uánto es A + B después? \_( ツ )_/ Por simplicidad asumiremos un orden de ejecución en el caso paralelo J U I Ó N

45 jecución paralela? uánto es A + B después? = 600 J U I Ó N

46 jecución paralela? uánto es A + B después? = 600 J U I Ó N

47 jecución paralela? J U I Ó N uánto es A + B después? = 600

48 uidado cuando el orden importe! uánto es A + B después? = 600 J U I Ó N

49 uidado cuando el orden importe! uánto es A + B después? 260 No tenemos = 600 ningún problema J con la restricción, pero el orden de ejecución puede afectar el resultado. Dependiendo de la aplicación, Ua veces puede ser necesario preservar el orden de transacciones y/o aplicar ejecución serial. I Ó N

50 jecución paralela? uánto es A + B después? = 640 J U I Ó N Dónde está el problema?

51 jecución paralela? uánto es A + B después? = 640 J U I Ó N Dónde está el problema?

52 Planificaciones: Secuenciables vs. No Secuenciables Secuenciable quivalente a ejecutar transacción T 1 y después transacción T 2 (serial) No secuenciable

53 Planificaciones: Secuenciables vs. No Secuenciables Una planificación es una lista de acciones de un conjunto de transacciones en el orden Secuenciable de ejecución. quivalente a ejecutar transacción T 1 y después transacción T 2 (serial) Una planificación secuenciable tendrá el mismo efecto que una planificación serial (en algún orden de las transacciones). ómo se puede identificar una planificación secuenciable? (sin ejecutarla y compararla con todas las posibles planificaciones seriales)? Seguiremos con la pregunta inversa cuándo no se puede garantizar No secuenciable que una planificación sea secuenciable?

54 (1) onflicto de Lectura scritura uánto es A + B después? = 640 J U I Ó N

55 (1) onflicto de Lectura scritura uánto es A + B después? = 640 J U I Ó N onflicto de Lectura scritura: (Lecturas no repetibles) T 2 cambia el valor de A que T 1 ha leído pero todavía no ha escrito

56 (2) onflicto de scritura Lectura uántos serían A y B si se ejecutaran T 1 y después T 2? 330 y 330 T 2 y después T 1? 340 y 320 J U I Ó N uántos serán A y B aquí? 330 y 320

57 (2) onflicto de scritura Lectura onflicto de scritura Lectura: uántos serían A y B si se ejecutaran T 1 y después T 2? 330 y 330 T 2 y después T 1? 340 y 320 J U I Ó N l orden de cambio de A es T 1 / T 2 mientras el orden de B es T 2 / T 1, entonces el orden de ambos no es ni T 1 / T 2 ni T 2 / T 1 uántos serán A y B aquí? 330 y 320

58 (3) onflicto de scritura scritura uántos serán A y B aquí? 1 y 1000 J U I Ó N Secuenciable? No!

59 (3) onflicto de scritura scritura J U I Ó N uántos serán A y B aquí? 1 y 1000 onflicto de scritura scritura: Secuenciable? No! T 2 sobrescribe T 1 y T 1 sobrescribe T 2 (no hay problema con lecturas aquí)

60 Qué tipo de conflicto hay aquí? onflicto de scritura Lectura: A cambia con T 1 / T 2 B cambia con T 2 / T 1 Qué tipo de conflicto hay aquí? s secuenciable! (No hay conflicto)

61 Qué tipo de conflicto hay aquí? onflicto de scritura Lectura: A cambia con T 1 / T 2 B cambia con T 2 / T 1 Los casos son parecidos pero uno es secuenciable y el otro no! Qué tipo de conflicto hay aquí? s secuenciable! (No hay conflicto)

62

63 (*) onflictos parecidos con anulaciones uánto es A + B después? = 500 J U I Ó N

64 (*) onflictos parecidos con anulaciones n una planificación recuperable, cada transacción T se compromete (OMMIT) sólo después de que se comprometan a su vez todas las transacciones desde las cuáles T hayan leído algo. J Si cada transacción T solamente lee cambios de transacciones comprometidas, se pueden evitar anulaciones en cascada y mantener una planificación recuperable. De lo contrario, si T lee algo U de una transacción no comprometida T y hay que anular T, entonces puede ser que haya que anular T también (una I anulación en casada) para mantener una planificación recuperable. Ó N Para uánto cumplir es con A + AID, B después? un sistema de bases de datos debe garantizar que 270 solamente = 500 se permitan planificaciones recuperables.

65

66 SOLUIÓN: BLOQUOS (LOKS)

67 l problema onflicto de scritura Lectura: Han visto un problema así antes de este curso? Multihilos (Multithreading) Y qué era la solución (en Java por ejemplo)? Bloques sincronizados

68 Una solución en Java onflicto de scritura Lectura:

69 Una solución en Java onflicto de scritura Lectura: ómo podrías mejorar el rendimiento del código abajo? Minimizar el código sincronizado tanto como sea posible Usar objetos de bloqueos tan especifico que sea posible (por ejemplo, usar un valor de la tabla o una fila de la tabla como el objeto de bloqueo, no la entera tabla, si es posible)

70 Una solución en un sistema de b.d.d.? onflicto de scritura Lectura: ómo podrías mejorar el rendimiento del código abajo? Minimizar el código sincronizado tanto como sea posible Usar objetos de bloqueos tan especifico que sea posible (por ejemplo, usar un valor de la tabla o una fila de la tabla como el objeto de bloqueo, no la entera tabla, si es posible) Los mismos conceptos aplican a sistemas de bases de datos! Salvo que es el sistema, no el programador, que tiene que decidir (automáticamente) el nivel de sincronización, el nivel de bloqueo, etc. Una transacción tiene que conseguir bloqueos para los objetos (valores, filas, vista, tablas) que quiere modificar. uando haya terminado con el bloque, lo libera. Un protocolo de bloqueo especifica las reglas que las transacciones tienen que seguir con respecto a bloqueos.

71 Un protocolo: Bloqueo en 2 fases Si una transacción T quiere leer un objeto O, tiene que conseguir un bloqueo compartido sobre O Varias transacciones pueden leer el mismo objeto al mismo tiempo Si una transacción T quiere modificar un objeto O, tiene que conseguir un bloqueo exclusivo sobre O Un bloqueo exclusivo excluye bloqueos compartidos T puede leer O (por supuesto) Así nadie (aparte de T) puede ni leer ni modificar O mientras T tenga su bloqueo exclusivo sobre O

72 onflicto de Lectura scritura uánto es A + B después? = 640 J U I Ó N

73 con bloqueos J U I Ó N ómo sería la planificación final?

74 con bloqueos J U I Ó N A. P. A.? Todavía permite conflictos

75 conflicto Qué tipo de conflicto hay? scritura-lectura! J U I Ó N Una solución?

76 bloqueo estricto Solución: Liberar los bloqueos sólo cuando la transacción haya terminado (bloqueo estricto) J U I Ó N

77 Un protocolo: Bloqueo en 2 fases estricto Si una transacción T quiere leer un objeto O, tiene que conseguir un bloqueo compartido sobre O Varias transacciones pueden leer el mismo objeto al mismo tiempo Si una transacción T quiere modificar un objeto O, tiene que conseguir un bloqueo exclusivo sobre O Un bloqueo exclusivo excluye bloqueos compartidos T puede leer O (por supuesto) Así nadie (aparte de T) puede ni leer ni modificar O mientras T tenga su bloqueo exclusivo sobre O (Solo) cuando T haya terminado, libará sus bloqueos

78 Un protocolo: Bloqueo en 2 fases estricto Si una transacción T quiere leer un objeto O, tiene que conseguir un bloqueo compartido sobre O Varias transacciones pueden leer el mismo objeto al mismo tiempo Si una transacción T quiere modificar un objeto O, La forma más popular de garantizar secuenciabilidad. tiene que conseguir un bloqueo exclusivo sobre O Un bloqueo exclusivo excluye bloqueos compartidos T puede leer O (por supuesto) Así nadie (aparte de T) puede ni leer ni modificar O mientras T tenga su bloqueo exclusivo sobre O (Solo) cuando T haya terminado, libará sus bloqueos

79 pero cuidado! A. P. A.? Hay que evitar interbloqueos (deadlocks) J U I Ó N Solución 1: Plazos para terminar o Solución 2: Detectar ciclos en transacciones esperando o

80 pero cuidado! A. P. A.? Hay que evitar interbloqueos (deadlocks) J U I Ó N Solución 1: Plazos para terminar o Solución 2: Detectar ciclos en transacciones esperando o

81 Bloqueo en 2 fases conservativo Solución 3: La transacción adquieren todos los bloqueos necesarios al inicio y de una forma atómica J U I Ó N s estricto? No

82 Bloqueo en 2 fases estricto/conservativo Sólo se pueden paralelizar transacciones que no compartan objetos (lo más fácil pero lo menos paralelizable) J U I Ó N

83

84 Pero para un usuario

85 Hemos terminado con bases de datos relacionales

86 Planificación del curso 24 de mayo: lab (transacciones) 26 de mayo: auxiliar 29 de mayo: clase (XML) 31 de mayo: lab (XML) 5 de junio: proyectos 7 de junio: proyectos 12 de junio: clase (RDF)

87 Preguntas?