Introducción a esta base de datos NoSQL que permite desarrollar aplicaciones altamente escalables gracias a su velocidad (100k operaciones por segundo en un ordenador corriente) y su capacidad de trabajar en varios nodos.

1. Redis, base de datos
NoSQL clave-valor
@gimenete
10 noviembre 2011
Libre software world conference

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

3. NoSQL buzzzzzzz

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. Ejemplos de apps que
necesitan escalar
• 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
• Se consigue
• Con software más óptimo. ¡Ahorro
de costes! Ej: http://bit.ly/ibdi20
• Con hardware verticalmente u
horizontalmente

8. RDMBS to the limit

9. SQL ¿rápido?
5.Acceder a los
1.Parsear SQL
datos
2.Planificar
6.Álgebra
consulta
relacional
3.Optimizar
7.Cerrar tablas
consulta
8.Devolver
4.Abrir tablas
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. Meneame.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

15. Back to basics

16. Clave ➔ valor
•DNI ➔ persona
•Matrícula ➔ vehículo
•Puntero ➔ dato
•PK ➔ fila

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
“autoámtico”:
• 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

23. Para no hacerlo
nosotros...
• redis-cluster (en desarrollo)
• redis-sharding. Sustituto temporal
hasta que redis-cluster esté listo.

24. Datos estructurados

25. ¿get/set/incr suficiente?
• Objetos:
• claves “usuario:1”, “usuario:2”,...
• valores: serialización, json, xml,...
• ¿Consultas?
• Listas 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
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
• Objetos ➔ hashes
• Consultas ➔ listas, sets y sets
ordenados
• Guardar sólo el id
• Son índices manuales

32. Consultas
• Consultamos el índice y hacemos JOIN
en la aplicación
• Consultas complejas con UNIONES e
INTERSECCIONES
• Paginaciones con LIMIT y OFFSET
• Borrado en cascada? Lecturas
destructivas

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

34. PUB / SUB

35. 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
---------------
1. “message”
2. “canal1”
3. “Hola”

36. Próximamente en Redis
• Scripting con LUA en la 2.6. Algo así
como procedimientos almacenados
• Redis-cluster en la 3.0
• Y más: http://antirez.com/post/short-
term-redis-plans.html

37. 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.
• Como base de datos principal.

38. ¿Algún inconveniente?
• Funciona con los datos en memoria
• ¡Pero es persistente!
• Snapshots o Append-only-file
• Y soporta replicación
• VM y diskstore fueron “deprecated”

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