Hazelcast IMDG (In-Memory Data Grid) is a distributed, in-memory data structure store that enables high-speed processing for building the fastest applications. It creates a shared pool of RAM from across multiple computers, and scales out by adding more computers to the cluster. It can be deployed anywhere (on-premises, cloud, multi-cloud, edge) due to its lightweight packaging that also makes it easy to maintain, since there are no required external dependencies. It provides a processing engine on distributed data structures such as maps, lists, queues, and topics to enable large-scale use cases such as payment processing, key-value stores, messaging, and distributed caching-as-a-service. It supports APIs for Java, C++, Go, .NET, Node.js, Python, and Scala. It offers business continuity capabilities (high availability and disaster recovery), and a full suite of security features. With its CP Subsystem, it can guarantee data consistency even during a network outage that results in a partition.
Images
Check Software Images
Customer Reviews
Hazelcast IMDG Reviews
Tharanga H.
Advanced user of Hazelcast IMDGWhat do you like best?
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.
What do you dislike?
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.
Recommendations to others considering the product:
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.
What problems are you solving with the product? What benefits have you realized?
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
