Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Redis Vs Hazelcast
If my app:
- Have a lot of http requests (6,000 per minute, I collect clicks info) that needs to be saved
- Have a lot of http requests that query the data previously saved.
My Questions are
- Which one between Redis and Hazelcast should I chose to store and query data
- which one is faster for reads and writes?
- which one is more reliable?
- Might Cassandra be a better option?
Answering any of the questions helps
We switched from redis to hazelcast for our caching needs.
- Protostuff + Hazelcast
is much faster for us than
- Protostuff + Jedis (pooled) + Redis
We use protostuff to serialize beans that are expensive to create. Hazelcasts standard-serialization mechanism is much slower. Our environment is Glassfish 3.1.
Hazelcast looks like they only have java libs, Redis has one for every language.
True. Hazelcast provides just a REST API and an implementation of the memcached protocol.
As of 2017, both Redis and Hazelcast offer highly available\scalable key\value storage. With very fast response times < 10ms.
Redis is unique in that it supports other data structures like sored sets, hash sets and a pub\sub mechanism. It's also extensible via lua scripting. It is probably the most popular and widely used of the two products. Especially outside of the Java ecosystem.
Hazelcast is unique in that it can be embedded in a Java host process, making it great for building stateful microservices without an external database dependency. It also has some other small differences, like the ability to get a call back from a key expiration. In a sense, it does less overall but the few things it does, it does them better. Especially if you're using Java.
Overall these are similar solutions designed for similar use cases like caching external data, creating a communication backplane or shared memory state for a stateful microservice, or possibly even storing (small amounts of non-relational) business data with some degree of durability.
There is a very handy lib - Redisson. It provides distributed Java objects and services (BitSet, BloomFilter, Set, SortedSet, Map, ConcurrentMap, List, Queue, Deque, BlockingQueue, BlockingDeque, ReadWriteLock, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, RemoteService, ExecutorService, LiveObjectService, ScheduledExecutorService) on top of Redis server!
It supports cluster, sentinel, master/slave and single connection modes.
Perfectly works in cloud and supports AWS Elasticache and Azure Redis Cloud
Below are some success stories from Redisson customers:
Moving from Hazelcast to Redis
Distributed Locking with Redis (Migration from Hazelcast)
To decide which one is the good, there is an issue about the client-thread using.
According to this benchmark Hazelcast is better than Redis if you use more thread. Maybe this is an unfair company benchmark but shows something about threading.
Both Redis and Hazelcast are memory based databases, so in theory, they should provided the same speed and performance. Looking over the docs for Hazelcast, you will get better support with Redis because of the wide amount of Libraries for interfacing with the database. Hazelcast looks like they only have java libs, Redis has one for every language.
Answers:
You will have to test this on your own, as far as I can tell different comparisons shows Redis as faster one of them is here, but i won't say these benchmarks are 100%
They should be both reliable, but I can not vouch for Hazelcast.
Maybe...
I would go with Redis, because I find it is the most usable and it has great documentation.
