Analisis del paper de DynamoDB.

1. DynamoDB
José A. San Miguel Carrillo
Javier de la Rosa Fernández
Alexandra Conde Hermo
Manuel Bazaga
Carmen Alonso Martínez

2. Introducción
● Requisitos operativos en términos de:
rendimiento, fiabilidad y eficiencia.
● Altamente escalable.
● Almacenamiento siempre disponibles
(Amazon S3)
● Acceso con primary-key

3. Introducción
● Data es particionada y replicada usando
hashing consistente y object versioning
(consistencia: técnica de quórum similar y
un protocolo de sincronización de réplica
descentralizado)
● Almacenamiento eventualmente consistente

4. Trasfondo
¿Qué es?
BD no relacional Uso de recursos eficiente
Interfaz (k,v) Escalable
Alta disponibilidad
¿Para quién?
● Para Amazon
● Para aquellos con problemas similares:
o No requieren querys ni manejo complejo
o Prefieren disponibilidad sobre consistencia

5. Requisitos
Query Model:
R/W simple. Objetos identificados por clave única
Las operaciones no afectan a más de un objeto
Objetos<1MB
ACID:
Sacrifica consistencia por disponibilidad.
No garantiza aislamiento y permite sólo
actualizaciones por clave única
Eficiencia:
Sacrifica rendimiento, disponibilidad y eficiencia
en coste para alcanzar latencias muy bajas y
consistentes.
Supuestos
“Dynamo sólo es usado
por Amazon”
● Se asume un ambiente no
hostil.
● No se tienen en cuenta
requisitos de seguridad.
● El primer dimensionamiento
se hace acorde a las
necesidades de Amazon.

6. SLA - service level agreement
● Medido en el percentil 99.9, no en la media.
● tr,tw<300ms
● Enfocado a mejorar la experiencia de todos
los usuarios, no de la mayoría.

7. Consideraciones del diseño
Eventualmente consistente - las actualizaciones llegan a
las réplicas eventualmente… ¿cuándo? ¿R/W?
Siempre podremos escribir.
Otros principios del diseño
Escalabilidad
Simetría
Descentralización
Heterogeneidad

8. Trabajo relacionado
Peer to Peer Systems
Freenet y Gnutella
Structured P2P Networks (Pastry y Chord) DHT
Oceanstore y PAST (Sistemas de almacenamiento)

9. Trabajo relacionado
Distributed File Systems and Databases
Ficus y Coda
Farsite - NFS (Network File System)
Google File System
GFS (Global Forecast System)

10. Trabajo relacionado
Distributed File Systems and Databases
Bayou
Antiquity (Byzantine para asegurar consistencia)
Big Table

11. Trabajo relacionado
Discusión
● Always writeable.
● Infraestructura dentro de un dominio administrativo
único.
● No requieren soporte para espacios de nombres
jerárquicos
● Se construye para aplicaciones sensibles a la latencia

12. Arquitectura
● Interfaz
● Particionado
● Alta disponibilidad en Escrituras
● Gestion de fallos
● Detección y recuperación ante fallos

13. Interfaz
● Almacenamiento <clave,valor>
● Operaciones:
o get(key): Devuelve un objeto (o una lista) de objetos (incluidos
los conflictos)
o put(key,context,object): Localiza donde escribir un objeto (y
sus réplicas) a partir de una clave
 Context contiene metainformación tal como versionado,
validaciones, etc.
● Se generan identificadores de 128-bits aplicando
MD5 a las claves

14. Particionado
● Diseñado para un escalado incremental mediante nodos
● Esquema de particionado distribuido mediante “Consistent
hashing”
o Claves distribuidas en estructura de anillo en varios nodos
o Cada nodo es responsable de gestionar un rango de claves
o Nodos virtuales para gestionar la carga y repartición de las claves
● Cada nodo acepta una carga equivalente a las de sus
vecinos.

15. Replicacion
● Cada clave (k) es asignada a un coordinador (i)
● Cada valor (v) se replica en los nodos (lógicos) (N-
1) segun el sentido horario
● El coordinador (i) es responsable de actualizar el
resto de nodos para las claves que posee.
● Cada clave (k) sabe los nodos físicos responsables
de mantener y acceder a los valores.

16. Replicacion

17. Versionado
● Consistencia Eventual
● Los datos son actualizados de forma asincrona
o put() se devuelve el dato antes de actualizar todas
las replicas
o get() puede devolver versiones (no actualizadas) del
mismo valor
● “Siempre escribe”
o Carrito de la compra
● “Vector de tiempo” para el versionado

