Redis, base de datos NoSQL clave-valor

5,941 views
5,696 views

Published on

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.

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,941
On SlideShare
0
From Embeds
0
Number of Embeds
2,055
Actions
Shares
0
Downloads
0
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Redis, base de datos NoSQL clave-valor

    1. 1. Redis, base de datos NoSQL clave-valor@gimenete 10 noviembre 2011 Libre software world conference
    2. 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. 3. NoSQL buzzzzzzz
    4. 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. 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. 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. 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. 8. RDMBS to the limit
    9. 9. SQL ¿rápido? 5.Acceder a los1.Parsear SQL datos2.Planificar 6.Álgebra consulta relacional3.Optimizar 7.Cerrar tablas consulta 8.Devolver4.Abrir tablas resultado
    10. 10. SQL ¿rápido?• Muchos pasos• Difícil de optimizar• Perdemos control• Difícil de escalar
    11. 11. Ejemplo:menéame.net
    12. 12. Join, join, join, join
    13. 13. Join, join, join, joinSELECT 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. 14. Meneame.netCreo que sería muy complicado encontrar unaconsulta más eficiente que la anterior para labase de datos del Menéame. Pero no ha sidouna idea que se me ocurrió de un día paraotro, ni siquiera en semanas. Fue la evolucióny el resultado de 5 años de experienciadirecta, a veces dolorosa, y de aprendermuchas cosas en el proceso.- Ricardo Galli
    15. 15. Back to basics
    16. 16. Clave ➔ valor•DNI ➔ persona•Matrícula ➔ vehículo•Puntero ➔ dato•PK ➔ fila
    17. 17. get / setredis > set foo barOKredis > get foo“bar”
    18. 18. incrredis > incr usuarios(integer) 1redis > get usuarios“1”
    19. 19. Ventajas•Fácil de escalar, como veremos•Rendimiento predecible. Sólo operaciones eficientes: optimizado por defecto•Operaciones atómicas
    20. 20. ¿Cómo escalar?• Escalar lecturas: replicación• Escalar escrituras: particionamiento
    21. 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. 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. 23. Para no hacerlo nosotros...• redis-cluster (en desarrollo)• redis-sharding. Sustituto temporal hasta que redis-cluster esté listo.
    24. 24. Datos estructurados
    25. 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. 26. Pero Redis nos lo hace más fácil• Soporta datos estructurados: • Hashes • Listas • Sets y sets ordenados
    27. 27. Hashesredis > hset usuario:1 nombre Antonio(integer) 1redis > hset usuario:1 apellido Gonzalo(integer) 1redis > hgetall usuario:11. “nombre”2. “Antonio”3. “apellido”4. “Gonzalo”
    28. 28. Hashes redis > hincrby usuario:1 followers (integer) 1• Nos ahorramos leer-calcular-modificar• Siguen siendo operaciones atómicas
    29. 29. Listasredis > lpush mensajes mundo(integer) 1redis > lpush mensajes holaredis > lrange mensajes 0 -11. “hola”2. “mundo”
    30. 30. Sets y sets ordenadosredis > zincrby superheroes 1 batman“1”redis > zincrby superheroes 10 kickass“10”redis > zincrby superheroes 3 spiderman“3”redis > zrevrange superheroes 0 -1 withscores1. “kickass”2. “10”3. “spiderman”4. “3”5. “batman”6. “1”
    31. 31. Modelado de datos• Objetos ➔ hashes• Consultas ➔ listas, sets y sets ordenados • Guardar sólo el id • Son índices manuales
    32. 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. 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. 34. PUB / SUB
    35. 35. PUB / SUBredis > subscribe canal1Reading 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. 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. 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. 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. 39. ¿Preguntas?Thanks for attending! @gimenete http://redis.io

    ×