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

Transacciones en MongoDB

No description
by

Jherson Jhair Chaparro Vega

on 24 November 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Transacciones en MongoDB

Alternativas para Transacciones en MongoDB
Transacciones ACID
Es un acrónimo que se utiliza en la Base de Datos y establece 4 características necesarias, las cuales garantizan que las transacciones se realicen en forma confiable.
Forma Básica del Algoritmo
(Two Phase Commits)
tomicity
Fase de petición del Commit

1. El coordinador envía un mensaje consulta para commit a todos los participantes.

2. Los participantes ejecutan la transacción hasta el punto donde ellos serán preguntados para realizar commit. Ellos pueden escribir una entrada a su log undo(log de deshacer) y una entrada a su log redo(log de rehacer).

3. Cada participante responde con un mensaje de acuerdo si la transacción tuvo éxito, o un mensaje abortar si falló la transacción.

4. El Coordinador espera hasta que tenga un mensaje de cada participante.
onsistency
solation
urability
Requiere que cada transacción sea "todo o nada".
- Puede acabar con una confirmación (commit).
- Puede ser cancelada en su totalidad por algún error (rollback).
Una BBDD es consistente si se garantiza la verificación de determinadas condiciones. Asegura que cualquier transacción llevará a la base de datos de un estado valido a otro estado valido (asegura que solo se empieza aquello que se puede acabar).
Es la propiedad que asegura que una operación no puede afectar a otras.

- Asegura que la realización de 2 transacciones sobre la misma información sean independientes.

- Es la garantía de que los cambios hechos dentro de cualquier transacción son invisibles a los usuarios mientras esta no haya concluido.

Es la propiedad donde se asegura que una vez una transacción al hacer su commit, sus resultados son permanentes y no pueden ser borrados de la base de datos aunque falle el sistema, incluso ante eventos como pérdida de alimentación eléctrica y errores.
¡Gracias!
Atomicidad a Nivel de
Documento
Control de
Concurrencia
Implementar Software especial de bloqueo
República Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación Superior
Vicerrectorado Académico
Departamento de Ingeniería Informática
Base de Datos II
Integrantes:
Bolívar, Diego
Chaparro, Jherson
Moreno, Jesús
Sánchez, María A.
Zambrano, Alejandro
Transacciones en MongoDB
BA S E
Es una alternativa flexible del modelo ACID para bases de datos NoSQL, donde es prioridad la Disponibilidad sobre la Consistencia.
Eventual Consistency: La consistencia se da eventualmente. Se asume que inconsistencias temporales progresen a un estado final estable.
Basic Availability: Se centra en la disponibilidad de los datos, incluso en presencia de múltiples fallos.
Soft-State: Se prioriza la propagación de datos, delegando el control de inconsistencias a elementos externos.
Modelo de Datos para
Operaciones Atómicas

El método recomendado para mantener la
atomicidad sería mantener toda la información
relacionada que se actualiza con frecuencia juntos
en un solo documento mediante la inclusión de
documentos. Esto se aseguraría de que todas
las versiones de un mismo documento
son atómicas.
MongoDB garantiza la atomicidad de las
operaciones sólo a nivel de documento, es decir,
todas las modificaciones que hagamos sobre un
documento en una instrucción son atómicas.
Por esto incluir documentos dentro de otros
en vez de crear más colecciones,
contrarresta el hecho de que MongoDB
no soporta transacciones, y también
el que no tenga joins.

Commit en
dos fases
El protocolo commit de dos fases, también conocido por las siglas 2PC (del inglés two-Phase Commit), es un protocolo de consenso distribuido que permite a todos los nodos de un sistema distribuido ponerse de acuerdo para hacer commit a una transacción. Típicamente es usado en Bases de datos distribuidas. El objetivo del protocolo es que todos los nodos realicen commit de la transacción o la aborten.

Las dos fases del algoritmo son la fase de petición de commit, en el cual el coordinador intenta preparar a todos los demás, y la fase commit, en la cual el coordinador completa las transacciones a todos los demás participantes.
Fase Commit - Éxito

El coordinador recibió un mensaje acuerdo de todos los participantes durante la fase de petición de commit:

1. El coordinador envía un mensaje commit a todos los participantes.

2. Cada participante completa la operación, y libera todos los bloqueos y recursos mantenidos durante la transacción.

3. Cada participante envía un reconocimiento (ack) al coordinador.

4. El coordinador completa la transacción cuando ha recibido todos los reconocimientos.
Fase Commit - Fracaso

Si algún participante envió un mensaje abortar durante la fase de petición de commit:

1. El coordinador envía un mensaje rollback a todos los participantes.

2. Cada participante deshace la transacción usando el log undo(log de deshacer), y libera los recursos y bloqueos mantenidos durante la transacción.

3. Cada participante envía un reconocimiento (ack) al coordinador.

4. El Coordinador completa la transacción cuando han sido recibidos los reconocimientos.
Desventajas
1. La mayor desventaja del protocolo
es el hecho de que es un protocolo bloqueante.
El protocolo puede bloquear indefinidamente de la
siguiente forma: si un participante ha enviado
un mensaje acuerdo al coordinador, se bloqueará
hasta que un “commit” o “rollback” sea recibido. Si el coordinador está permanentemente caído, el participante bloqueará indefinidamente, a menos que pueda obtener la decisión global “commit” o
“abort” desde uno de los participantes.
2. Se predispone al caso de aborto en lugar del caso
completo: Cuando el coordinador ha enviado "consulta para commit" a los participantes, esté se bloqueará hasta que todos los participantes hayan enviado su respuesta, pero si un participante está permanentemente caído o tiene un largo tiempo de respuesta, el coordinador no se bloqueará indefinidamente, esto dado a que el coordinador es el único en tomar la decisión de si es 'commit' o 'abort‘. el bloqueado permanente o indefinido puede evitarse introduciendo un timeout. Si el coordinador no ha recibido todos los
mensajes esperados cuando ha pasado el timeout
decidirá 'abortar'.
3. El protocolo descansa sobre el funcionamiento correcto del coordinador.