18. http://cloudacademy.com/blog/data-versioning-with-dynamodb-an-inside-look-into-nosql-part-5/

19. http://www.slideshare.net/advaitdeo/dynamodb-presentation-
31000206

20. Resolución de conflictos
● Sintáctica (interna)
o Resolucion automatica
● Semántica (cliente)
o Es el cliente quien decide cómo resolver el conflicto
o Ejemplo: Carrito de la compra
 Siempre se mantienen los items añadidos
 Pueden “volver a aparecer” elementos borrados

21. http://www.slideshare.net/advaitdeo/dynamodb-presentation-
31000206

22. put() & get()
● 2 estrategias para seleccionar un nodo
o En función de la carga (Generic load-balancer)
o Partition aware client-library
● Operaciones de lectura y escritura a través de un nodo Coordinador
● Quorum como protocolo de consistencia
o Operación de escritura se realizará en (N/2) +1 nodos
● Para mantener la consistencia se utilizan 3 variables
o N – Numero de nodos
o W – Número de nodos para escribir
o R – Número de nodos para leer

23. put()
● Ante una escritura, el coordinador genera el Vector de
tiempo y escribe localmente
● El coordinador réplica hacia los N nodos de su lista
● Si al menos W-1 nodos responden, la escritura es
correcta

24. get()
● El coordinador pide todas las versiones del objeto a los
N nodos de su lista
● Espera al menos a que R nodos respondan con el dato
● Si hay diferentes versiones, delega en el cliente su
resolución
● El cliente resuelve el conflicto y actualiza el dato

25. Hinted Handoff
● Asumiendo N=3, un fallo en una operacion
put() en el node A is administrado
temporalmente por B.
● Después de que A se recupere, B envia el
resultado de la operación put() a A.
● Ventaja: Los fallos temporales tienen un
mínimo efecto en la aplicación.

26. Escalabilidad
● Para añadir o quitar nodos se necesita
interacción directa
● Protocolo “Gossip”
o Detección de fallos
o Propagaciones en el cluster
● La sincronización de las replicas se realiza
mediante un Merkel hash tree

27. Implementación
Persistencia local, solicitud de coordinación y detección
de fallos
Persistencia local: diferentes motores (BDB, MySQL etc) - depende del tamaño
del objeto.
Solicitud de coordinación:
Petición R -> State machine -> enviar petición a nodos -> esperar y recibir
respuestas (si se reciben pocas la petición es fallida) -> decidir la versión de los
datos a devolver -> actualizar nodos a la última versión (read repair)
Petición W -> puede ser coordinada por cualquiera de los “top N nodes”
Generalmente el que antes respondió al read, para mantener la consistencia.

28. Estrategias seguidas con Dynamo
● Reconciliación lógica del negocio
● Reconciliación basada en Timestamp
● Alto rendimiento en lecturas
o N (Nodes) W (Writes) R(Read)

29. Dynamo es personalizable
● El poder cambiar los valores de N, W y R nos permite
adaptar Dynamo a nuestras necesidades.
o Bajos valores de W y R dan posibles riesgos de
inconsistencia
o Incrementando W se dotará de mayor durabilidad
o La configuración estándar es (3,2,2)

30. Equilibrio rendimiento-durabilidad
● El típico SLA ofrecido por Dynamo es 99.9% de
lecturas y escrituras a 300ms de latencia.
● Para algunos clientes esto no es aceptable y prefieren
intercambiar garantías de durabilidad por rendimiento.
○ Buffer en memoria

31. Distribución uniforme de la carga
● Un nodo está fuera de equilibrio si supera un cierto
umbral (por ejemplo un 15%) con respecto a la media
de peticiones en un determinado periodo de tiempo.
● Los tokens son nodos virtuales que se podrán distribuir
según las siguientes estrategias
○ ESTRATEGIA 1: T Tokens aleatorios por nodo
○ ESTRATEGIA 2: T Tokens del mismo tamaño
○ ESTRATEGIAS 3: Q/S Tokens por nodo y particionado del mismo
tamaño.

32. Conclusiones
Durante el tiempo de vida de Dynamo se ha
contrastado:
● El 99.9995% de peticiones de datos se han producido sin pérdida
● Configurable (N,R,W)
● Altamente disponible, es posible el manejo de los fallos e inconsistencias.

33. Bibliografia
● http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
● http://cloudacademy.com/blog/dynamodb-replication-and-partitioning-part-
4/
● http://cloudacademy.com/blog/data-versioning-with-dynamodb-an-inside-
look-into-nosql-part-5/