Redis - A Trial by Fire

1,291 views
1,243 views

Published on

Published in: Technology
1 Comment
3 Likes
Statistics
Notes
  • very nice overview. thanks!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
1,291
On SlideShare
0
From Embeds
0
Number of Embeds
33
Actions
Shares
0
Downloads
31
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

Redis - A Trial by Fire

  1. 1. Fred Oliveira @f on twitter and fred@webreakstuff.com on that older thing A trial by fire. Also, probably my first presentation all set in a monospaced font.
  2. 2. $ mkdir redis && cd redis $ wget http://6rq8.sl.pt $ tar -zxvpf redis-2.0.4.tar.gz $ cd redis-2.0.4 $ make # now give it a minute
  3. 3. $ whatis redis
  4. 4. $ whatis redis redis is an advanced, fast, persistent key- value database
  5. 5. $ whatis redis redis is an advanced, fast, persistent key- value database, developed by Salvatore Sanfilippo (@antirez)
  6. 6. $ whatis redis redis is an advanced, fast, persistent key- value database, developed by Salvatore Sanfilippo (@antirez), who was recently hired by VMWare (to keep working on redis).
  7. 7. $ whereis redis
  8. 8. $ whereis redis places like github, engineyard, forrst, craigslist
  9. 9. $ whereis redis places like github, engineyard, forrst, craigslist, and (I’ll assume) a bunch of places we won’t hear about.
  10. 10. $ whereis redis places like github, engineyard, forrst, craigslist, and (I’ll assume) a bunch of places we won’t hear about. (mostly because regardless of how sexy you think a key-value storage engine is, not a lot of people talk about what they actually use.)
  11. 11. $ ./redis-cli redis> set currentslide “What’s it good for?” OK
  12. 12. “I see Redis definitely more as a flexible tool than as a solution specialized to solve a specific problem: his mixed soul of cache, store, and messaging server shows this very well.” - Salvatore Sanfilippo
  13. 13. Possible use cases: * Caching mechanism (as a substitute for memcached that doesn’t just store blobs) * Job management, queueing systems (github’s resque or Octobot are two good examples) * IPC (easy to setup up a message passing system, locally or over a network) * Locking mechanisms (with commands like setnx and blpop/brpop) * Session/Token data store
  14. 14. At WBS, we built a node+redis-based chat server for a client. Super fast and easily scalable. Also, of trivial implementation. Then we built a realtime node/redis/WS based voting system. Pain points: actually, the only pain point were browsers that didn’t support Websockets.
  15. 15. It is very likely that we end up porting many of our current support processes (queues, background job management, caching) for our products to Redis, mostly for its speed and flexibility.
  16. 16. $ ./redis-cli redis> set currentslide “Crash course!” OK
  17. 17. $ ./redis-cli redis> set currentslide “Redis Data Types” OK
  18. 18. first, a bit about keys * binary-safe strings * stay away from using whitespace * object:property is a good convention * SHA hashes are great keys examples: * user:name * lastmessage * 464A1E96B2D217EBE87449FA8B70E6C7D112560C
  19. 19. redis supports: * strings * lists * sets (+ sorted sets) * hashes
  20. 20. * strings set rickroll “never gonna give you up” OK get rickroll “never gonna give you up”
  21. 21. * strings set count 10 <-- set key OK get count <-- get key “10” setnx count 9999 <-- set if doesn’t exist (integer) 0 incr count <-- increment key (returns integer) (integer) 11 del count <-- deletes the key (integer) 1 expire count 120 <-- key TTL in secs (integer) 1
  22. 22. redis supports: * strings * lists * sets (+ sorted sets) * hashes
  23. 23. redis supports: * strings * lists <-- ordered list of binary-safe strings. implemented on top of the idea for a linked list (not an array) * sets (+ sorted sets) * hashes
  24. 24. redis supports: * strings * lists <-- ordered list of binary-safe strings. implemented on top of the idea for a linked list (not an array) <-- getting an element by index is slow, but adding to edges is super fast (as it should in a db). * sets (+ sorted sets) * hashes
  25. 25. * lists rpush nevergonna “let you down” <-- push right (integer 1) rpush nevergonna “run around and desert you” (integer 2) rpush nevergonna “make you cry” (integer 3) rpush nevergonna “say goodbye” (integer 4) rpush nevergonna “tell a lie and hurt you” (integer 5) lpush nevergonna “give you up” <-- push left (integer 6)
  26. 26. * lists (indexes) [“a”, “b”, “c”, “d”, “e”]
  27. 27. * lists (indexes) [“a”, “b”, “c”, “d”, “e”] 0 1 2 3 4
  28. 28. * lists (indexes) [“a”, “b”, “c”, “d”, “e”] 0 1 2 3 4 -5 -4 -3 -2 -1
  29. 29. * lists rpush nevergonna “let you down” <-- push right (integer 1) rpush nevergonna “run around and desert you” (integer 2) rpush nevergonna “make you cry” (integer 3) rpush nevergonna “say goodbye” (integer 4) rpush nevergonna “tell a lie and hurt you” (integer 5) lpush nevergonna “give you up” <-- push left (integer 6)
  30. 30. * lists lrange 0 2 <-- 3 first elements 1. “give you up” 2. “let you down” 3. “run around and desert you” lrange 0 -1 <-- first to last 1. “give you up” 2. “let you down” 3. “run around and desert you” 4. “make you cry” 5. “say goodbye” 6. “tell a lie and hurt you”
  31. 31. * lists llen nevergonna <-- list length (integer 6) lpop nevergonna <-- pop from left “give you up” lpop nevergonna “let you down” rpop nevergonna <-- pop from right “tell a lie and hurt you”
  32. 32. * lists lindex nevergonna 0 <-- element at index “give you up” ltrim nevergonna 0 2 <-- trims list to [0,1,2] OK other commands: lrem <-- removes x instances of a value blpop/brpop <-- blocking pop operation. if list is empty, waits for another client to lpush or rpush. sort <-- sorts a list given certain criteria (sorts numeric lists in ASC by default) rpoplpush <-- removes from right, adds to left
  33. 33. redis supports: * strings * lists * sets (+ sorted sets) * hashes
  34. 34. redis supports: * strings * lists * sets (+ sorted sets) <-- unordered collection of binary-safe strings. no duplicate elements in sets. * hashes
  35. 35. redis supports: * strings * lists * sets (+ sorted sets) <-- unordered collection of binary-safe strings. no duplicate elements in sets. <-- you can do interesting things like intersections, unions and verifying if a key is a member of a set. * hashes
  36. 36. * sets sadd beatles “george” <-- add george sadd beatles “paul” <-- add paul sadd beatles “john” <-- add john sadd beatles “ringo” <-- add ringo smembers beatles <-- list set members 1. “ringo” 2. “john” 3. “george” 4. “paul”
  37. 37. * sets sismember beatles “john” <-- check presence (integer) 1 sismember beatles “yoko” (integer) 0
  38. 38. * sets implementing things like tags becomes trivial: sadd taggedwith:design “@jasonsantamaria” sadd taggedwith:design “@zeldman” sadd taggedwith:design “@f” sadd taggedwith:dev “@ezra” sadd taggedwith:dev “@dhh” sadd taggedwith:dev “@f” sinter taggedwith:design taggedwith:dev ^ intersect both sets 1. "@f"
  39. 39. * (sorted) sets sorted sets are much like regular sets, except each one member has an associated score. Redis uses the score to sort between the elements in the set. zadd pleague 28 “FC Porto” zadd pleague 18 “V. Guimarães” zadd pleague 18 “Benfica” zadd pleague 16 “Nacional” zadd pleague 15 “Académica”
  40. 40. * (sorted) sets zrank pleague “FC Porto” <-- rank, low to high (integer) 4 zrevrank pleague "FC Porto" <-- high to low (integer) 0 zrange pleague 0 2 <-- returns 1st to 3rd 1. "Academica" 2. "Nacional" 3. "Benfica" zrevrange pleague 0 2 <-- high to low 1. "FC Porto" 2. (...)
  41. 41. * (sorted) sets zcard pleague <-- return cardinality zscore pleague “Benfica” <-- return the score zcount pleague 16 18 <-- returns the number of elements with score between 16 and 18 zremrangebyrank <-- remove by rank range zremrangebyscore <-- remove by rank score
  42. 42. redis supports: * strings * lists * sets (+ sorted sets) * hashes
  43. 43. * hashes useful in the case of web applications, where storing objects is important. Implementation is on top of a hash table. Small hashes, however (with a limited number of fields and size for values) are implemented differently in order to be more memory efficient (to compensate for the overhead of a traditional hash-table implementation).
  44. 44. * hashes hset u:fred name “fred” hset u:fred age “27” hset u:fred email “fred@webreakstuff.com” hkeys u:fred <-- return all the keys hvals u:fred <-- return all the values hgetall u:fred <-- key(1), value(1)..key(n).. hincr u:fred age 1 <-- age becomes age++
  45. 45. $ ./redis-cli redis> set currentslide “Publish/Subscribe” OK
  46. 46. * pub/sub Redis natively supports the publish/subscribe messaging pattern. In the pattern, publishers don’t know about subscribers. Subscribers express interest in channels and receive messages in those channels, with no knowledge of publishers.
  47. 47. * pub/sub subscribe messages Reading messages... (press Ctrl-c to quit) elsewhere: publish messages “hello world” (integer) 1 back in the first client: 1. “message” 2. “messages” 3. “hello world”
  48. 48. * pub/sub possible use cases: * alert systems * chat functionality * (insert awesomeness)
  49. 49. $ ./redis-cli redis> set currentslide “A few considerations” OK
  50. 50. * While the primitives in Redis are pretty fast, how fast your system actually performs boils down to how you design the way you store data. * Remember there’s no guarantee that data has been written to disk when a command returns. * Always design based on how you query. * Also, you’ll be building your indexes manually. This means your data will be replicated in a few places. What they taught in your DB classes may not apply. De- normalization is common, natural and necessary here.
  51. 51. Most previous considerations apply to NoSQL in general. Relational data makes sense in relational databases, whereas non-relational data is perfect for NoSQL. Don’t treat NoSQL in general or Redis in particular as a silver bullet. (although Redis is pretty damn shiny)
  52. 52. $ ./redis-cli redis> set currentslide “Finally,” OK
  53. 53. This talk didn’t focus on: * Scaling redis (trivial with slaveof) * How fast it is (pretty speedy) * Comparisons between Redis and key value stores (because that would be flamebait)
  54. 54. Also, it didn’t talk about * Clustering Redis (Salvatore himself will talk about that tomorrow at 3PM on Stage C. He’s a smart dude, you should go listen to what he has to say)
  55. 55. ...and it didn’t mention, * Your brain! (I’m going to be speaking about that sexy beast between your ears tomorrow at 2PM on Stage C. I like to pretend I’m a smart dude, you should probably go listen to what I have to say)
  56. 56. redis> exit >> fred@oreo [~/Projects/redis-2.0.4] $ _ # thank you! # email me at fred@webreakstuff.com # or follow me on twitter - @f

×