1. Home
  2. NoSQL Databases
  3. Redis™* Reviews
  4. User Review of Redis™*
Redis - memory is the new disk
March 30, 2018

Redis - memory is the new disk

Hugo Romani Cortes | TrustRadius Reviewer
Score 8 out of 10
Vetted Review
Verified User

Overall Satisfaction with Redis

I used Redis in the context of an Airline company middleware implementation. At that time, we were looking for an efficient caching solution with the possibility to distribute data across nodes (i.e. sort of data grid without the complexity of a data grid).
Redis allowed us to build very fast a small cluster of nodes (4) serving as a cache for storing web sessions.
Because of additional features of Redis (pub/sub, in memory Keystore), Redis was also identified as non-critical storage for some data.
  • Redis is easy to learn and concepts are very simple. It's an in-memory storage with regular snapshots for data resiliency.
  • Redis offers the possibility to act as a cache with limited but strong eviction set policies. LRU is the most common one.
  • The pub/sub feature of Redis is an interesting alternative for efficient and fast data distribution when we don't need a central broker such as JMS. Obviously, it requires some analysis before choosing between the bunch of providers (JMS, Kafka, MQTT, AMQP, Redis, etc)
  • Redis is sponsored by Redislab which limit its functionalities. This is normal but they should push for a graphical tool for Redis monitoring. This tool is available for the enterprise edition, it would be nice to have a core version for the community
  • I don't know if Redis is available in containers, this might be interesting to have such capability
  • Redis has a fast learning curve for developers and operations teams.
  • Community edition allows touching a small part of Redis capabilities. In case we need support and additional features, we can decide to buy the enterprise edition which offers many additional features.
Memcached didn't offer the possibility to distribute data easily across nodes. Memcached was more for near cache features whereas we were looking for a distributed cache.
Hazelcast and ActiveSpaces are considered as data grid with a powerful approach while distributing data (i.e. geo localization of data) but were more complex in terms of administration compared to Redis.
Redis is very easy to use and because of its open-source approach, we can convince a lot of people to start using it (even contractors). The philosophy of Redis is very interesting "small is beautiful" and drive all decisions while developing with such tool.
The memory optimization is also very important which allows fast data access while dealing with critical environments (SLA).
Redis fits perfectly when the cache is required or when fast data access is a criterion. With the community edition, we can build very fast and efficient cluster of data nodes with adequate persistent policy.

I don't recommend Redis if you are looking for something else than a key/value store. Even if Redis claims to be a "data structure server", you might face limitations while dealing with other data structures.

Redis™* Feature Ratings

NoSQL Databases
7.1
Performance
8
Availability
8
Concurrency
7
Security
7
Scalability
9
Data model flexibility
5
Deployment model flexibility
6

Using Redis

15 - Redis was used by many teams in my previous company. The main usage of Redis across these teams was to cache web sessions. Redis was also used in various PoC for exploring distributed cache and how efficient Redis was/is compared to the ad-hoc implementation of Memcached.
Majority of teams were working on internal projects and were not focus on client delivery.
5 - Colleagues supporting Redis (i.e. responsible) are mostly data and system experts already working with data distribution (NoSQL databases). They have a strong understanding of the system and network constraints (such as geolocalisation, bandwidth control, data sharing, etc).
They also have a clear understanding of alternatives and why, for specific use cases, it is better to use in-memory database compare to physical storage.
  • The main use case was for caching data in a distributed context. Redis is really powerful while dealing with data sharding and heavy traffic load
  • Another use case of Redis was the capacity to server faster data compare to physical databases. It was used for non-critical systems.
  • The last use case (minor) was to explore the pub/sub capability of Redis in the context of the multi-tenant application
  • To be honest, we were not really innovating with Redis, we were using common features.
  • I'm not anymore working for the company, but I remember that LUA script was explored. They were also trying to build bigger cluster (~100/150 nodes)