Redis, Explained
What shape does Redis have in your mind?
Over the past five years, Redis has changed and morphed and grown considerably. Features have been added, removed, expanded, and rewritten to increase performance while removing unnecessary complexity. As a casual user whose full time job isn’t Redis-Redis-Redis, it can be difficult keeping up with all the new changes unless you re-read all the documentation once a month looking for updated sections.
This is a series of short posts designed to get you up to speed with modern Redis (or refresh what you kinda already know). We’ll focus on examples, use cases, and deployment strategies by introducing general Redis concepts then expanding on those ideas. We’ll get into individual Redis commands and detailed use cases about four posts from now.
What is Redis?
Redis is a data structure server. Redis stores your data in one of five native Redis data types so you can perform fast, reliable operations on your data across a network.
Redis stores and manipulates all data in memory, but you can configure Redis to also store your dataset to disk, replicate your data to a secondary nodes supporting live failover, and (soon) load balance your data across an entire cluster.
If Redis had to be described in one word, it would be “configurable.” Every feature of Redis has user configurable tuning parameters. If you need a reliable data store, you can adjust durability guarantees for storing data to disk. If you need a highly available replicated data store, you can adjust failover criteria and availability modes. If you need a fast cache, you can pick how keys get evicted when memory limits are reached.
All modes of Redis (expiring cache, reliable data persisted to disk, replicated data store) can be combined too. You can configure a writes-to-disk database with fast in-memory operations distributed across hot backup nodes and (soon) an entire load balanced cluster.
Is Redis a memory-only cache? Yup. Is Redis a reliable database? Indeed. Is Redis a replicated data store? Yeah, it’s that too.
Since Redis gives you a framework for writing and reading complex data types, you can easily build complex systems like these (and many more) on top of Redis:
- User defined indexing schemes
- Directed and undirected graph stores for following or friending systems
- Rate limiting governors to throttle user access to sites/APIs/content
- Message queues with real time new element notification
- Real time publish/subscribe notification systems
- Real time analytics backends
- Bloom filter servers
- Task queues and job systems
- High score leaderboards
- User ranking systems
- Hierarchical/tree structured storage systems
- Individual personalized news or data feeds for your users
The simplicity, reliability, and high performance of native Redis data types means it’s easier to build what you need using Redis. You can build abstractions on top of Redis to support your specific use cases (instead of pulling in large external dependencies never working quite like you need or expect). Using Redis, you can build systems to serve your purposes and react to what you need instead of you constantly reacting to the needs of external dependencies outside your control.