Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

dba_lounge_Iasi: Everybody likes redis

We are going to explore how Redis can be added to your existing stack, solving performance and scalability problems.

  • Be the first to comment

  • Be the first to like this

dba_lounge_Iasi: Everybody likes redis

  1. 1. Everybody likes REDIS Liviu Costea @clm160 Software Developer Biz Pro Technologies 23.09.2015 Let me help you add Redis to your stack today!
  2. 2. Agenda What’s all this with Redis? Advanced structures (real usage scenarios) Features, many features How and where to use it
  3. 3. Bit of history There was a developer (@antirez) and he had a problem: real time web analytics NOT a plain Key-value NoSql database but a in memory data structures server VMWare, Pivotal, RedisLabs and many other companies helped in some way Very popular: Twitter, Airbnb, Flickr, StackOverflow, GitHub, BitBucket, Biz Pro Technologies and many others
  4. 4. How people start First there was a server, then you think of scaling Next you have 2 servers, but how do you share: ◦Session ◦Cached & static items ◦Sometimes you need to synchronize them Then you find some solutions: ◦Database (probably the worst) ◦Memcached (getting better) ◦Redis (a NoSQL, newest addition)
  5. 5. Data structures Main data types: ◦Strings (everything is a string) ◦Lists (double linked lists) ◦Sets (unique lists) ◦Hashes (like an object) ◦Sorted sets (by a value at creation) Efficiently modeling of data is your main concern!
  6. 6. Queries You don’t have queries, you don’t have indexes You do have ◦KEYS = returns all your keys (EVIL I tell you!) ◦SCAN with MATCH, COUNT = server side cursor But these are not for real queries, instead you should keep your data updated by yourself: queries, indexes
  7. 7. DEMO 1 1. Data model for a voting based website 2. Query to get all developers from Iasi
  8. 8. Single threaded server Don’t block it with long operations (#1 threat in production is KEYS command)
  9. 9. Single threaded server There is no locking necessary Extremely fast, everything is in RAM Limited support for transactions with optimistic locking (might be removed in the future versions) Pipelining support (check your client)
  10. 10. Lua scripting Similar to stored procedures: ◦They are atomic by nature, but not transactions ◦Rule of thumb: don’t write heavy scripts because you block the server ◦Limitation: use only deterministic functions (because of replication model) ◦KEYS and ARGV global variables
  11. 11. DEMO 2 1. Sliding expiration for a simple key 2. Increment all scores of a set 3. Distributed locking
  12. 12. Use as a cache system It can be configured as a LRU cache with max memory and different eviction policies Expiration (TTL) of keys only (no subkeys)
  13. 13. Use as a session storage If you go with the session out of proc here are some existing session providers: ◦PHPRedis ◦Spring Session ◦Ruby ◦Node.js ◦ASP.NET (official and open source - wow)
  14. 14. Use as a real database Backup – Snapshot (RDB file) - default ◦BGSave – fork ◦On Stop / On Start Persistence - AOF ◦Every write appends Use both, on long term they will be unified Master / Slave replication and WAIT command
  15. 15. DEMO 3 1. Restarting the server, data is not lost 2. Save on demand 3. Lets see also AOF
  16. 16. More features Big ecosystem, lots of client libraries out there: redis. io/clients On AWS and Azure – first class citizen (with high availability) Windows port by MS Open Tech (good for dev) GUIs: Redsmin (web), Redis-commander (web, your own installation, node.js), FastoRedis (desktop)
  17. 17. Redis Cluster Available from 3.0 – waiting for adoption – clients and applications Implemented with query routing Client must be (smart) able to memorize things about the cluster: gets redirected to the right node Ping – Pong between clients (heartbeat) Keyspace (dividing data into nodes) Generating KEYS in a LUA script isn’t cluster-safe
  18. 18. Troubleshooting Main problems come from long running commands: ◦FLUSHDB, ◦FLUSHALL, ◦KEYS ◦LUA Scripts ◦They can even bring your replica set DOWN
  19. 19. DEMO 4 1. Slowlog 2. Big keys 3. Monitor
  20. 20. Future features For the next version ◦Geo hashing API (already documented) ◦A few new commands: like a memory introspection command Other things in the queue: ◦Real transactions with Lua, support for rollback
  21. 21. ?questions? 1. Liviu Costea 2. 3. @clm160 4. SO user:4138058