Introducción a Voldemort

1. Proyecto Voldemort

2. Plan de trabajo
Parte 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
R
Voldemort.
 onclusiones
C

3. Parte I – Acerca de Voldemort
 oldemort es un sistema distribuido de bases de datos
V
clave-valor.
 plica el concepto clásico de cluster. Sus nodos son
A
independientes (no maestro/esclavo). No hay un punto
central de coordinación.
 stá siendo utilizado con éxito en LinkedIn (sus creadores)
E
y muchas otras empresas que requieren el procesamiento
de grandes volúmenes de información con un alto numero
de operaciones concurrentes y tiempo de respuesta
exigentes.
 00% Java y open source.
1

4. Características del cluster
 scalabilidad: habilidad de un servidor para procesar
E
eficientemente múltiples peticiones concurrentes
simultáneamente.
 alanceo de carga: distribución de la carga de las
B
peticiones en un grupo de servidores.
 lta disponibilidad: incremento del tiempo que el servicio
A
está disponible para procesar peticiones.

5. Un poco de historia I
LinkedIn es un servicio web que conforma una red social
orientada 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. 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ó en
servicios remotos para proveer perfiles,
ejecutar búsquedas, interactuar con
grupos, contactar compañías, etc. Estas
BD tenían réplicas de sólo-lectura, pero
las escrituras no eran escalables.

7. Un poco de historia III
Muchas funcionalidades web que la gente exige hoy en día
requieren conjuntos masivos de datos, altas cargas de
escritura, o ambos. Los tiempos de respuesta que se
obtenían no eran satisfactorios.

8. Un poco de historia IV
¿Cómo mejorar el tiempo de respuesta?
Se revisaron los productos que otras empresas de Internet
habí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 Amazon's Dynamo
paper, que parecía cumplir las necesidades y era factible de
implementar.

9. Un poco de historia V
Resultados:
Gestionar aplicaciones con cientos de millones de lecturas/
escrituras por día.
Bajaron de 400ms a 10ms y simultáneamente creció la
cantidad de registros almacenados.

10. Código abierto como estrategia
 inkedIn provee un servicio web, no es una casa de
L
software.
 ecidieron que necesitaban una BD clave-valor, ya que no
D
encontraron ninguna que los satisfaciera, la construyeron.
 ero necesitaban ayuda con el soporte, así que lo
P
convirtieron en código abierto. Hoy más de la mitad de
quienes modifican el código no son miembros de LinkedIn.

11. En producción I
LinkedIn
 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,
U
procesamiento de noticias, sistema de correo,
comunicaciones, y más.

12. En producción II
KaChing
 ervicio de contactos para hacer inversiones. Empezó
S
como 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,
U
análisis.

13. En producción III
eHarmony
 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. En producción IV
Gilt 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
U
el procesamiento de ordenes, eventos de ventas con picos
diarios.

15. Innova4j y Voldemort I
Características del proyecto
Uno de nuestros principales clientes dedicado a operaciones de ventas onlines,
nos planteo la necesidad de desarrollar una nueva plataforma online de bajo
coste que le permitiera soportar un promedios de 20 millones de peticiones
diarias con la capacidad de gestionar más de 800 millones de registros activos que
deberían ser consultados durante las peticiones de disponibilidad y donde los
tiempos 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. Innova4j y Voldemort II
Un enfoque pragmático
Conjuntamente con nuestro cliente se decidió dividir el proyecto en 2 grandes
fases que nos permitieran mejorar el "Time to market" de la plataforma.
 La primera fase del proyecto nos permitió garantizar la lógica de negocio y
estructurar una arquitectura flexible y fácil de escalar; pero sin incluir una
solución NoSQL.
Ventaja : Nos dedicamos a consolidar la oportunidad de negocio de nuestro
cliente, liberando rápidamente un producto que le permitiera madurar su
estrategia de negocio.
 n la Segunda fase del proyecto nos enfocamos en cumplir en un 100% con los
E
puntos claves del proyecto.
Ventaja : La lógica de negocio ya estaba implementada con un enfoque TDD, lo
que nos permitió asegurar que el incluir una solución NoSQL fuese algo controlado
y 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 impactar
en la lógica de negocio.

17. Parte II
Visión general de la arquitectura
de Voldemort

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
L
delete.
 onsistent hashing para asignar datos a los nodos.
C
 olerancia a fallos en los nodos se logra por medio de
T
replicación.
 a consistencia distribuida se logra con versiones y la
L
técnica read-repair.

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. Formato de los datos I
El equivalente de una tabla relacional se denomina store.
Cada clave queda asociada a un store. El dato puede ser tan
complejo como se necesite (listas, grafos, etc.).

21. Formato de los datos II
La simplicidad de las consultas hace que resulte muy
sencillo crear un simulador de la BD para pruebas unitarias
con una estructura que es prácticamente una tabla hash.

22. Particionamiento de los datos I
 onsiste en tener copias/replicas de un subconjunto de los
C
datos 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
A
convertiría en el factor preponderante.
 l dividir en nodos, los datos más buscados podrían caber
A
en cada caché.

