1. Aplicaciones web
ultraescalables con
Redis
Alberto Gimeno
@gimenete
18 Febrero 2011

2. ¿Qué es Redis?
• Base de datos clave-valor
• Soporta tipos de datos ¡y transacciones!
• Muuuuuuuuuy rápida. ~100k op/s
• Esponsorizada por VMWare

3. NoSQL buzzzzzzzz

4. ¿RDBMS suficiente?
• 640K - of memory - ought to be enough for
anybody - Bill Gates?
• Who the hell knew how much address space
we needed? - Vint Cerf

5. ¿Hasta cuánto
necesitaré escalar?
• ¿Cuántos usuarios tienes? ¿Cuál es tu máximo de
usuarios? Tu país, todos los smartphones del mundo,
el mundo entero?
• ¿Cuántas peticiones/s hace cada usuario de media?
• Elasticidad: ¿tienes picos?

6. ¿Quién necesita escalar
mucho? Ejemplos:
• Juegos. Especialmente multijugador.
• Aplicaciones sociales. Ej: Facebook apps
• Web services. Ej: pasarelas de pago.
• ¿Tú? Depende, claro.

7. Escalar es...
• Escalar es poder atender más peticiones / s
• Podemos escalar:
• Con software más óptimo. ¡Ahorro de costes!
Ejemplo: http://bit.ly/ibdi20
• Con hardware:
• Verticalmente: mejor hardware en 1 máquina
• Horizontalmente: más máquinas

8. RDMBS to the limit

9. SQL ¿rápido?
1. Parsear SQL 6. Acceder a los datos
2. Planificar consulta 7. Álgebra relacional
3. Optimizar consulta 8. Cerrar tablas
4. Abrir tablas 9. Devolver resultado

10. SQL ¿rápido?
• Muchos pasos
• Difícil de optimizar
• Perdemos control
• Difícil de escalar

11. Ejemplo: menéame.net

12. Join, join, join, join

