Redis is a hammer in search of a nail.
March 21, 2019

Redis is a hammer in search of a nail.

Anonymous | TrustRadius Reviewer
Score 10 out of 10
Vetted Review
Verified User

Overall Satisfaction with Redis

In our organization, Redis is being used as a temporary cache for ephemeral data. This solves the problem of needing to store cached data in a centralized place that is accessible by multiple devices and can be retrieved quickly. In general, nothing is stored in Redis that can't be reproduced from another resource on demand. For example, if we have a process that creates summaries of data from multiple data sources and is costly or very time consuming, we would cache those results in Redis for an appropriate period of time to make it available to other applications in a timely manner without having to rerun the original process. This reduces the time/cost normally incurred to review that data set.
  • Speed: Redis is, generally speaking, very fast. I typically place Redis somewhere within my internal network so the major factor in the speed of retrieving data is the size of the data cached.
  • Configuration: Redis is very configurable to the point where you can utilize it as simply as a single instance running with no backups to a multi-tiered cluster running with permanent storage, data backups, and replication.
  • Documentation: Redis has done a good job of documenting all of its capabilities as well as providing guidance in terms of what client libraries exist to help the developer's application(s) interface with it.
  • I, as a rule, don't use Redis for persistent data, but it would be nice if Redis had an option to persist data to another data source such as MySQL or PostgreSQL.
  • This is more a wish list item than a con but, it would be nice to have the ability to configure Redis as a write-through proxy. This is generally done by having a processor processes write-data to Redis, another process then reads the data from Redis and writes it to a database, and then finally the keys that have been written are flushed out of Redis.
  • We have used Redis to improve the speed/performance of several applications, as well as make those applications a little more scalable.
  • There are certain paid services we use where we are charged for every API call we make to them. By caching the results of those hits, we were able to reduce the number of overall calls to the service.
  • Product Features
  • Product Usability
  • Prior Experience with the Product
For me, the single most important factor in the decision-making process was my previous experience with the product. Once I understood what it was, and what it wasn't, it was very easy to find places where it would not only work but improve a given process. Another important deciding factor is its ease of use. I'm able to go from nothing to coding in a very short time period.
The only other product I've used that I would compare to Redis is Memcache. I prefer Redis simply because of its ease of use and it's very well documented. It also has a lot of community support which means there are a large number of client libraries that exist to make the development of a project easier on me.
Slack, GitHub, DBeaver, Docker, Sublime Text, PhpStorm, IntelliJ WebStorm, PyCharm, PostgreSQL, Ubuntu Linux, Red Hat Enterprise Linux (RHEL), Nginx, Apache Web Server, Oracle VM VirtualBox
Redis is well suited for storage of ephemeral data that could be used by multiple processes. For example, a multi-server website that sits behind a load balancer could use Redis to store session information that might typically be stored on the filesystem. This would allow all the website nodes to share session information without having to resort to sticky sessions.

I generally try to avoid using Redis as a primary data source for critical data.

Redis™* Feature Ratings

Performance
8
Availability
8
Concurrency
8
Security
Not Rated
Scalability
6
Data model flexibility
8
Deployment model flexibility
8