23. Particionamiento de los datos II
Toda la complejidad del particionamiento es transparente
para el desarrollador, gracias a las diferentes capas
implementadas en su arquitectura

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. Consistencia de los datos I
Difícil de lograr al tener que escribir en múltiples nodos (y
tal vez múltiples data-centers).
Usualmente se usan transacciones distribuidas pero son
lentas y frágiles.
Una alternativa es tolerar la posibilidad de inconsistencias
temporales, y resolverlas cuando se hagan lecturas de datos
(read-repair).

26. Consistencia de los datos II
Con Read-repair cuando se hace una lectura se detectan y
resuelven los conflictos. Esto implica poca coordinación y es
completamente tolerante a fallos, pero puede requerir más
lógica en la aplicación desarrollada.

27. Consistencia de los datos III
CAP: 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. Versionamiento I
Un sistema de versionado simple es igual a un bloqueo
optimista: se almacena un contador o “clock” con cada
dato y solo se puede actualizar si se tiene el contador
correcto.
Ese enfoque no funciona en un sistema distribuido ya que
los nodos aparecen y desaparecen y la replicación puede
tomar tiempo.

29. Versionamiento II
Voldemort usa versionamiento por vector-clock, el cual
mantiene un contador por cada nodo para calcular cuando
dos versiones están en conflicto.

30. Serialización
En el nivel más bajo los datos (claves y valores) son arreglos
de bytes.
Aunque Voldemort viene con serializadores para textos,
objetos Java y flujos de bytes en bruto, implementando la
interfaz Serializer se puede escribir su propio serializador.

31. Parte III
Entrando en detalles

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
E
sub-carpetas.

33. Instalación II
La estructura de archivos resultante es la siguiente:

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. Configuración I
La operación de un servidor Voldemort se configura con 3
archivos: server.properties, cluster.xml y stores.xml.
Los dos últimos deben tener el mismo contenido en todos
los nodos del cluster.

36. Configuración II
server.properties contiene los parámetros de afinamiento
de cada nodo.
Incluye su identificador, tamaño del pool de hilos, así como
el mecanismo de persistencia local (por ejemplo BDB o en
memoria).
Este archivo es diferente en cada nodo.

37. Configuración III
node.id=0
max.threads=200 #Máximo número de hilos en el servidor
socket.enable=true #comunicación por sockets
http.enable=true #comunicación por HTTP
jmx.enable=true #monitorización
routing.timeout.ms=5000 #En espera de respuesta de los nodos.
enable.bdb.engine=true #Activar Berkeley
bdb.cache.size=100MB #Caché de Berkeley

38. Configuración IV
cluster.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. 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. Configuración VI
stores.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.
L
Este archivo es igual en todos los nodos.

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. Propuesta capa intermedia de
acceso a datos

43. APIs del servicio
Voldemort ofrece un API administrativo y
un API cliente.

44. API administrativo
Permite realizar labores administrativas que casi nunca son
necesarias a nivel de aplicación, por ejemplo:
 xtraer registros para backups.
E
 igrar particiones.
M
 btener datos de configuración del cluster.
O
La clase principal es AdminClient.

45. API cliente
Permite la interacción típica de manipulación de datos.
 lientConfig: agrupa parámetros de configuración para la
C
conexión del cliente (ip, puerto, timeout, etc.).
 ocketStoreClientFactory: encapsula el pool de
S
conexiones, hilos, y permite crear instancias de StoreClient.
 toreClient: para manipular cada store de Voldemort (get,
S
put, delete, etc.)
[IDE]

46. Opciones de serialización I
Voldemort permite indicar el tipo de serialización de los
datos almacenados. Los opciones son:
 tring
s
 son
j
 ava-serialization
j
 rotobuff
p
 hrift
t
 dentity (bytes en bruto)
i

47. Opciones de serialización II
Se realizó un laboratorio para comparar las prestaciones del
procesamiento con Json, Jackson y Protobuff (de Google y
de ActiveMq).

48. Opciones de serialización III
Tiempo de procesamiento de datos en memoria

49. Opciones de serialización IV
Tiempo de procesamiento de datos con E/S Voldemort.
Se elimina ActiveMq

50. Opciones de serialización V
Uso del pre-compilador de Protobuff y el patrón Builder.
[IDE]

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 desarrollar
justifican 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 recomendable
pensar en ello desde el inicio.

52. Conclusiones
 as bases de datos NoSQL son una realidad que permiten
L
solventar problemas para los que las bases de datos relaciones no
fueron diseñadas (aun).
 l diseño de una buena arquitectura debe permitir que las bases
E
de datos relacionales y las bases de datos NoSQL coexistan.
 a tecnología NoSQL esta en proceso de madurez y evolución, lo
L
que hace necesario un seguimiento continuo de los nuevos
productos y de las nuevas versiones de los ya existentes.
 a mejor forma de evaluar y estar seguros que la tecnología
L
NoSQL puede encajar en sus proyectos es realizando sus propios
laboratorios. (para creer hay que tocar)

53. Gracias por la atención prestada.
Innova4j
“Dando soluciones hoy y alternativas para el futuro”