Introducción a Voldemort - Innova4j

1,908 views

Published on

Introducción a Voldemort

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Introducción a Voldemort - Innova4j

  1. 1. Proyecto Voldemort
  2. 2. Plan de trabajoParte I – Acerca de Voldemort  Qué es Voldemort? ¿Quienes lo usan? ¿Parte II - Visión general de la arquitectura Voldemort.Parte III - Entrando en detalles nstalación, configuración y API con ejemplos de código. I  ecomendaciones a la hora de iniciar un proyecto con RVoldemort.  onclusiones C
  3. 3. Parte I – Acerca de Voldemort  oldemort es un sistema distribuido de bases de datos Vclave-valor.  plica el concepto clásico de cluster. Sus nodos son Aindependientes (no maestro/esclavo). No hay un puntocentral de coordinación.  stá siendo utilizado con éxito en LinkedIn (sus creadores) Ey muchas otras empresas que requieren el procesamientode grandes volúmenes de información con un alto numerode operaciones concurrentes y tiempo de respuestaexigentes.  00% Java y open source. 1
  4. 4. Características del cluster  scalabilidad: habilidad de un servidor para procesar Eeficientemente múltiples peticiones concurrentessimultáneamente.  alanceo de carga: distribución de la carga de las Bpeticiones en un grupo de servidores.  lta disponibilidad: incremento del tiempo que el servicio Aestá disponible para procesar peticiones.
  5. 5. Un poco de historia ILinkedIn es un servicio web que conforma una red socialorientada a negocios.Empleado principalmente para contactos profesionales,cada usuario mantiene una lista de “conexiones” para:  ncontrar trabajo, personas, oportunidades. E  onocer novedades de las compañías. C  tc. E
  6. 6. Un poco de historia II Infraestructura de LinkedIn: inicialmente una enorme base de datos monolítica y un cluster de servidores para el front-end.Al crecer la empresa, la BD se dividió enservicios remotos para proveer perfiles,ejecutar búsquedas, interactuar congrupos, contactar compañías, etc. EstasBD tenían réplicas de sólo-lectura, perolas escrituras no eran escalables.
  7. 7. Un poco de historia IIIMuchas funcionalidades web que la gente exige hoy en díarequieren conjuntos masivos de datos, altas cargas deescritura, o ambos. Los tiempos de respuesta que seobtenían no eran satisfactorios.
  8. 8. Un poco de historia IV¿Cómo mejorar el tiempo de respuesta?Se revisaron los productos que otras empresas de Internethabían desarrollado. Interesante el BigTable de Google,pero no tiene sentido construir algo similar sin un GFS(Global File System) de baja latencia.En su lugar, se tomaron conceptos del Amazons Dynamopaper, que parecía cumplir las necesidades y era factible deimplementar.
  9. 9. Un poco de historia VResultados:Gestionar aplicaciones con cientos de millones de lecturas/escrituras por día.Bajaron de 400ms a 10ms y simultáneamente creció lacantidad de registros almacenados.
  10. 10. Código abierto como estrategia  inkedIn provee un servicio web, no es una casa de Lsoftware.  ecidieron que necesitaban una BD clave-valor, ya que no Dencontraron ninguna que los satisfaciera, la construyeron.  ero necesitaban ayuda con el soporte, así que lo Pconvirtieron en código abierto. Hoy más de la mitad dequienes modifican el código no son miembros de LinkedIn.
  11. 11. En producción ILinkedIn  NA Team (Search, Network, and Analytics) S  lusters con 12 nodos (y creciendo) C  cores y muy bajo consumo de C.P.U. 8  sos: personas que conoces, quién ha visto mi perfil, Uprocesamiento de noticias, sistema de correo,comunicaciones, y más.
  12. 12. En producción IIKaChing  ervicio de contactos para hacer inversiones. Empezó Scomo una aplicación de Facebook.  sa Voldemort desde Febrero de 2010. U  esafíos: alto tráfico, grandes conjuntos de datos. D  luster de 6 nodos. C  sos: datos del mercado de acciones, historia de usuarios, Uanálisis.
  13. 13. En producción IIIeHarmony  usca de pareja en Internet. B  sa Voldemort desde Abril de 2009. U  res clusters de producción: de tres, siete y diez nodos. T
  14. 14. En producción IVGilt Groupe  itio de ventas premium. S  sa Voldemort desde Agosto de 2009. U  res clusters de cuatro nodos cada uno. T  sos: “Shopping Cart”, almacenamientos separados para Uel procesamiento de ordenes, eventos de ventas con picosdiarios.
  15. 15. Innova4j y Voldemort ICaracterísticas del proyectoUno de nuestros principales clientes dedicado a operaciones de ventas onlines,nos planteo la necesidad de desarrollar una nueva plataforma online de bajocoste que le permitiera soportar un promedios de 20 millones de peticionesdiarias con la capacidad de gestionar más de 800 millones de registros activos quedeberían ser consultados durante las peticiones de disponibilidad y donde lostiempos de respuesta no fueran superiores a 3 segundos.Puntos claves del proyecto y "Drivers" de la arquitectura  menor tiempo de respuesta, mayor posibilidad de venta. A  menor coste de infraestructura, precios mas competitivos. A  estión de un número elevado de peticiones concurrentes. G  anejo de grandes volúmenes de información. M
  16. 16. Innova4j y Voldemort II Un enfoque pragmáticoConjuntamente con nuestro cliente se decidió dividir el proyecto en 2 grandesfases que nos permitieran mejorar el "Time to market" de la plataforma. La primera fase del proyecto nos permitió garantizar la lógica de negocio yestructurar una arquitectura flexible y fácil de escalar; pero sin incluir unasolución NoSQL.Ventaja : Nos dedicamos a consolidar la oportunidad de negocio de nuestrocliente, liberando rápidamente un producto que le permitiera madurar suestrategia de negocio.  n la Segunda fase del proyecto nos enfocamos en cumplir en un 100% con los Epuntos claves del proyecto.Ventaja : La lógica de negocio ya estaba implementada con un enfoque TDD, loque nos permitió asegurar que el incluir una solución NoSQL fuese algo controladoy fiable que nos permitirá dar solución a los requerimientos de escalabilidad,tiempo de respuesta y manejo de grandes volúmenes de información sin impactaren la lógica de negocio.
  17. 17. Parte IIVisión general de la arquitectura de Voldemort
  18. 18. Decisiones de arquitectura  e almacenan datos “solo” en formato clave-valor. S  o se soportan consultas complejas o joins. N  as únicas operaciones con los datos son put, get, getAll y Ldelete.  onsistent hashing para asignar datos a los nodos. C  olerancia a fallos en los nodos se logra por medio de Treplicación.  a consistencia distribuida se logra con versiones y la Ltécnica read-repair.
  19. 19. Arquitectura lógica Cada capa aporta en las operaciones solicitadas. Cada capa ejecuta una función como comunicación tcp/ip, serialización, etc. La capa de enrutamiento envía una operación (digamos un put) a N nodos en paralelo. Tener estas capas permite flexibilidad en tiempo de ejecución, por ejemplo añadir compresión de bytes en cualquier punto por debajo de la capa de serialización.
  20. 20. Formato de los datos IEl equivalente de una tabla relacional se denomina store.Cada clave queda asociada a un store. El dato puede ser tancomplejo como se necesite (listas, grafos, etc.).
  21. 21. Formato de los datos IILa simplicidad de las consultas hace que resulte muysencillo crear un simulador de la BD para pruebas unitariascon una estructura que es prácticamente una tabla hash.
  22. 22. Particionamiento de los datos I  onsiste en tener copias/replicas de un subconjunto de los Cdatos en diversos nodos.  ecesario para que ningún nodo tenga todos los datos. N  ún si todos caben en un nodo, el acceso a disco se Aconvertiría en el factor preponderante.  l dividir en nodos, los datos más buscados podrían caber Aen cada caché.
  23. 23. Particionamiento de los datos IIToda la complejidad del particionamiento es transparentepara el desarrollador, gracias a las diferentes capasimplementadas en su arquitectura
  24. 24. Consistent hashing Cuando un nodo se adiciona solo es necesario mover un subconjunto de los datos. Se usa para calcular la ubicación de una clave en el cluster. Cuando un nodo falla se redistribuye la carga.
  25. 25. Consistencia de los datos IDifícil de lograr al tener que escribir en múltiples nodos (ytal vez múltiples data-centers).Usualmente se usan transacciones distribuidas pero sonlentas y frágiles.Una alternativa es tolerar la posibilidad de inconsistenciastemporales, y resolverlas cuando se hagan lecturas de datos(read-repair).
  26. 26. Consistencia de los datos IICon Read-repair cuando se hace una lectura se detectan yresuelven los conflictos. Esto implica poca coordinación y escompletamente tolerante a fallos, pero puede requerir máslógica en la aplicación desarrollada.
  27. 27. Consistencia de los datos IIICAP: Consistency, Availability, Partition Tolerance (red).  olo se garantizan 2 de 3 en todo momento. S  oldemort escoge consistencia eventual (AP) por que: V Permite multi-datacenters.  Buen rendimiento tanto para lecturas como escrituras.  Por configuración se puede mejorar la C. 
  28. 28. Versionamiento IUn sistema de versionado simple es igual a un bloqueooptimista: se almacena un contador o “clock” con cadadato y solo se puede actualizar si se tiene el contadorcorrecto.Ese enfoque no funciona en un sistema distribuido ya quelos nodos aparecen y desaparecen y la replicación puedetomar tiempo.
  29. 29. Versionamiento IIVoldemort usa versionamiento por vector-clock, el cualmantiene un contador por cada nodo para calcular cuandodos versiones están en conflicto.
  30. 30. SerializaciónEn el nivel más bajo los datos (claves y valores) son arreglosde bytes.Aunque Voldemort viene con serializadores para textos,objetos Java y flujos de bytes en bruto, implementando lainterfaz Serializer se puede escribir su propio serializador.
  31. 31. Parte IIIEntrando en detalles
  32. 32. Instalación I  onsiste en descomprimir un zip. C ncluye scripts para Linux fácilmente migrables a Windows. I  o hemos instalado en Linux, Windows y Mac. L  iene con ejemplos de configuración. V  n la distribución por defecto los clusters se configuran en Esub-carpetas.
  33. 33. Instalación IILa estructura de archivos resultante es la siguiente:
  34. 34. Instalación III Ejemplo de interacción básica por línea de comandos:$voldemort-server.bat ..configutil_nodo1$voldemort-shell.bat testStore tcp://localhost:6666>put “CLI-001” “[{“fecha”=”25-01-2020”},{“fecha”=”28-01-2020”}]”>get “CLI-001”version(0:1):“[{“fecha”=”25-01-2020”},{“fecha”=”28-01-2020”}]”> delete "CLI-001"> get "CLI-001"null> exit
  35. 35. Configuración ILa operación de un servidor Voldemort se configura con 3archivos: server.properties, cluster.xml y stores.xml.Los dos últimos deben tener el mismo contenido en todoslos nodos del cluster.
  36. 36. Configuración IIserver.properties contiene los parámetros de afinamientode cada nodo.Incluye su identificador, tamaño del pool de hilos, así comoel mecanismo de persistencia local (por ejemplo BDB o enmemoria).Este archivo es diferente en cada nodo.
  37. 37. Configuración IIInode.id=0max.threads=200 #Máximo número de hilos en el servidorsocket.enable=true #comunicación por socketshttp.enable=true #comunicación por HTTPjmx.enable=true #monitorizaciónrouting.timeout.ms=5000 #En espera de respuesta de los nodos.enable.bdb.engine=true #Activar Berkeleybdb.cache.size=100MB #Caché de Berkeley
  38. 38. Configuración IVcluster.xml contiene la información de todos los nodos(servidores) del cluster, como sus IPs, puertos de conexión,etc. El id del nodo mapea al de server.properties.Este archivo es igual en todos los nodos.
  39. 39. Configuración V<cluster> <name>Integrations cluster</name> <server> <id>0</id> <host>localhost</host> <socket-port>7711</socket-port> <partitions>0, 1</partitions> </server> <server> ...</cluster>
  40. 40. Configuración VIstores.xml contiene información de los almacenamientos(stores). Un store es similar a una tabla.Incluye:  a cantidad de nodos accedidos en lecturas y escrituras. L  a forma de serializar las claves y valores. LEste archivo es igual en todos los nodos.
  41. 41. Configuración (vii)<store> <name>protobufAvail</name> <replication-factor>2</replication-factor> <required-reads>1</required-reads> <required-writes>2</required-writes> <key-serializer> <type>string</type> </key-serializer> <value-serializer> <type>protobuf</type> <schema-info>java=com.innova4j.Availability</schema-info> </value-serializer></store><store>...
  42. 42. Propuesta capa intermedia de acceso a datos
  43. 43. APIs del servicioVoldemort ofrece un API administrativo y un API cliente.
  44. 44. API administrativoPermite realizar labores administrativas que casi nunca sonnecesarias a nivel de aplicación, por ejemplo:  xtraer registros para backups. E  igrar particiones. M  btener datos de configuración del cluster. OLa clase principal es AdminClient.
  45. 45. API clientePermite la interacción típica de manipulación de datos.  lientConfig: agrupa parámetros de configuración para la Cconexión del cliente (ip, puerto, timeout, etc.).  ocketStoreClientFactory: encapsula el pool de Sconexiones, hilos, y permite crear instancias de StoreClient.  toreClient: para manipular cada store de Voldemort (get, Sput, delete, etc.)[IDE]
  46. 46. Opciones de serialización IVoldemort permite indicar el tipo de serialización de losdatos almacenados. Los opciones son:   tring s   son j   ava-serialization j   rotobuff p   hrift t  dentity (bytes en bruto) i
  47. 47. Opciones de serialización IISe realizó un laboratorio para comparar las prestaciones delprocesamiento con Json, Jackson y Protobuff (de Google yde ActiveMq).
  48. 48. Opciones de serialización IIITiempo de procesamiento de datos en memoria
  49. 49. Opciones de serialización IVTiempo de procesamiento de datos con E/S Voldemort.Se elimina ActiveMq
  50. 50. Opciones de serialización VUso del pre-compilador de Protobuff y el patrón Builder.[IDE]
  51. 51. Recomendaciones para iniciar un proyecto con bases de datos NoSQL Determine si los requerimientos de escalabilidad, volumen de datos y concurrencia de la aplicación que va a desarrollarjustifican el uso de una tecnología NoSQL. Identifique que tipo/familia de base de datos NoSQL encaja mejor con sus necesidades. No todos los datos tienen que estar almacenados en una base de datos NoSQL. Use NoSQL donde realmente aporta valor. Cuando diseñe su aplicación piense en la estructura de datos y la forma más optima de acceder a ella, en NoSQL es recomendablepensar en ello desde el inicio.
  52. 52. Conclusiones  as bases de datos NoSQL son una realidad que permiten Lsolventar problemas para los que las bases de datos relaciones nofueron diseñadas (aun).  l diseño de una buena arquitectura debe permitir que las bases Ede datos relacionales y las bases de datos NoSQL coexistan.  a tecnología NoSQL esta en proceso de madurez y evolución, lo Lque hace necesario un seguimiento continuo de los nuevosproductos y de las nuevas versiones de los ya existentes.  a mejor forma de evaluar y estar seguros que la tecnología LNoSQL puede encajar en sus proyectos es realizando sus propioslaboratorios. (para creer hay que tocar)
  53. 53. Gracias por la atención prestada. Innova4j “Dando soluciones hoy y alternativas para el futuro”

×