Redis Replacement

Architecture

Key architectural differences between Hazelcast and Redis include:

  • Language: Hazelcast is written in Java, while Redis is implemented in C.
  • Threading: Redis is single-threaded. Hazelcast can benefit from all available CPU cores.
  • Design: Hazelcast is designed from the ground up to be used in a distributed environment; Redis was initially intended to be used in standalone mode. Clustered Redis does not support SELECT command, meaning it only supports a single DB (namespace) per cluster. In contrast, Hazelcast supports unlimited number of maps and caches per cluster.
  • High availability: more on this in failover section.

Clustering

Hazelcast

  • The easiest option is multicast discovery, where members use multicast UDP transmission to get to know each other automatically without any additional configuration.
  • It is also possible to specify the member addresses manually through TCP. Providing just one working address will be enough regardless of whether your cluster consists of three or thirty nodes.
  • For cloud deployments, Hazelcast supports automatic discovery of its member instances on Amazon EC2 and Google Compute Engine
  • Hazelcast provides a Discovery Service Provider Interface (SPI), which allows users to implement custom member discovery mechanisms to deploy Hazelcast on any platform. Hazelcast Discovery SPI also allows you to use third-party software like Zookeeper, Eureka, Consul, etcd for implementing custom discovery mechanism.

Redis

  • A Redis client connects to a Redis cluster through a TCP connection. There is no provision for discovering Redis servers on a multicast UDP network.
  • Redis does not provide an automatic discovery mechanism for any cloud provider, which makes it difficult to use in custom cloud deployments.
  • Establishing a Redis cluster is not straightforward — one needs to launch a special utility script while specifying all member addresses. This utility script (“redis-trib.rb”) is written in Ruby and thus requires additional Ruby runtime dependencies (script is included in Redis distribution).

Scaling

Adding a node to the Hazelcast cluster is super easy — just launching the node with the proper configuration does the job. Removing a node is also remarkably simple — just shutdown the node and the data is recovered on other nodes from backups.

In both cases, Hazelcast automatically rebalances the data across all available server nodes, without affecting the availability of the data.

On the other hand, adding a node to a Redis cluster is not as convenient — the user has to use the utility script to manually introduce a new member and then re-partition the cluster with the same script. Removal in Redis is similar, but the order of operations is different — repartition, make the cluster “forget” about the node, and only then shutdown.

Speed

We have performed several tests to compare the performance of Hazelcast Java client to Jedis, the most widely used Java client for Redis.

See the Redis vs Hazelcast Benchmark for the performance comparison.

Failover

When it comes to providing fault-tolerance, Redis uses a traditional master-slave approach, where each primary site for the data is backed up by one or more slaves that are promoted if the master goes down.

In a Hazelcast cluster, all members are equal and hold primary data as well as backup of the primary on other members in the cluster. Thus, Hazelcast requires fewer physical machines to establish the same level of resilience. Also, Redis slave nodes do not process read requests, which reduces the throughput of the entire system.

High availability of Redis is provided by Redis Sentinel, which continuously monitors the Redis cluster and initiates a slave promotion if it detects a master failure. At least three instances of Sentinel are recommended for a reliable deployment, which unnecessarily uses resources.

In Hazelcast, member failures are detected by other cluster peers, and recovery of lost data from backups is initiated automatically and immediately on remaining members in the cluster

Persistence

Redis supports two modes of filesystem persistence — append-only file (AOF) and snapshotting (RDB):

  • Append-only file is similar to write-ahead logs employed by SQL databases that record each mutating operation to a file that can be played back at database start to recover the data.
  • Snapshotting periodically dumps memory contents to a file.

Hazelcast also supports file system persistence via the Hot Restart feature as well as abstractions for persisting to arbitrary data storages, such as SQL databases.

With Hazelcast data can be backed up by a database in two distinct ways: database first (write-through), or cache first (write-behind).

If the user requests a non-existent entry from the map, Hazelcast is able to look up missing data from the database and, if found, automatically save it for later use in the map.

Client support

Hazelcast has officially supported clients for Java, Scala, C++, C#, Python and JavaScript/Node.JS. Redis has community-developed clients for most mainstream languages.

Hazelcast also includes official support for Memcached protocol.

Distributed computing

Let’s say you have stored a hundred gigabytes worth of data in your cache and you need to quickly find all the photos that were taken around a certain location.

Simply fetching the data from the server to the client and then extracting the metadata on the client side might work, but it will take quite a lot of time and will also cause memory pressures on client

A better way to achieve this is to send the extraction logic to the servers that store the actual data and let them work in parallel, with less data exchanged over the wire.

This can be done in both Hazelcast and Redis.

Redis supports evaluation of Lua scripts that can invoke pretty much any Redis operation. In clustered mode the Lua scripts have a limitation — if the script is going to use multiple keys, all those keys must belong to the same hash slot (partition).

Hazelcast has a Distributed Execution Service, which is a special implementation of java.util.concurrent.ExecutorService that allows one to distribute computation tasks written in Java among several physical machines. Depending on the use case, the tasks can be routed to cluster nodes in a few different ways — randomly, based on address, or based on key ownership.

Hazelcast also supports efficient bulk updates of map data with an abstraction called EntryProcessor. EntryProcessor can be executed on all keys, specific keys supplied by the user, or on keys that match a specific criteria.

Querying

Hazelcast supports predicate API for locating the map entries by value attributes.

Redis does not support querying directly, but makeshift solutions can be done using sorted sets.

Get the Full Comparison

For the full side-by-side comparison grid of Redis vs Hazelcast, get the comparison whitepaper.

Hazelcast.com

Menu