Bd NoSQL Técnicas III PROFA. MERCY OSPINA

Agenda Disponibilidad Consenso Partición Replicación

Ordenación con marcas de tiempo multiversión MVCC Reed (1983) Se mantiene una lista de versiones antiguas: ◦ Versiones tentativas: registradas por las operaciones de escritura y son invisibles para las demás transacciones. ◦ Versiones consumadas: cuando la transacción que creó la versión termina exitosamente. Esta lista representa la historia de los valores del objeto Cada versión tiene: ◦ Una marca de tiempo de lectura: la mayor marca de tiempo de las transacciones que han leído el objeto ◦ Una marca de tiempo de escritura: La marca de tiempo de la transacción que creó la versión del objeto

Ordenación con marcas de tiempo multiversión MVCC Reed (1983) Si se realiza una operación de lectura por Ti sobre D ◦ Se lee la versión consumada con MT_escritura(D) mas grande menor que MT(Ti). ◦ Se actualiza la MT_lectura(D) al máximo entre ella y la MT(Ti). Cuando una operación de lectura llega tarde se le permite leer de una versión antigua ya consumada, por lo que no se rechaza.

Ordenación con marcas de tiempo multiversión MVCC Reed (1983) Si se realiza una operación de escritura sobre D por Ti ◦ Se dirige a la versión consumada más reciente del objeto D ◦ Si MT_lectura(D) < MT(Ti) ◦ Realiza la operación de escritura de una versión tentativa de D con la MT_escritura(D)=MT(Ti)=MT_lectura(D) ◦ Si no ◦ Se rechaza la operación y se cancela la transacción Ti. Si una transacción se aborta todas las versiones que creó se eliminan.

Ordenación con marcas de tiempo multiversión MVCC Reed (1983) Cuando una transacción termina exitosamente todas sus versiones se mantienen, pero de cuando en cuando se deben borrar las versiones antiguas. Solo se replica la ultima versión del objeto

Ordenación con marcas de tiempo multiversión MVCC Reed (1983) Nodo del dato A VersiónValorMT lectura MT escritura 1312 Leer(A),3 Leer(A),4 Leer(A),2 Escribir(A=8),6 Escribir(A=10),5

Ordenación con marcas de tiempo multiversión MVCC Reed (1983) Nodo del dato A VersiónValorMT lectura MT escritura 131, Leer(A),3 Leer(A),7 Leer(A),2 Escribir(A=8),6 Escribir(A=10),5 La MT_lectura es mayor

Elección Algoritmos en que un proceso cumple un rol particular. Caída del proceso coordinador ◦ Cualquier otro par podría tomar su rol ◦ Pero todos deben estar de acuerdo ◦ La selección del proceso elegido debe ser única Cualquier proceso pi que detecte la desaparición del coordinador puede iniciar la elección ◦ Podrá haber N elecciones simultaneas ◦ pi tiene una variable: participante o no-participante ◦ pi i tiene una variable: electedi, con el líder elegido por pi, o el valor null

Elección Basado en Anillo Cualquier proceso puede comenzar la elección y envía un mensaje de elección a su vecino con su identificador y se marca como participante Cuando un proceso recibe un mensaje de elección compara el identificador del mensaje con el suyo: ◦ Si es mayor reenvía el mensaje al siguiente ◦ Si es menor y no es un participante sustituye el identificador del mensaje por el suyo y lo reenvía. ◦ Si es menor y es un participante no lo reenvía ◦ Cuando se reenvía un mensaje, el proceso se marca como participante Cuando un proceso recibe un identificador con su número y es el mayor se elige como coordinador El coordinador notifica al resto

Elección Anillo

Elección Algoritmo del matón o abusón (bully) Investigar

Algoritmo del matón Premisas ◦ El sistema es síncrono y utiliza tiempo de espera para la identificación de fallos en los procesos. ◦ Se permite que los procesos se bloqueen/caigan durante la ejecución del algoritmo. ◦ La entrega de mensajes entre procesos se supone fiable. ◦ Los IDs de los procesos deben ser conocidos. Comparado con el Algoritmo en Anillo: ◦ Se supone que el sistema es síncrono. ◦ Utiliza el tiempo de espera para detectar fallos/caídas en los procesos. ◦ Cada proceso conoce qué procesos tienen el ID más alto que el suyo y puede comunicarse con ellos.1

Algoritmo del Matón Tipos de mensaje ◦ Mensaje de Elección: Enviados para comunicar que se va a seleccionar un nuevo coordinador. ◦ Mensaje de Respuesta: Encargados de responder al mensaje de elección. ◦ Mensaje de Coordinador: Enviado para comunicar el ID del proceso seleccionado.

