Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

MANEJO DE TRANSACCIONES Y CONCURRENCIA EN POSTGRES

No description
by

maria saenz

on 24 October 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of MANEJO DE TRANSACCIONES Y CONCURRENCIA EN POSTGRES

MANEJO DE TRANSACCIONES Y CONCURRENCIA EN POSTGRES
Las transacciones deben cumplir el criterio ACID
*Atomicity: todas las acciones en la transacción se cumplen o no se cumple ninguna.

*Consistency: la transacción solo termina si la data es consistente.

*Isolation: la transacción es independiente de otras transacciones.

*Durability: cuando la transacción termina el resultado de la
misma es perdurable.

Caracteristicas de MVCC
*La data nunca es “visible” por otros usuarios hasta que no sea “commiteada”.

*La principal ventaja es que las operaciones de R nunca bloquean a las de W, y viceversa, podemos obtener backups en caliente sin bloquear la db.

*Como desventaja: consumimos mas disco duro.
ESTADOS DE UNA TRANSACCION
*Active : es el estado inicial y permanece durante toda la ejecución.

*Partially committed : después de que se ha ejecutado el último statement

*Failed : después de algún error, no se puede continuar.

*Aborted : se hace un "rollback" hacia un estado anterior consistente.

*Committed : después del éxito


Control de Concurrencia
El control de concurrencia es el que asegura que muchos usuarios puedan acceder a la data al mismo tiempo. Al realizar procesos de transacciones se producen operaciones de R/W.
Ninguna transacción debe ver el resultado de otras transacciones inconclusas, si esto no fuera así estaríamos leyendo datos inconsistentes.
El control de accesos concurrentes y específicamente de transacciones concurrentes en SQL es manejado por un módulo del dbms llamado "scheduler".


MVCC (Multiversion Concurrency Control) de PostgreSQL
Postgres mantiene la consistencia de los datos con un modelo multiversión (MVCC). Esto significa que mientras se consulta una base de datos, cada transacción ve una imagen de los datos (una versión de la base de datos) como si fuera tiempo atrás, sin tener en cuenta el estado actual de los datos que hay por debajo. Esto evita que la transacción vea datos inconsistentes que pueden ser causados por la actualización de otra transacción concurrente en la misma fila de datos, proporcionando aislamiento transaccional para cada sesión de la base de datos.
Programación
Crear Conexión

Abrir Conexión
(Openconnection)

Iniciar Transacción
(Begin Transaction) setAutoCommit(0/false)

Queries...
(Insert, Select, Update, Delete...)

-Error
(Abort Transaction) rollback
Procesar resultados
(Print, a= , b= )
Asegurar Transacción
(End Transaction) commit
Cerrar Conexión
(Closeconnection)
Transacciones
Una transacción es una unidad de programa que accesa y posiblemente actualiza varios elementos de datos a la vez, en postgreSQL se pueden realizar transacciones utilizando las siguientes instrucciones SQL:

BEGIN: se utiliza para indicar explícitamente el inicio de una transacción. Todas las instrucciones siguientes a BEGIN deben completarse correctamente para que sean registradas permanentemente.

COMMIT: Se utiliza para registrar los cambios hechos en una transacción permanentemente.

ROLLBACK: Se utiliza para descartar todas las operaciones realizadas en una transacción.


Diferencia entre multiversión y el modelo de bloqueo

La principal diferencia entre multiversión y el modelo de bloqueo es que los bloqueos MVCC derivados de una consulta (lectura) de datos no entran en conflicto con los bloqueos derivados de la escritura de datos y de este modo la lectura nunca bloquea la escritura y la escritura nunca bloquea la lectura.
Nivel de Aislamiento de una transacción

El nivel de aislamiento de una transacción determina qué datos de la transacción pueden verse desde otra transacción que se está ejecutando concurrentemente.
SQL estándar define 4 niveles de aislamiento en términos de 3 fenómenos que deben ser prevenidos entre transacción concurrentes. Estos son:

*DIRTY READ
*NONREPEATABLE READ
*PHANTOM READ
*REPEATABLE READ

