Redis or Ehcache?

Question

Which is better suited for the following environment:

1. Persistence not a compulsion.
2. Multiple servers (with Ehcache some cache sync must be required).
3. Infrequent writes and frequent reads.
4. Relatively small database (very less memory requirement).

I will pour out what's in my head currently. I may be wrong about these.

I know Redis requires a separate server (?) and Ehcache provides local cache so it must be faster but will replicate cache across servers (?). Updating all caches after some update on one is possible with Ehcache.

My question is which will suit better for the environment I mentioned?
Whose performance will be better or what are scenarios when one may outperform another?

Thanks in advance.

Gassaway

a bit of explaination?? – Gassaway

from (java//spring) developer perspective, it is much more easy to implement – Twelvetone

any idea which is better performance wise?? – Gassaway

you should think about performance when you got a performance issue..not now – Twelvetone

You Can think of Redis as your Cache implementation, as it has distributed nature while using Amazon's ElastiCache, its a better choice for developers for making caching server for the application infrastructure – Triplicity

Here an article that may give some information about the performance of Ehcache and Redis (plus other caching solutions): Evaluation of Caching Frameworks – Tectrix

Answer 1

You can think Redis as a shared data structure, while Ehcache is a memory block storing serialized data objects. This is the main difference.

Redis as a shared data structure means you can put some predefined data structure (such as String, List, Set etc) in one language and retrieve it in another language. This is useful if your project is multilingual, for example: Java the backend side , and PHP the front side. You can use Redis for a shared cache. But it can only store predefined data structure, you cannot insert any Java objects you want.

If your project is only Java, i.e. not multilingual, Ehcache is a convenient solution.

Saccular

Yes but I can always serialize java objects into JSON strings and store in redis. I believe that's the way most people use redis as a cache. – Gassaway

Is it really worth if my data never grows beyond 100 or 200MB max where I don't want to distribute data across clusters. If my data is limited(max 200MB). Is redis a good choice then? Is EhCache better than Redis in that case? – Understate

Which one will have a better performance? – Waggle

Answer 2

You will meet issues with EhCache scaling and need resources to manage it during failover and etc. Redis benefits over EhCache:

1. It uses time proven gossip protocol for Node discovery and synchronization.
2. Availability of fully managed services like AWS ElastiCache, Azure Redis Cache. Such services offers full automation, support and management of Redis, so developers can focus on their applications and not maintaining their databases.
3. Correct large memory amount handling (we all know that Redis can manage with hundreds of gigabytes of RAM on single machine). It doesn't have problems with Garbage collection like Java.

And finally existence of Java Developer friendly Redis client - Redisson.
Redisson provides many Java friendly objects on top of Redis, like:

• Set
• ConcurrentMap
• List
• Queue
• Deque
• BlockingQueue
• BlockingDeque
• ReadWriteLock
• Semaphore
• Lock
• AtomicLong
• CountDownLatch
• Publish / Subscribe
• ExecutorService
• and many more...

Redisson supports local cache for Map structure which cold give you 45x performance boost for read operations.

Here is the article describing detailed feature comparison of Ehcache and Redis.

Spathe

I ended up using redis and later switched to hazelcast (I find redisson similar to hazelcast though - support of java friendly objects etc). I''ll consider using redission in future projects :) – Gassaway