3. Key Value
page:index <html><head>[...]
user:123:session xDrSdEwd4dSlZkEkj+
user:123:avatar 77u/PD94bWwgdm+
Everything is a «blob»
Commands, primarily, can GET and SET the values
3
4. Key Value Type
page:index <html><head>[...] String
events:timeline { «Joe logged», «File X Uploaded», …} List
logged:today { 1, 2, 3, 4, 5 } Set
time => 10927353
user:123:profile Hash
username => bmatte
joe ~ 1.3483
game:leaderboard smith ~ 293.45 Sorted Set
fred ~ 83.22
Different «data type/structure»
Rich set of specialized commands 4
5. Everything is stored in memory
Screamingly fast performance
Persistent via snapshot or append-only log file
Replication (only Master/Slave)
Extensible via embedded scripting engine (Lua)
Rich set of client libraries
High availability (In progress)
◦ Cluster (Fault tolerance, Multi-Node consistence)
◦ Sentinel (Monitoring, Notification, Automatic failover)
5
6. Created by Salvatore
Sanfilippo (@antirez)
First «public release»
in March 2009.
Since 2010 sponsored
by VMware.
Initially written to improve performance of Web
Analytics product LLOOGG out of his startup
6
7. Written in ANSI C
No external dependencies
Single thread (asynchronous evented I/O)
Works on all POSIX-like system
Exist unofficial build for Windows
Open-source BSD licensed
Community (list, IRC & wiki)
7
8. 1. A DSL for Abstract Data Types.
2. Memory storage is #1.
3. Fundamental data structures for a
fundamental API.
4. Code is like a poem.
5. We're against complexity.
6. Two levels of API.
7. We optimize for joy.
8
21. Sharing state across processes
◦ Distribute lock, Incremental ID, Time series,
User session.
Web Analytics
◦ User visit (day, week, month), Feature Tracking.
Caching
◦ String values can hold arbitrary data.
Rate limiting
◦ Limit number of API calls/minute.
21
30. Events Store or Notification
◦ Logs, Social Network Timelines, Notifications.
Fixed Data
◦ Last N activity.
Message Passing
◦ Durable MQ, Job Queue.
Circular list
30
36. Web Analytics
◦ Unique Page View, IP addresses visiting.
Relations
◦ Friends, Followers, Tags.
Caching Result
◦ Store result of expensive intersection of data.
36
42. Web Analytics
◦ Online users, Most visited pages.
Leaderbord
◦ Show top N.
Order by data
◦ Maintain a set of ordered data like user by age.
42
50. Dump data to disk after certain
conditions are met
50
51. Pro:
◦ RDB is a very compact single-file.
◦ RDB files are perfect for backups.
◦ RDB is very good for disaster recovery.
◦ RDB allows faster restarts with big datasets.
◦ RDB maximizes performances (backgr. I/O via fork(2)).
Contro:
◦ RDB is NOT good if you need to minimize the chance of
data loss in case Redis stops working (for example after
a power outage).
◦ Fork can be time consuming if the dataset is very big.
51
54. Pro:
◦ AOF is much more durable.
◦ AOF is an append only log, no seeks, nor corruption
problems (for example after a power outage).
◦ AOF contains a log of all the operations one after the
other in an easy to understand and parse format.
Contro:
◦ AOF files are usually bigger than the equivalent RDB.
◦ AOF can be slower then RDB depending on the exact
fsync policy.
54
55. Use both persistence methods if you want a degree of
data safety comparable to what any RDBMS can provide
you.
If you care a lot about your data, but still can live with a
few minutes of data lose in case of disasters, you can
simply use RDB alone.
There are many users using AOF alone, but we
discourage it since to have an RDB snapshot from time to
time is a great idea for doing database backups, for
faster restarts.
55
77. Scalability
◦ Multiple slaves for read-only queries.
Redundancy
◦ Data replication.
Slave of Slave
◦ Graph-like structure for more scalability e
redundancy.
77
85. «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
85