DIRTY READ cuando la transacción accede a datos escritos por otra transacción que aún no hace Commit.
 
NONREPEATABLE READ cuando la transacción re-lee datos que ya ha leído previamente y encuentra que han sido modificados por una transacción que ha hecho Commit después de la lectura inicial.

PHANTOM READ Una transacción re-ejecuta un query devolviendo un conjunto de filas que satisfacen una condición de búsqueda y encuentra que han sido modificadas por otra transacción que ha hecho Commit recientemente.
 
REPEATABLE READ Este nivel es muy parecido al Read Committed, salvo que también puede ver modificaciones a las que aún no se les ha hecho Commit dentro de la misma transacción en que se está ejecutando. Las aplicaciones corriendo en este nivel deben estar preparadas para reintentar transacciones debido a fallos de serialización. Provee el mínimo de aislamiento que cualquier nivel debe proveer.
Isolation Level Dirty Read Nonrepeatable Read Phantom Read
Read uncommitted Possible Possible Possible
Read committed Not possible Possible Possible
Repeatable read Not possible Not possible Possible
Serializable Not possible Not possible Not possible
Niveles de aislamiento
PostgreSQL ofrece Read Committed (default) y Serializable
READ COMMITED
Nivel de aislamiento por defecto de PostgreSQL, donde las modificaciones de otras transacciones se ven si se terminaron con COMMIT antes de comenzar la consulta. En caso de intentar cambiar un dato que otra transacción está cambiando, la actual queda bloqueada hasta saber si proceder con el cambio (en caso de rollback) o si volver a ejecutar la condición de consulta del cambio para comprobar que las filas a cambiar aún la cumplen (en caso de commit).
SERIALIZABLE
Es la empleada por defecto en SQL estándar, solo se ven las modificaciones de otra transacción que hayan sido aceptadas (COMMIT) al principio de la transacción actual. PostgreSQL no tiene un nivel SERIALIZABLE real puesto que solo ve los datos que han sido COMMIT antes de la primera consulta o modificación de datos.

Para garantizar serialización verdadera Postgre utiliza “bloqueo de predicados” esto significa que mantiene bloqueos que le permiten determinar si una escritura pudiera tener un impacto en el resultado de alguna lectura de otra transacción concurrente, estos bloqueos no causan bloqueos reales, por lo tanto no pueden causar deadlocks, se utilizan para identificar dependencias entre transacciones serializables.
Bloqueos y tablas
Postgres ofrece varios modos de bloqueo para controlar el acceso concurrente a los datos en tablas. Algunos de estos modos de bloqueo los adquiere Postgres automáticamente antes de la ejecución de una declaración, mientras que otros son proporcionados para ser usados por las aplicaciones.

En PostgreSQL el bloqueo puede ser Compartido (Share) o Exclusivo (Exclusive), estos son administrados por un “Lock Manager”. Existen varios tipos de bloqueos:

*BLOQUEOS A NIVEL DE TABLA
*BLOQUEOS A NIVEL DE FILA
AccessShareLock

Un modo de bloqueo adquirido automáticamente sobre tablas que están siendo consultadas. Postgres libera estos bloqueos después de que se haya ejecutado una declaración.

Conflictos con AccessExclusiveLock.
RowShareLock

Adquirido por SELECT FOR UPDATE y LOCK TABLE para declaraciones IN ROW SHARE MODE.

Entra en conflictos con los modos ExclusiveLock y AccessExclusiveLock.
RowExclusiveLock

Lo adquieren UPDATE, DELETE, INSERT y LOCK TABLE para declaraciones IN ROW EXCLUSIVE MODE.

Choca con los modos ShareLock, ShareRowExclusiveLock, ExclusiveLock y AccessExclusiveLock.
ShareLock

Lo adquieren CREATE INDEX y LOCK TABLE para declaraciones IN SHARE MODE.

Está en conflicto con los modos RowExclusiveLock, ShareRowExclusiveLock, ExclusiveLock y AccessExclusiveLock.
ShareRowExclusiveLock

Lo toma LOCK TABLE para declaraciones IN SHARE ROW EXCLUSIVE MODE.