13. Join, join, join, join
SELECT link_id AS id, link_author AS author, link_blog AS blog, /* muc
FROM links
INNER JOIN users ON (user_id = link_author)
LEFT JOIN (categories AS cat, categories AS meta) ON (cat.category_i
LEFT JOIN votes ON (link_date > @enabled_votes AND vote_type='links'
LEFT JOIN favorites ON (@user_id > 0 AND favorite_user_id = @user_i
LEFT JOIN link_clicks AS clicks ON (clicks.id = links.link_id)
INNER JOIN (SELECT link_id FROM links $from WHERE $where $order_by L
Fuente: http://bit.ly/fLf0MK

14. Menéame.net
Creo que sería muy complicado encontrar una consulta más
eficiente que la anterior para la base de datos del
Menéame. Pero no ha sido una idea que se me ocurrió de
un día para otro, ni siquiera en semanas. Fue la evolución y
el resultado de 5 años de experiencia directa, a veces
dolorosa, y de aprender muchas cosas en el proceso.
- Ricardo Galli
Fuente: http://bit.ly/fLf0MK

15. Back to basics

16. Clave => valor
• DNI => persona
• Matrícula => coche • PK => fila
• Puntero => dato

17. Get / Set
redis> set foo bar
OK
redis> get foo
"bar"

18. Incr
redis> incr usuarios
(integer) 1
redis> get usuarios
"1"

19. Ventajas
• Fácil de escalar, como veremos.
• Rendimiento predecible. Sólo operaciones
eficientes: optimizado por defecto
• Operaciones atómicas

20. ¿Cómo escalar?
• Escalar lecturas: replicación
• Escalar escrituras: particionamiento

21. Particionamiento
• Los datos están en varios nodos
• A partir de la clave sabemos el nodo donde
está el dato.
• Particionamiento manual. Ej: claves con fechas
• Ejemplo particionamiento “automático”:
• nodo = hash(clave) % nodos

22. Particionamiento
• nodo = hash(clave) % nodos
• Problema: resharding. Al añadir o quitar
nodos. ¡Hay que mover casi todos los datos!
• Solución: consistent hashing => método para
que los datos a mover sean los menos
posibles.

23. Para no hacerlo
nosotros...
• redis-cluster
• En desarrollo.Versión experimental en Marzo
• RC prevista para Junio
• http://bit.ly/c4XyyZ
• redis-sharding
• Sustituto temporal hasta que redis-cluster esté listo
• https://github.com/kni/redis-sharding

24. Datos estructurados

25. ¿get/set/incr suficiente?
• Objetos:
• claves “usuario:1”, “usuario:2”,...
• valores: serialización, json, xml,...
• ¿Consultas?
• Índices manuales: listas, sets que guardan ids
• También serializados

26. Pero Redis nos lo hace
más fácil
• Soporta datos estructurados:
• Hashes
• Listas
• Sets y sets ordenados

27. Hashes
redis> hset usuario:1 nombre Antonio
(integer) 1
redis> hset usuario:1 apellido Gonzalo
(integer) 1
redis> hgetall usuario:1
1. "nombre"
2. "Antonio"
3. "apellido"
4. "Gonzalo"

28. Hashes
redis> hincrby usuario:1 followers
(integer) 1
•Nos ahorramos leer-calcular-modificar
•Siguen siendo operaciones atómicas

29. Listas
redis> lpush mensajes mundo
(integer) 1
redis> lpush mensajes hola
(integer) 2
redis> lrange mensajes 0 -1
1. "hola"
2. "mundo"

30. Sets y sets ordenados
redis> zincrby superheroes 1 batman
"1"
redis> zincrby superheroes 10 kickass
"10"
redis> zincrby superheroes 3 spiderman
"3"
redis> zrevrange superheroes 0 -1 withscores
1. "kickass"
2. "10"
3. "spiderman"
4. "3"
5. "batman"
6. "1"

31. Modelado de datos

32. Modelado de datos
• Objetos → hashes
• Consultas → Listas, sets y sets ordenados
• Guardar sólo el id
• Son índices manuales

33. APIs bajo nivel
• Muchas en muchos lenguajes.
• En Java por ejemplo: Jedis
• Spring Data

34. APIs de alto nivel
• GORM Redis
• ¿Hacemos la nuestra?

35. Do it yourself
public static IntegerValue users = new IntegerValue("users");
public static ObjectValue<User> user
= new ObjectValue<User>(User.class, "user");
Integer n = users.incr();
User u = new User("Pepe");
user.withKey(n.toString()).set(u);

36. Do it yourself
• Clases que abstraen los valores soportados
en Redis:
• IntegerValue
• ObjectValue con generics
• ListValue
• SetValue
• SortedSetValue.

37. Do it yourself
• withKey(String...params)
• Construye una clave con un prefijo y los
params separados por “:”.
• Devuelve un objeto con métodos
apropiados para el tipo de dato

38. Transacciones

39. Transacciones
• MULTI. Inicia transación.
• EXEC. Ejecuta transacción.
• DISCARD. Cancela transación.
• WATCH / UNWATCH. Bloquea /
desbloquea valores de ser modificados
durante la transacción

40. PUB/SUB

41. PUB/SUB
redis> SUBSCRIBE canal1
Reading messages... (press Ctrl-c to quit)
1. "subscribe"
2. "canal1"
3. (integer) 1
redis> PUBLISH canal1 Hola
(integer) 1
DEMO
1. "message"
2. "canal1"
3. "Hola"

42. Configurar Redis

43. Todo en memoria
• Comportamiento por defecto
• La BD debe caber en RAM
• Persistencia:
• Snapshotting. Con fork
• Append-only file. Log binario

44. Virtual Memory (VM)
• Guarda las claves en memoria
• Los valores se guardan en disco a partir de
cierto máximo de memoria usado.
• Desaconsejado

45. Diskstore
• Permite guardar claves y valores en disco
• Permite tener replicados en memoria los
datos más usados
• A partir de la versión 2.2

46. Cuándo usar Redis

47. Cuándo usar Redis
• Como caché. Un memcache con datos estructurados
y persistente. También soporta expiración.
• Como base de datos auxiliar cuando se necesite
mucha velocidad. Que sea persistente tiene
• una ventaja importante: si
Como base de datos principal. se cae la caché, al volver a
arrancarla no está vacía.
Así que no habrá un aluvión
de peticiones a la fuente de
datos principal.

48. ¿Preguntas?
Thanks for attending!
@gimenete
http://redis.io