4. Otra versión de este protocolo no necesita coordinador y permite que los clientes envíen los mensajes de preparación a todas las réplicas. Quitando al coordinador el rendimiento del sistema debería mejorar. La desventaja es un incremento en la probabilidad de conflicto ya que múltiples clientes pueden sugerir distintos valores.
MongoDB permite que múltiples usuarios puedan leer y escribir la misma data. Para asegurar consistencia, utiliza medidas de bloqueos y otros controles de concurrencia para prevenir que múltiples clientes puedan modificar la misma data simultáneamente.

También utiliza bloqueo multi-granular que permite a las operaciones bloquear al nivel global, de la base de datos, o de colección, y permite que motores de almacenaje individuales implementen su propio control de concurrencia debajo del nivel de colección. MongoDB utiliza bloqueos de lectura-escritura que permite acceso compartido de recursos a lectores concurrentes, además de un bloqueo compartido (S) para las lecturas y un bloqueo exclusivo (X) para las operaciones de escritura, los modos de intención compartida (IS) e intención exclusiva (IX) indican una intención de lectura o escritura de un recurso usando un bloqueo de granularidad fina.
Por ejemplo, considere el caso en el cual un bloqueo X se acaba de liberar, y en el cual la cola conflictiva contiene los siguientes elementos:

IS ->IS -> X ->X ->S-> IS

En orden estricto de primero que entra primero que sale (FIFO), solo los primeros 2 modos IS serán otorgados. MongoDB realmente otorgara todos los modos IS y S, y una vez que estos se agoten, otorgara X, así nuevas peticiones de IS o S hayan sido puestas en cola durante ese tiempo. Como una otorgación siempre moverá todas las demás peticiones adelante en la cola, no existe posibilidad de inanición a ninguna petición.

Tipos de Bloqueo

Existen 2 tipos de bloqueo que son: Bloqueo Optimista y Bloqueo Pesimista.
El Bloqueo Optimista se encarga de verificar que la versión no haya cambiado desde que se hace la petición hasta el momento de escribir la transacción a la base de datos, a través de fechas, marcas de tiempo o checksums (sumas de comprobación), si la versión no coincide se cancela la transacción y el usuario puede reiniciar la operación.
El Bloqueo Pesimista hace un bloqueo exclusivo hasta que se ha terminado la transacción, se debe tener cuidado al momento de implementar este tipo de bloqueo ya que pueden crear Deadlocks en el sistema, que son procesos que se encuentran en estado de espera porque un recurso del sistema que necesita no ha sido liberado por otro proceso que a su vez también se encuentra en estado de espera y así sucesivamente, cuando esto ocurre se dice que el sistema está en Deadlock o punto muerto.

Para WiredTiger
Empezando con la versión 3.0, MongoDB viene con el
motor de almacenamiento WiredTiger. Para la mayoría de las
operaciones de lectura y escritura, WiredTiger utiliza el control de concurrencia optimista. WiredTiger utiliza solo bloqueos de intención al nivel global, de base de datos y de colección. Cuando el motor de almacenamiento detecta conflictos entre 2 operaciones, una de estas incurrirá en un conflicto de escritura haciendo que MongoDB reintente esa operación de forma transparente.

Algunas operaciones globales, por lo general operaciones de vida corta que involucran múltiples bases de datos todavía requieren de un
bloqueo global “instance-wide” (instancia completa). Otras
operaciones, tales como tumbar una colección (Drop),
todavía requieren un bloqueo exclusivo
de la base de datos.

Para MMAPv1
El motor de almacenamiento MMAPv1 utiliza bloqueos de
nivel de colección desde que salió la serie 3.0, una mejora de versiones anteriores en el que el bloqueo de la base de datos era el bloqueo de granularidad más fina. Motores de búsqueda de terceras partes pueden o usar el bloqueo a nivel de
colección o implementar su propio control de
concurrencia de granularidad más fina.

Por ejemplo, si tienes 6 colecciones en una base de datos usando el motor de almacenamiento MMAPv1 y una operación hace un bloqueo de escritura a nivel de colección, las otras cinco colecciones todavía estarán disponibles para operaciones de lectura y escritura. Un bloqueo exclusivo de la base de datos hace que las seis colecciones se encuentren no disponibles mientras la operación mantenga el bloqueo.

'
Qué operaciones bloquean la Base de Datos?
Muchos sistemas de bases de datos son capaces de manejar de forma concurrente a múltiples usuarios. En algunas situaciones cada usuario puede estar interactuando con una base de datos diferente, mientras que en otras pueden ser muchos los usuarios que interactúen con la misma base de datos. El control de concurrencia asegura que las operaciones se pueden ejecutar al mismo tiempo sin comprometer la exactitud. El control de concurrencia pesimista, bloqueará cualquier operación potencialmente conflictiva, incluso si no pueden
llegar a entrar en conflicto.
Para tolerar actualizaciones en gran cantidad de documentos sin interferir con otras consultas u operaciones concurrentes y no mermar el rendimiento de la base de datos la actualización múltiple se hace de forma secuencial y de forma atómica por documento.

Esto es muy importante de cara a la concurrencia por lo que hay que controlar en nuestra aplicación que estos cambios sean totalmente visibles antes de querer usarlos con otras operaciones de lectura o escritura.
Full transcript