04 ago

Voldemort sistema de cache distribuida

En los últimos dias me topé con la necesidad de aprender y montar Voldemort, voy a intentar que este sea el primero de una serie de post donde explicaré todo aquello que vaya descubriendo sobre Voldemort sistema de cache distribuida

Empecemos, como todos sabemos Voldemort es bien conocido por ser el incomprendido de la serie de libros Harry Potter, pues entre hechizo y hechizo planeando su maquiavélica victoria y ayudado por Linkedin monto un sistema de cache distribuida, y la verdad es que no le quedó nada mal!

¿Cómo salio este proyecto?

Básicamente se unieron dos ideas, por un lado Amazon Dynamo Storage system que nos ofrece:

  • Poder trabajar en diferentes datacenters
  • Eventual Consistency
  • Y facil de poner en marcha.

Y por otro lado el bien conocido Memcache

  • Multiples lecturas y escrituras
  • Consisten Hashing para la distribución de datos
  • Clave-Valor
  • Versionado de datos

Si juntamos estos dos conceptos tendremos una idea de lo que es Voldemort.

¿Qué nos ofrece Voldemort?

Eligiendo las 2 opciones del Teorema de CAP

  • Particionamiento de datos a través del cluster
  • Alta disponibilidad

A más

  • Escalavilidad Horizontal
  • “Transparencia” para la aplicación

¿Qué no nos ofrece Voldemort?

Consistencia estricta de los datos, es muy importante el adjetivo estricto, nos ofrece Eventual Consistency, podemos “asegurar” que el dato escrito por el cliente será leído por la siguiente petición.

¿Cómo funciona  Eventual Consistency de Voldemort?

Principalmente necesitaremos dos puntos

  • Saber cual es el ultimo valor
  • Saber que valores no son comparables.

Soluciones

  • Timestamps
  • Vector Clocks
    • Nos ofrecen una manera de tener eventos ordenados en un sistema distribuido, cada vector es una tupla.
    • Como tenemos un sistema con particiones, cada valor tendrá un master del cluster
      • Cuando un dato es escrito en el master, todas las replicas reciben la misma versión
      • Con lo que no tenemos necesidad de bloqueos

¿Cómo trabajamos con los datos?

  • Los datos se organizan dentro de Stores, podríamos pensar que son como tablas en los sistemas tradicionales.
  • Solo disponemos de clave->valor, pero podremos hacer listas, mapas, juntando combinaciones
  • Los datos se reparten en particiones.

Partition voldemort distributed cache system

  • Repartimos los datos en particiones y las particiones entre los nodos.
  • Definimos en replicación de cada dato por store
  • Definimos el numero de lecturas/escrituras necesarias.
    • Esto quiere decir que si tenemos 3 nodos en un cluster, cuando un cliente lee o escribe, podremos definir cuantos OK de escritura debemos tener para que se de por buena la operación
    • O sea que si el numero de R+W > N(Numero de nodos) podremos leer nuestras propias escrituras.

Zonas

Disponemos de Zonas.

Zones architecture voldemort distributed cache system

Podemos crear tantas zonas como queramos, con ellas podemos conseguir tener servidores repartidos en diferentes datacenters, de esta manera el cluster sabrá donde tiene mas o menos latencia.

También las podemos utilizar en el caso de la virtualización, si disponemos de 4 zonas en 2 servidores, nos interesara que las replicaciones no se realicen en los nodos que corren en el mismo servidor, ya que en el caso de fallo del mismo… pues mal asunto.

Detección de errores

  1. Necesitamos que sea muy rápido
  2. Encontrar los servidores que tienen inconsistencia
    1. El servidor A puede hablar con el servidor B, pero C no puede
    2. A puede hablar con C, B puede hablar con A, pero no con C
    3. Actualmente se controla por los timeout, periodicidad de fallos

Mecanismos de Reparación

  • Read Repair
    1. Un cliente recibe valores de múltiples nodos
    2. Notifica al nodo si uno de los valores es antiguo entonces en nodo actualiza su valor
  • Hinted Handoff
    1. Si una escritura falla en cualquier nodo, es marcada como escritura especial
    2. Cada nodo periódicamente intenta deshacerse de todas las escrituras especiales.

Visión general tenemos 3 arquitecturas posibles

Architecture voldemort distributed cache system

  1.  La aplicación no conoce donde se encuentran los datos en el cluster, por cada petición, el cluster deberá ir a buscar el dato al nodo que a través de la partición lo tenga y lo entregara al cliente.
  2. La aplicación sabe que nodo tiene el dato, de tal manera que la petición es directa.
  3. Asociamos una instancia de Voldemort a cada servicio del Backend.

 

One thought on “Voldemort sistema de cache distribuida

  1. Pingback: Alternativa a los comunes Memcached y Redis

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>