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.
Agenda
What’s all this with Redis?
Advanced structures (real usage scenarios)
Features, many features
How and where to use it

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.
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.
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.
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.
DEMO 1
1. Data model for a voting based
website
2. Query to get all developers
from Iasi

8.
Single threaded server
Don’t block it with long
operations (#1 threat in
production is KEYS
command)

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.
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.
DEMO 2
1. Sliding expiration for a simple
key
2. Increment all scores of a set
3. Distributed locking

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.
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.
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.
DEMO 3
1. Restarting the server, data is
not lost
2. Save on demand
3. Lets see also AOF

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.
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.
Troubleshooting
Main problems come from long running commands:
◦FLUSHDB,
◦FLUSHALL,
◦KEYS
◦LUA Scripts
◦They can even bring your replica set DOWN

19.
DEMO 4
1. Slowlog
2. Big keys
3. Monitor

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.
?questions?
1. Liviu Costea
2. email.lcostea@gmail.com
3. @clm160
4. SO user:4138058