Algoritmo del Matón

Consenso Objetivo: que un conjunto de procesos se pongan de acuerdo en una determinada acción o valor. Un servicio de consenso consta de ◦ Un conjunto de N procesos que deben tener una visión consensuada de un determinado objeto, valor o acción ◦ Clientes que envían peticiones a los procesos para proponer un valor Un protocolo de consenso es correcto sii: ◦ Todos los nodos deciden el mismo valor (seguridad) ◦ El valor decidido debe haber sido propuesto por algún nodo ◦ Todos los nodos deciden el valor en el algún momento (terminación)

Consenso Paxos Consenso para replicación (investigar sloopy quorum &hinted handoff)

Consenso - Paxos Propuesto por Lamport (1989) Es un algoritmo que permite llegar a consensos en sistemas distribuidos. Todos los nodos alcanzan consenso a pesar de fallos en los nodos, particiones de red y retrasos en la entrega de mensajes

Consenso - Paxos Roles ◦ Cliente: emite una petición al sistema distribuido, y espera una respuesta. ◦ Proponente: media por una petición del cliente, tratando de convencer a los aceptadores para que se pongan de acuerdo sobre el mismo ratificando un valor propuesto, y actúan como un coordinador para seguir adelante con el protocolo cuando se producen conflictos.

Consenso - Paxos Roles ◦ Aceptadores: actúan como la “memoria” con tolerancia a fallos del protocolo. Los aceptadores forman grupos llamados Quórums. Cualquier mensaje enviado a un aceptador debe ser enviado a un Quórum de aceptadores. ◦ Aprendiz: actúan como el factor de replicación para el protocolo. Una vez que la petición del cliente ha sido acordada por los Aceptadores, el aprendiz puede tomar acción (es decir, ejecutar la petición y enviar una respuesta al cliente).

Consenso - Paxos Basado en Quorum: ◦ Solo es necesario que el valor sea aceptado por mayoría simple

Consenso - Paxos Proponente Aceptador Aprendiz

Fase 1: PREPARE/PROMISE Uno o más nodos deciden ser coordinador (proponente) El nodo proponente propone un valor y solicita la aceptación de un conjunto de nodos aceptadores con un mensaje multicast ◦ PREPARE (N) ◦ N: Las propuestas van ordenadas con un número de propuesta único

Fase 1: PREPARE/PROMISE

Si un nodo aceptador recibe una petición PREPARE (N) con N mayor a cualquier otra petición recibida entonces contesta ◦ PROMISE(n’,v) ◦ Con la promesa de no aceptar otra petición con un numero menor que N ◦ N’ Es el número de la propuesta aceptada antes ◦ V valor de la propuesta, null si no se ha recibido ninguno

Fase 1: PREPARE/PROMISE

Fase 2: ACCEPT/ACCEPTED El proponente A cree que es el líder ◦ Recibió 2/3 mensajes de aceptación El proponente B también cree que es el líder ◦ Recibió 3/3 mensajes de aceptación Ambos generan su propio valor ◦ Todos los aceptadores han recibido el número de propuesta máximo N=4, por lo tanto ignoran los mensajes del proponente A

Fase 2: ACCEPT/ACCEPTED

Los aceptadores aceptan el valor del proponente B y envían un mensaje de aceptación al aprendiz con el valor aceptado ◦ ACCEPTED(v) El aprendiz (learner) envía el valor decidido a todos los nodos ◦ DECIDED (v)

Fase 2: ACCEPT/ACCEPTED

Usos de Paxos Google: Chubby (servicio de cerrojos distribuido basado en Paxos) ◦ Bigtable y otros servicios de Google utilizan Chubby Yahoo: ZooKeeper (servicio de cerrojos distribuido basado en Paxos)

Propiedades de paxos Seguridad: si se alcanza consenso, todos los nodos acuerdan el mismo valor Tolerancia a fallos: si menos de la mitad de los nodos fallan, el resto alcanza acuerdo Terminación no garantizada en casos muy improbables en el mundo real Elección de coordinador

Replicación Modelos de replicación ◦ Modelo síncrono ◦ Modelo asíncrono Variantes ◦ Copia primaria ◦ Basado en quorums

Replicación – Modelo Síncrono Actualizaciones síncronas: se difunden atómicamente a todas las réplicas Consistencia serial: Exigencia de que una operación sea procesada en todas las réplicas en el mismo orden en que se ejecutaron, antes de retornar Esto da lugar a: Baja disponibilidad en actualizaciones Tiempos de respuesta muy altos

