DynamoDB

José A. San Miguel Carrillo

Javier de la Rosa Fernández

Alexandra Conde Hermo

Manuel Bazaga

Carmen Alonso Martínez

Introducción

● Requisitos operativos en términos de:

rendimiento, fiabilidad y eficiencia.

● Altamente escalable.

● Almacenamiento siempre disponibles

(Amazon S3)

● Acceso con primary-key

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

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

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

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.

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

Trabajo relacionado

Peer to Peer Systems

Freenet y Gnutella

Structured P2P Networks (Pastry y Chord) DHT

Oceanstore y PAST (Sistemas de almacenamiento)

Trabajo relacionado

Distributed File Systems and Databases

Ficus y Coda

Farsite - NFS (Network File System)

Google File System

GFS (Global Forecast System)

Trabajo relacionado

Distributed File Systems and Databases

Bayou

Antiquity (Byzantine para asegurar consistencia)

Big Table

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

Arquitectura

● Interfaz

● Particionado

● Alta disponibilidad en Escrituras

● Gestion de fallos

● Detección y recuperación ante fallos

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

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.

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.

Replicacion

Versionado

● Consistencia Eventual

● Los datos son actualizados de forma asincronao 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

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

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

31000206

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

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

31000206

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

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

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

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.

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

Implementación

Persistencia local, solicitud de coordinación y detección

de fallosPersistencia 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.

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)

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)

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

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.

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.

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/