DynamoDB, análisis del paper.
-
Upload
javier-de-la-rosa-fernandez -
Category
Engineering
-
view
98 -
download
0
Transcript of DynamoDB, análisis del paper.
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/