Este documento presenta información sobre técnicas de bases de datos NoSQL como la disponibilidad, el consenso, la partición y la replicación. Explica el modelo de ordenación con marcas de tiempo multiversión MVCC de Reed, incluyendo cómo se manejan las lecturas y escrituras. También cubre algoritmos de elección como el anillo y el matón, y protocolos de consenso como Paxos, incluyendo sus roles, fases y propiedades. Por último, revisa modelos de replicación como el síncrono, asíncrono, copia primaria

1. Bd NoSQL
Técnicas III
PROFA. MERCY OSPINA
mercy.ospinat@gmail.com

2. Agenda
Disponibilidad
Consenso
Partición
Replicación

3. 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

4. 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.

5. 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.

6. 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

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

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

9. 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
◦ pii tiene una variable: electedi, con el líder elegido por pi, o el
valor null

10. 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

11. Elección Anillo
Inicialmente, ∀𝑖; 𝑝𝑎𝑟𝑡𝑖𝑐𝑖𝑝𝑎𝑛𝑡𝑖 = 𝐹𝐴𝐿𝑆𝐸
Cuando pi inicia una elección
◦ 𝑝𝑎𝑟𝑡𝑖𝑐𝑖𝑝𝑎𝑛𝑡𝑖 = 𝑇𝑅𝑈𝐸
◦ Agrega id i a un mensaje elección, y lo envía a VECINO(P)
Cuando pj recibe un mensaje election con id k
◦ IF id j > id k
◦ IF 𝑝𝑎𝑟𝑡𝑖𝑐𝑖𝑝𝑎𝑛𝑡𝑗 = 𝐹𝐴𝐿𝑆𝐸
◦ Reenvía mensaje election, pero con id j
◦ 𝑝𝑎𝑟𝑡𝑖𝑐𝑖𝑝𝑎𝑛𝑡𝑗 = 𝑇𝑅𝑈𝐸
◦ ELSE
◦ Reemplaza idk por idj , pero no reenvía
◦ ELSE IF id j < id k
◦ Reenvía mensaje election
◦ 𝑝𝑎𝑟𝑡𝑖𝑐𝑖𝑝𝑎𝑛𝑡𝑗 = 𝑇𝑅𝑈𝐸
◦ ELSE (id j == idk )
◦ Envía mensaje elected con id j
◦ 𝑝𝑎𝑟𝑡𝑖𝑐𝑖𝑝𝑎𝑛𝑡𝑗 = 𝐹𝐴𝐿𝑆𝐸
◦ electedj = id j

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

13. 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

14. 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.

15. Algoritmo del Matón

16. Algoritmo del Matón

17. 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)

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

19. 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

20. 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.

21. 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).

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

23. Consenso - Paxos
Proponente
Proponente
Aceptador
Aceptador
Aceptador
Aprendiz

24. 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

25. Fase 1: PREPARE/PROMISE

26. 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

27. Fase 1: PREPARE/PROMISE

28. Fase 1: PREPARE/PROMISE

29. 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

30. Fase 2: ACCEPT/ACCEPTED

31. 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)

32. Fase 2: ACCEPT/ACCEPTED

33. 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)

34. 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

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

36. 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

37. 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.

38. 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.

39. 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)

40. 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.

41. 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

42. 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

43. 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

44. 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.

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

46. 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, en lugar del esquema clásico 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

47. 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

48. 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
0B
C
1
1
1A
D
E
read (op2)
0
0B
C
1
1
1A
D
E

49. Replicación basado en quórums
Hinted handff
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
0B
C
1
1
1A
D
E
0
0
1
1

50. Replicación basado en quórums
Hinted handff
A Little Riak Book, Eric Redmond & John Daily, 2.0.0 2014-10-15

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

52. 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)

53. 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

54. Técnicas de Sharding
Usando Intervalos o rangos de claves
◦ Usada por MongoDB y Hbase
◦ El manejo de fallas se hace a través de las réplicas que
garantizan que los datos estén en los nodos activos
Nodo 1 Nodo 2 Nodo 3 Nodo 4
Key Range
0..25
Key Range
26..50
Key Range
51..75
Key Range
76.. 100

55. Técnicas de Sharding
Hashing Consistente o tablas hash distribuidas:
◦ La consulta se puede iniciar en cualquier nodo
◦ Los nodos están configurados en un anillo lógico
◦ 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

56. Ejemplo: Chord

57. Ejemplo: Chord o cuerdas
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 << 2m .
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 =>succ(k)

58. Ejemplo: Chord
Cómo recorrer e anillo
Cell Index
Referenced
GUID
GUID Distance
0 1 1 (20)
1 2 2 (21)
2 4 4 (22)
3 8 8 (23)

59. Ejemplo: Chord
Cómo recorrer e anillo

60. Ejemplo: Chord
Cómo recorrer e anillo
Ir del nodo o al nodo
15 usando las tablas
de enrutamiento
http://tutorials.jenkov.com/p2p/index.html

61. 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

62. Ejemplo: Chord o cuerdas
El objetivo es resolver de manera eficiente una clave
k para la dirección succ(k)
si FTp denota la tabla de enrutamiento o tabla finger
dentro del nodo, entonces
FTp[i]=succ(p+2i-1)
Si un nodo p recibe una petición para resolver una
clave k, reenviará la petición de inmediato al nodo q
con índice j en la FTp tal que
q=FTp[j] ≤ k < FTp[j+1]

63. 63
Finger Tables (1)
0
4
26
5
1
3
7
1
2
4
[1,2)
[2,4)
[4,0)
1
3
0
finger table
start int. succ.
keys
1
2
3
5
[2,3)
[3,5)
[5,1)
3
3
0
finger table
start int. succ.
keys
2
4
5
7
[4,5)
[5,7)
[7,3)
0
0
0
finger table
start int. succ.
keys
6
El primer sucesor del
nodo 0 es el 1, quien
es responsable de
las claves 1≤ k <2

64. 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.

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

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

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

68. 68
Salida del nodo 1– con Finger
Tables
0
4
26
5
1
3
7
1
2
4
[1,2)
[2,4)
[4,0)
1
3
0
finger table
start int. succ.
keys
1
2
3
5
[2,3)
[3,5)
[5,1)
3
3
0
finger table
start int. succ.
keys
2
4
5
7
[4,5)
[5,7)
[7,3)
6
6
0
finger table
start int. succ.
keys
finger table
start int. succ.
keys
7
0
2
[7,0)
[0,2)
[2,6)
0
0
3
6
6
6
0
3
7

69. 69
Búsqueda de claves – con Finger
Tables
0
4
26
5
1
3
7
1
2
4
[1,2)
[2,4)
[4,0)
1
3
0
finger table
start int. succ.
keys
1
2
3
5
[2,3)
[3,5)
[5,1)
3
3
0
finger table
start int. succ.
keys
2
4
5
7
[4,5)
[5,7)
[7,3)
6
6
0
finger table
start int. succ.
keys
finger table
start int. succ.
keys
7
0
2
[7,0)
[0,2)
[2,3)
0
0
3
6
6
6
0
7
Si en el nodo 0 se consulta la clave 5
1. Se consulta la finger table y el
sucesor 6 tiene las claves
mayores que 4
2. El nodo 6 tiene la clave buscada

70. Próxima clase
Exámen
BD NoSQL Clave – Valor:
◦ Modelo de datos
◦ Operaciones
◦ Técnicas usadas
◦ Caso de estudio