Hazelcast IMDG Reviews

I love the small memory of the library I embedded (since I have many issues with the memory of my pc).

It is also very fast and not complex at all and it saved my all my problems in the distributed systems for sure!

Nothing to share about this...I would say as a con that it takes a bit more time in order ro coordinate yourself where and what is located

Solved my problems with my relational databases where I was struggling with the whole backend team in managing correctly our db

Hazelcast first of all is a really great distributed data grid. You can use distributed collections out of the box like Map, Set, Queue for microservices replicas to share data or for caching purposes. Also, it is possible to take distributed locks to prevent doing the same work simultaneously. The Streaming framework Hazelcast Jet has many needful features and is very fast. Can be run separately from services or as a library. Supports automatic rebalancing and replication. Multiple network options to make a cluster such as multicasting or kubernetes support.

It`s a little bit tricky to set up cluster in Kubernetes but it`s a matter of reading the documentation carefully. You should write serializers for objects yourself but it`s your payment for the size of the memory footprint of your cache. Poor search options in in-memory data structures.

Great tool for distributed caches and for the stream processing

Distributed cache, distributed locking for microservices architecture. Stream processing of the big data.

Performance, ease-of-use, and JVM friendliness

Hazelcast implementation requires application changes. However, solutions like the Heimdall Proxy can manage Hazelcast clusters by providing the caching and invalidation logic for Hazelcast.

The Heimdall Database Proxy provides the caching and invalidation for Hazelcast. You can create a SQL cache subsystem in minutes without any code changes.

Improved response times and database scale via query caching

Hazlecast is great because it's distributed data-structures are extensions of commonly used java interfaces. Due to this our team was able to quickly grasp the framework, and implement our solution.

At the time I was using this (2017), there weren't much documentation explaining the internal behavior, so we had to dig in to the source code.

May be the stateful architectures that Hazelcast presents are not for every situation, as they are hard to manage (talking about DevOps). Use it when there is a dying need for performance.

Hazlecast IMDG helped us to reduce service transaction response times by an order of magnitude, by allowing us to process at the data nodes, in memory. This is a huge cut down in network and disk I/O, when comparing to traditional architectures, where all the data is loaded to the service nodes. It also helped us increasing the number of CPUs available for a single transaction, thanks to it's distributed executor service.

More details - https://medium.com/@tharanga.hewa/distributed-computing-for-not-so-big-data-a7a14600d4b8

Useful to store and retrieve as the service call is frequently get data than database

Key and value pair in concurrent mapping can be modified model or pojo class's with security upgrade

Good to go with this in today world and data

API service call to database is reduced to frequent hits makes deadlock on database. To avoid that ,hazelcast to store as cache needs to be implemented

Performance and how it is easy to start implementation. In-memory processing is great adventage, because of high availability.

Documentation is not as good as for Hazelcast IMDG and sometimes I do not know where I can find some information I am looking for.

We needed Stream processing platform which allow to connect to Kafka and generate some output based on Python scripts provided by business analitycs. Jet allowed us to get messages from Kafka, translate them, enrich with data from software based on another Hazelcast IMDG, execute Python scripts and generate expected output.

I like Hazelcast being configurable to auto back-up features of it. When one of your hazelcast instance is down, remaining instances in the cluster recovers those data from backup and continue working where it left.

I can't think of anything I don't like about Hazelcast IMDG, maybe the pricing would be the worst side of it.

I used Hazelcast embedded to the services. However, stand-alone usage of Hazelcast might provide a better/more sustainable cluster.

Hazelcast is solving our caching problem and fastens the data access time. It also makes it possible to spend less time on managing instances of cache. The instances can discover each other and communicate as default.

We enjoyed using hazel cast cluster for one of the highly scalable SaaS applications serving 2 million transactions every minute

Hazel cast was very stable and we loved it

We used Hazel cast back in 2013-2015 and those days I felt there were multiple opportunities to improve further. Some of those improvements which we had suggested didn't get implemented even after a a couple of years.

It used to be one of the well-known java based alternative for Memcached.

Give it a try:)

We used it for reducing DB hits for our highly scalable SaaS application

The ability to have a distributed cache with very high performance numbers

Setup on a distributed system can somethings be tricky, but with tools like Kubernetes it's much more simpler than used to be.

We needed to serve multiple customers. Before, the only way to scale was adding a bigger machine, now, we can just add a new node.

We had multiple services running independently. It was helping us to make financial data instantly available to all our services.

It's costly and you cannt add huge data in this as it stores data in in-memory.

Saved multiple back and forth calls between services as if you add data in any service and it will be instantly available to other services.