If
you are evaluating high-performance NoSQL solutions such as: Redis,
Riak, Couchbase, MongoDB, Cassandra etc. or in even rarer cases if
you’re evaluating caching solutions such
as Memcached or EHcache, it’s possible that your best choice may be
Hazelcast: Hazelcast uses a considerably different approach to any of
the above projects, and yet for some classes of people looking for a
Key-Value store, Hazelcast may be the best option
for you.
So lets look at Hazelcast and why it is better alternative for above mentioned systems, Hazelcast is an In-Memory Data Grid, not a NoSQL database.
advantages
and disadvantages of using Hazelcast in-memory solution, first of all
as being key-value store into the memory, it has some default advantages
are speed and read efficiency
but also some natural disadvantages as storing map into memory are
scalability and volatility, as we know that size of RAM is always less
than the total available disk space, as RAM is more expensive than the
disk, so being in-memory store space is always
been a constant and second one as being flash storage, RAM refreshes
itself on process restart, resulting into the data loss. Hazelcast
addressing this shortcomings of the in-memory stores by providing
efficient and convenient solution.
In
Hazelcast, scalability issue is addressed by clustering solution, as
joining hundreds nodes into the cluster, we may aggregate more than
terabytes of in-memory space, to accommodate
Hazelcast map into the memory. Of course this not going to be compared
with disk space as its been 100 times more than memory but depending
upon use case some terabytes of space is sufficient for the in-memory
operations or else this solution may use with
some backend data store.
Volatility,
in Hazelcast volatility handled by peer to peer data distribution, so
every block of data has multiple copies(replication across the cluster)
of it present on different
locations, as any node/rack goes down because of some issue, we can
recover data from other copies present on other locations. The number of
backup copies can be configured as depending upon the data criticality.
Too much copies of the data into the cluster
may reduce the overall availability of working memory to other
operations. Hazelcast addresses the tuning problem of the cluster by
providing ways to make your cluster available and reliable, including
setting up backup process for example servers on one rack
would be set to back up on another rack, so failure of entire rack can
be managed gracefully.
Hazelcast
also address the Rebalancing problem of the cluster, whenever node is
added/removed to/from the cluster can be lead to moving data across the
cluster to rebalancing
it. If the node crashes because of some issues, the data copy(primary)
on dead node has to be re-owned by the another node who is having
replica of that data copy(secondary) becoming primary and backed up on
another node to make cluster fail-safe again. this
process may consume more cluster resources like CPU, RAM, network etc.
might lead to latency into the process during this whole process.
