Redis Reviews

Redis is extremely well suited for storing key-value kind of data. Flat and static values are around which they are built. There is no headache of indexing, or maintaining formats like other databases have.

I can also vouch for Redis's pub/sub notification. You can basically set expiration or event hooks around your keys, and Redis will trigger a notification for those events.

But Redis is ill-suited for treating it as a proper database. For instance, this is not a replacement for elasticsearch or mongo.

To assess if you need Redis, in my opinion, just think if you need to query values. If yes, don't use redis. If you are only concerned with key operations, then go with Redis.

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 is particularly suited when you want to mesh millions of data and get a unique statistics or a child dataset out of it. Then Redis is the only viable product with the highest number of read and write per second. It increases my speed drastically so that I am able to put 10k records per second and successfully retrieve at same speed.

Redis is great for application cache, internet cache, sharing sessions across stateless web servers. It also works well as a serializing channel for stream data. It has a pub-sub layer as well, which can be used to facilitate peer to peer data sharing. Because it's built as an in-memory store, it is not suitable for data durability.

If you want to increase your database queries changing from SQL to Redis probably you can optimize your performance using in-memory cached by Redis, doing this you can have a better workload on SQL servers but you have to configure correctly your complete infrastructure. Furthermore, you need a little bit of time to test your calls with a stress test.

Good for:

• Low latency queries are a must
• Frequent point queries as it is a key-value store
• Use awesome Redis Modules (Redis Search, Redis Neural Net, Redis ML, Redis-Secondary, Redis Graph)

Not suitable for (as far as I know):

• When values are complex objects and not simple data structures. Document stores are better for those work loads
• Huge data and not feasible (due to budget constraints) to scale up RAM

If you're doing caching, it's perfect. Especially when doing key-value store lookups. However, if you have a hardware load balancer, then setting up multiple slaves would be good. One slave is not so great for 1 million reads per sec. Transactions to the master can be slow at times depending on how much written to it Not as afast as say cassandra for writes.

For anything that requires a cache, redis has been a great option for me for several years. It can easily handle a huge volume of requests, making it a fantastic way to speed up a popular web application, for example. Being able to automatically expire entries after a certain amount of time helps reduce load caused by complex calculations or queries that use other data sources. It's simply fantastic.

If you are dealing with an application that needs to serve high volumes of redundant data or feel that memcached isn't doing enough for you, then it's time to consider redis. Also, redis can be a great tool to communicate between different applications without creating interfaces that might take a lot of time build.

This is best for needing to access data at a high volume quickly at a low cost. This is not the best option if you need high durability of the data and cannot suffer any data loss. Redis is perfect for key-value situations of data including a key being a hash and the value being a huge json object. It is not good when you need a more relational schema.