Replicación – Modelo Asíncrono Localidad de operaciones: ◦ Cada cliente se comunica únicamente con el servidor local (el más próximo) y recibe una respuesta inmediata ◦ Actualizaciones asíncronas: los servidores replicados cotillean entre si (protocolo gossip) las actualizaciones entre ellos de manera asíncrona o diferida.

Diseminación de datos basada en gossip Basado en el comportamiento epidémico (como se propagan las enfermedades. Se asume que todas las actualizaciones de un dato se inician en un nodo. Propagación: ◦ Un nodo integrante de un grupo de actualización que mantiene información que vale la pena propagar se dice que está infectado ◦ Un nodo que aun no ha visto esta información es susceptible ◦ Un nodo que no esté dispuesto o no pueda propagar la información será eliminado.

Diseminación de datos basada en gossip Antientropía: P elige al azar a otro nodo Q, y posteriormente intercambia información con Q: ◦ P solo empuja (push) sus actualizaciones hacia Q ◦ P solo jala (pull) nuevas actualizaciones desde Q ◦ P y Q se envían actualizaciones entre sí (push-pull) Propagación de rumores (gossiping) ◦ P se acaba de actualizar con el elemento de datos X ◦ P contacta a Q e intenta empujar la actualización a Q ◦ Es posible que Q ya haya sido actualizado previamente ◦ P pierde el interés en difundir la actualización con una probabilidad de 1/k (la actualización se elimina)

Diseminación de datos basada en gossip Analogía a la vida real ◦ Javier se entera de un rumor y quiere contarlo, contacta a Alicia para decírselo ◦ Alicia contacta a Pedro, pero Pedro ya lo sabía, Alicia se desilusiona y deja de contar el rumor ¿Para que llama a otros amigos si ya saben el chisme? Consideraciones ◦ El gossiping es excelente para difundir información ◦ No garantiza que todos los nodos serán actualizados ◦ Si se aplica antientropía se logra la actualización completa.

Replicación – Copia primaria ◦ Actualizaciones: todas las peticiones de actualización se dirigen a la misma réplica que es la que guarda la copia actualizada. La copia primaria se encarga de mantener réplicas esclavas ◦ Consultas: las peticiones de consulta pueden dirigirse a cualquier réplica

Replicación basado en quórums Se definen dos operaciones READ y WRITE Hay un conjunto de N nodos, que sirven peticiones ◦ Un READ debe realizarse sobre R copias ◦ Un WRITE debe realizarse sobre W copias ◦ Cada réplica tiene un número de versión V ◦ Debe cumplirse que: ◦ R + W > N ◦ W + W > N ◦ R, W < N

Replicación basado en quórums Hay un conjunto de N nodos, que sirven peticiones ◦ R numero de copias de lectura ◦ W número de copias de escritura ◦ Cada réplica tiene un número de versión V ◦ Debe cumplirse que: ◦ R + W > N ◦ W + W > N ◦ R, W < N

Replicación basado en quórums READ (Consulta) ◦ Se lee de R réplicas, se queda con la copia con la última versión WRITE (Escritura) ◦ Hay que asegurarse que todas las réplicas se comportan como una sola (seriabilidad) ◦ Se calcula el nuevo número de versión actual. ◦ Se actualizar el valor y el número de versión en W o más réplicas.

Replicación basado en quórums Ejemplo: n= 5, w=3, r=3

Replicación basado en quórums Variante Sloopy quorum En este modelo se toma en cuenta la latencia de las operaciones de lectura o escritura en las réplicas y se calcula en base a la más lenta de R o de W Por esta razón se configura ◦ R + W N ◦ o R + W > N’ donde N’ son los nodos saludables (que no fallan) del conjunto de réplicas del dato Todas las operaciones de lectura y escritura se realizan en los primeros N’ nodos saludables de la lista de preferencias, que no siempre pueden ser los primeros nodos N del clúster (quorum descuidado) Dynamo Amazon

Replicación basado en quórums Variante Sloopy quorum Sin embargo este modelo puede dar lugar a inconsistencias, por ejemplo Por ejemplo, si N’ es igual a 3 tres en un clúster de cinco nodos (A, B, C, D y E) y los nodos A, B y C son los tres principales nodos preferidos, luego se harán escrituras en nodos A, B y C. Pero si B y C no están disponibles el sistema escribirá en D y E en su lugar

Replicación basado en quórums Variante Sloopy quorum Entonces si R es 2, se cumple R + W >N’, e inmediatamente se leen B y C, estos no se interceptan con los nodos que actualizaron que son A, D y E write (op1) 0 0 B C A D E read (op2) 0 0 B C A D E

Replicación basado en quórums Variante Sloopy quorum Las BD NoSQL usan sloopy quorum indican que mitigan este problema usando hinted handoff (Transferencias insinuadas o indicios de trasferencias) Si el sistema tuvo que escribir en los nodos D y E en lugar de los nodos B y C ◦ D informa que su escritura era para B ◦ E informa que su escritura era para C ◦ D y E mantienen esta información en un almacén temporal y periodicamente sondean a B y C para su disponibilidad ◦ Una vez B y C estén disponibles D y E envían los valores 0 0 B C A D E

Replicación basado en quórums Paxos Google Chubby Aceptadores: Servidores de réplicas Aprendizes: Diseminan el valor aprendido a las demas réplicas

Tecnicas de Sharding Sharding manual Problema ◦ No hay garantía de que los datos sean distribuidos de manera uniforme (sesgo) ◦ Ante el fallo de un nodo es muy difícil redistribuir los nodos. Ventajas ◦ Las consultas son mas rápidas (tomar en cuenta que en estos sistemas de BD la mayoría de las consultas son sobre la clave)

Técnicas de Sharding Sharding automático: ◦ Los datos son revisados por una distribución uniforme ◦ Los datos son accedidos desde cualquier nodo mediante un algoritmo que dirige la solicitud al nodo particular ◦ Mas fácil rebalancear los datos Desventaja ◦ Las consultas pueden ser mas lentas si no se cuenta con índices

Técnicas de Sharding Hashing Consistente: ◦ A los elementos de datos se les asigna una clave aleatoria en un espacio grande. ◦ A los nodos se les asigna un número aleatorio en el mismo espacio identificador ◦ El sistema mapeará cada elemento de datos con un identificador de nodo. ◦ Cada nodo podrá recibir cualquier petición y enrutarla al nodo correspondiente

Ejemplo: Chord A cada nodo se le asigna un identificador único en un espacio m Los nodos se organizan en un anillo lógico de tamaño N (numero de nodos) tal que k + N << 2 m. Cada nodo tiene una tabla de enrutamiento con m entradas. ◦ k se mapea hacia el nodo con el identificador más pequeño id>=k. ◦ Este nodo se conoce como el sucesor de la clave k.

Ejemplo: Chord

Ejemplo: Chord Cómo recorrer e anillo Cell Index Referenced GUID GUID Distance 011 (2 0 ) 122 (2 1 ) 244 (2 2 ) 388 (2 3 )

Ejemplo: Chord Cómo recorrer e anillo

Ir del nodo o al nodo 15 usando las tablas de enrutamiento

Ejemplo de tablas de enrutamiento: Finger tables Cada nodo almacena información acerca de sólo un pequeño número de otros nodos. Una Tabla finger de un nodo en general no contiene suficiente información para determinar el sucesor de una clave k arbitraria Consultas repetitivas a los nodos que preceden inmediatamente a la clave dada conducirán al sucesor de la clave con el tiempo

60 Finger Tables (1) [1,2) [2,4) [4,0) finger table startint.succ. keys [2,3) [3,5) [5,1) finger table startint.succ. keys [4,5) [5,7) [7,3) finger table startint.succ. keys 6

Manejo de inconsistencias: Finger tables Un Protocolo de "estabilización" básico es utilizado para mantener los apuntadores a los nodos sucesores “al día”, lo cual es suficiente para garantizar la exactitud de las búsquedas Estos apuntadores a sucesores pueden usarse para verificar las entradas de la tabla finger Cada nodo ejecuta stabilize periódicamente para encontrar nodos que se unieron recientemente al anillo o que lo abandonaron.

62 Unión del nodo 6 – con Finger Tables [1,2) [2,4) [4,0) finger table startint.succ. keys [2,3) [3,5) [5,1) finger table startint.succ. keys [4,5) [5,7) [7,3) finger table startint.succ. keys finger table startint.succ. keys [7,0) [0,2) [2,6)

63 Salida del nodo 1– con Finger Tables [1,2) [2,4) [4,0) finger table startint.succ. keys [2,3) [3,5) [5,1) finger table startint.succ. keys [4,5) [5,7) [7,3) finger table startint.succ. keys finger table startint.succ. keys [7,0) [0,2) [2,6)

Próxima clase Paxos vs Two fase commit Repaso Examen Jueves BD NoSQL Clave – Valor: ◦ Modelo de datos ◦ Operaciones ◦ Técnicas usadas ◦ Caso de estudio