Está en conflicto con los modos RowExclusiveLock, ShareLock, ShareRowExclusiveLock, ExclusiveLock y AccessExclusiveLock.
ExclusiveLock

Lo toma LOCK TABLE para declaraciones IN EXCLUSIVE MODE.

Entra en conflicto con los modos RowShareLock, RowExclusiveLock, ShareLock, ShareRowExclusiveLock, ExclusiveLock y AccessExclusiveLock.
AccessExclusiveLock

Lo toman ALTER TABLE, DROP TABLE, VACUUM y LOCK TABLE.

Choca con RowShareLock, RowExclusiveLock, ShareLock, ShareRowExclusiveLock, ExclusiveLock y AccessExclusiveLock.

Nota

Sólo AccessExclusiveLock bloquea la declaración SELECT (sin FOR UPDATE).
Bloqueo a Nivel de tabla
Bloqueo a nivel de Fila
Este tipo de bloqueos se producen cuando campos internos de una fila son actualizados (o borrados o marcados para ser actualizados). Postgres no retiene en memoria ninguna información sobre filas modificadas y de este modo no tiene límites para el número de filas bloqueadas sin incremento de bloqueo.

Sin embargo, tenga en cuenta que SELECT FOR UPDATE modificará las filas seleccionadas marcándolas, de tal modo que se escribirán en el disco.

Los bloqueos a nivel de fila no afecta a los datos consultados. Estos son usados para bloquear escrituras a la misma fila únicamente.
* Bloqueo Explicito:
PostgreSQL provee varios métodos de bloqueo además de MVCC para situaciones donde este no proporciona el comportamiento deseado.

* Bloqueo a nivel de Tablas:
Estos son los tipos de bloqueo a nivel de tablas, son adquiridos de manera automatica por Postgre o manual mediante el comando LOCK.

* Bloqueo a nivel de Filas:
Los tipos de bloqueo a nivel de filas son SELECT FOR UPDATE para un bloqueo exclusivo y SELECT FOR SHARE para un bloqueo compartido, pero que genera una solicitud de bloqueo exclusivo cuando se intenta modificar la fila.

* Advisory Locks:
Son bloqueos para fines específicos que no son usados normalmente por el sistema, existen de sesión, que obtienen el bloqueo desde el inicio de la sesión hasta el final de esta y no se desbloquea incluso con rollbacks, y de transacción, que se comporta más como los bloqueos normales, se liberan automáticamente al final de la transacción, si hay un bloqueo de sesión sobre un recurso, no puede haber uno de transacción, y viceversa.
Cuando Usar MVCC?
• Aplicaciones que procesan transacciones en línea en gran escala.

• Aplicaciones mixtas que usan reportes contra datos sobre tablas en línea.

• Aplicaciones donde se ejecutan consultas largas mientras que simultaneamente se realizan operaciones sobre ella.
Bloqueos de Postgres
Escenarios donde no generalmente debería usarse MVCC
• Aplicaciones de datawarehousing que extraen información sobre tablas históricas donde no hay escritura.

• Aplicaciones que procesan datos en línea con poca concurrencia.

• Aplicaciones realtime, donde la velocidad es mas importante aun que la consistencia de información.
Ventajas de usar el Control de Concurrencia
Mejor respuesta en ambientes de grandes volúmenes. Los principales proveedores de sistemas de bases de datos comerciales usan también esta tecnología, por las mismas razones.
Desventajas de usar en Control de Concurrencia
* Puntos de recuperación dentro de transacciones. Actualmente, las transacciones abortan completamente si se encuentra un fallo durante su ejecución.

*consumimos mas disco duro.

Integrantes:
Asprilla M. Rosa M. 18289707
Escalante S. Luis M. 21341391
González H. Leyry C. 19522867
Paredes P. Milagros C. 19977433
Sáenz M. María G. 19135329
Integrantes:

Asprilla M. Rosa M. 18289707
Escalante S. Luis M. 21341391
González H. Leyry C. 19522867
Paredes P. Milagros C. 19977433
Sáenz M. María G. 19135329
Full transcript