Proyecto Voldemort

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

 Instalación, configuración y API con ejemplos de código.

 Recomendaciones a la hora de iniciar un proyecto con Voldemort.

 Conclusiones

Parte I – Acerca de Voldemort  Voldemort es un sistema distribuido de bases de datos clave-valor.

 Aplica el concepto clásico de cluster. Sus nodos son independientes (no maestro/esclavo). No hay un punto central de coordinación.

 Está siendo utilizado con éxito en LinkedIn (sus creadores) 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.

 100% Java y open source.

Características del cluster

 Escalabilidad: habilidad de un servidor para procesar eficientemente múltiples peticiones concurrentes simultáneamente.

 Balanceo de carga: distribución de la carga de las peticiones en un grupo de servidores.

 Alta disponibilidad: incremento del tiempo que el servicio está disponible para procesar peticiones.

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:

 Encontrar trabajo, personas, oportunidades.

 Conocer novedades de las compañías.

 Etc.

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.

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.

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.

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.

Código abierto como estrategia

 LinkedIn provee un servicio web, no es una casa de software.

 Decidieron que necesitaban una BD clave-valor, ya que no encontraron ninguna que los satisfaciera, la construyeron.

 Pero necesitaban ayuda con el soporte, así que lo convirtieron en código abierto. Hoy más de la mitad de quienes modifican el código no son miembros de LinkedIn.

En producción I

LinkedIn

 SNA Team (Search, Network, and Analytics)

 Clusters con 12 nodos (y creciendo)

 8 cores y muy bajo consumo de C.P.U.

 Usos: personas que conoces, quién ha visto mi perfil, procesamiento de noticias, s istema de correo, comunicaciones, y más.

En producción II KaChing

 Servicio de contactos para hacer inversiones. Empezó como una aplicación de Facebook.

 Usa Voldemort desde Febrero de 2010.

 Desafíos: alto tráfico, grandes conjuntos de datos.

 Cluster de 6 nodos.

 Usos: datos del mercado de acciones, historia de usuarios, análisis.

En producción III

eHarmony

 Busca de pareja en Internet.

 Usa Voldemort desde Abril de 2009.

 Tres clusters de producción: de tres, siete y diez nodos.

En producción IV

Gilt Groupe

 Sitio de ventas premium.

 Usa Voldemort desde Agosto de 2009.

 Tres clusters de cuatro nodos cada uno.

 Usos: “Shopping Cart”, almacenamientos separados para el procesamiento de ordenes, eventos de ventas con picos diarios.

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  A menor tiempo de respuesta, mayor posibilidad de venta.

 A menor coste de infraestructura, precios mas competitivos.

 Gestión de un número elevado de peticiones concurrentes.  Manejo de grandes volúmenes de información.

Innova4j y Voldemort II

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.

 En la Segunda fase del proyecto nos enfocamos en cumplir en un 100% con los 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.

Un enfoque pragmático

Parte II Visión general de la arquitectura

de Voldemort

Decisiones de arquitectura

 Se almacenan datos “solo” en formato clave-valor.

 No se soportan consultas complejas o joins.

 Las únicas operaciones con los datos son put, get, getAll y delete.

 Consistent hashing para asignar datos a los nodos.

 Tolerancia a fallos en los nodos se logra por medio de replicación.

 La consistencia distribuida se logra con versiones y la técnica read-repair.

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.

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

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.

Particionamiento de los datos I

 Consiste en tener copias/replicas de un subconjunto de los datos en diversos nodos.

 Necesario para que ningún nodo tenga todos los datos.

 Aún si todos caben en un nodo, el acceso a disco se convertiría en el factor preponderante.

 Al dividir en nodos, los datos más buscados podrían caber en cada caché.

Particionamiento de los datos II

Toda la complejidad del particionamiento es transparente para el desarrollador, gracias a las diferentes capas implementadas en su arquitectura

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.

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

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.

Consistencia de los datos III

CAP: Consistency, Availability, Partition Tolerance (red).

 Solo se garantizan 2 de 3 en todo momento.

 Voldemort escoge consistencia eventual (AP) por que:

 Permite multi-datacenters.

 Buen rendimiento tanto para lecturas como escrituras.

 Por configuración se puede mejorar la C.

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.

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.

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.

Parte III Entrando en detalles

Instalación I

 Consiste en descomprimir un zip.

 Incluye scripts para Linux fácilmente migrables a Windows.

 Lo hemos instalado en Linux, Windows y Mac.

 Viene con ejemplos de configuración.

 En la distribución por defecto los clusters se configuran en sub-carpetas.

Instalación II

La estructura de archivos resultante es la siguiente:

Instalación III Ejemplo de interacción básica por línea de comandos:

$voldemort-server.bat ..\config\util_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

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.

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.

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

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.

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>

Configuración VI

stores.xml contiene información de los almacenamientos (stores). Un store es similar a una tabla.

Incluye:

 La cantidad de nodos accedidos en lecturas y escrituras.

 La forma de serializar las claves y valores.

Este archivo es igual en todos los nodos.

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

Propuesta capa intermedia de acceso a datos

APIs del servicio

Voldemort ofrece un API administrativo y

un API cliente.

API administrativo

Permite realizar labores administrativas que casi nunca son necesarias a nivel de aplicación, por ejemplo:

 Extraer registros para backups.

 Migrar particiones.

 Obtener datos de configuración del cluster.

La clase principal es AdminClient.

API cliente

Permite la interacción típica de manipulación de datos.

 ClientConfig: agrupa parámetros de configuración para la conexión del cliente (ip, puerto, timeout, etc.).

 SocketStoreClientFactory: encapsula el pool de conexiones, hilos, y permite crear instancias de StoreClient.

 StoreClient: para manipular cada store de Voldemort (get, put, delete, etc.)

[IDE]

Opciones de serialización I

Voldemort permite indicar el tipo de serialización de los datos almacenados. Los opciones son:

 string

 json

 java-serialization

 protobuff

 thrift

 identity (bytes en bruto)

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

Opciones de serialización III

Tiempo de procesamiento de datos en memoria

Opciones de serialización IV Tiempo de procesamiento de datos con E/S Voldemort.

Se elimina ActiveMq

Opciones de serialización V

Uso del pre-compilador de Protobuff y el patrón Builder.

[IDE]

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.

Conclusiones

 Las bases de datos NoSQL son una realidad que permiten solventar problemas para los que las bases de datos relaciones no fueron diseñadas (aun).

 El diseño de una buena arquitectura debe permitir que las bases de datos relacionales y las bases de datos NoSQL coexistan.

 La tecnología NoSQL esta en proceso de madurez y evolución, lo que hace necesario un seguimiento continuo de los nuevos productos y de las nuevas versiones de los ya existentes.

 La mejor forma de evaluar y estar seguros que la tecnología NoSQL puede encajar en sus proyectos es realizando sus propios laboratorios. (para creer hay que tocar)

Gracias por la atención prestada.

Innova4j

“Dando soluciones hoy y alternativas para el futuro”