Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

DynamoDB, análisis del paper.

744 Aufrufe

Veröffentlicht am

Analisis del paper de DynamoDB.

Veröffentlicht in: Ingenieurwesen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

DynamoDB, análisis del paper.

  1. 1. DynamoDB José A. San Miguel Carrillo Javier de la Rosa Fernández Alexandra Conde Hermo Manuel Bazaga Carmen Alonso Martínez
  2. 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. 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. 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. 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. 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. 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. 8. Trabajo relacionado Peer to Peer Systems Freenet y Gnutella Structured P2P Networks (Pastry y Chord) DHT Oceanstore y PAST (Sistemas de almacenamiento)
  9. 9. Trabajo relacionado Distributed File Systems and Databases Ficus y Coda Farsite - NFS (Network File System) Google File System GFS (Global Forecast System)
  10. 10. Trabajo relacionado Distributed File Systems and Databases Bayou Antiquity (Byzantine para asegurar consistencia) Big Table
  11. 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. 12. Arquitectura ● Interfaz ● Particionado ● Alta disponibilidad en Escrituras ● Gestion de fallos ● Detección y recuperación ante fallos
  13. 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. 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. 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. 16. Replicacion
  17. 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. 18. http://cloudacademy.com/blog/data-versioning-with-dynamodb-an-inside-look-into-nosql-part-5/
  19. 19. http://www.slideshare.net/advaitdeo/dynamodb-presentation- 31000206
  20. 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. 21. http://www.slideshare.net/advaitdeo/dynamodb-presentation- 31000206
  22. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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/

×