Load My Code

No frills backup automation

Why use In Memory data grid over Redis

Hazelcast and Redis look similar at first glance. They can solve similar problems, so it may be hard to decide which one to use. We have had extensive experience with using both Redis and Hazelcast. Although these products are usually not compared together, In this post, we’ll try and explain why we chose HazelCast over Redis in our backend application.

Guess what is faster than Redis? The data within your own application!

One thing we value over all other is simplicity, We did not want another moving part. HazelCast allowed us to embed the data right within our application memory and scale it across nodes without having to worry about maintaining another caching server or having to worry about latency.

Redis is good for simple data caching use cases, but in the real world, you will want more than simple caching from your in-memory computing platform. You will hit this wall sooner than you think.

Querying:

Redis and Hazelcast both provide Key/Value structures, but they work quite differently when you want to query. By query we mean the ability to retrieve data when you do not know the key, so you are querying by specific properties of the value.

The most fundamental difference is that Hazelcast is able to store complex objects and understand the object graph. Redis is unable to do this, in order to reason about graphs the developer has to model the graph in a series of key/value entries where part of the key represents a property and its value. Redis does not provide the ability to division data using concepts such as tables, everything is stored in one namespace, e.g. the Database. Hence the need to come up with complex namespace schemes within keys.

On the other hand, Hazelcast provides a Predicate API and SQL like where clauses and projections to query out data. These Querying API can be used on Complex Objects and JSON. Hazelcast also has a more flexible namespace in that you can have many Maps and name these appropriately, for example, Customer, Invoice, Orders. This then negates the need to pollute the key namespace with these concerns, your keys can just describe the actual value being saved.

Messaging:

One of our use case included updates to be transmitted to all the nodes in real-time, We could have used another moving part like RabbitMQ, but since all your nodes are already connected with HazelCast, It is capable of doing both peer-2-peer and Multicast messaging between our backend nodes.

To summarize, we use HazelCast to avoid another moving part like Redis, more moving parts always means more complexity. We use Java as our backend technology and hence HazelCast became an obvious choice.

We are currently at an early stage and have kept our tech very simple and grounded, we are very flexible to change and we will change as our requirements change or unravel.

(C) 2024 Codologic Pvt. Ltd. #REG: U72900MH2017PTC298460