Redis Replacement

See Hazelcast in Action

Master intelligent applications with Hazelcast unified real-time stream processing platform.

Introduction

Redis is popularly used for simple data caching use cases, but in the real world, you want more than simple caching in your data architecture. Caching is about meeting technical SLAs but not necessarily about making your application development work easier. A caching-focused deployment only results in a significant effort for a short-term fix. This limits your ability to build the applications that add value to your business.

You should instead seek a software technology that can provide fast data access in a scalable way to meet your growing data workloads, and can also grow with your expanding use cases without complicating your data architecture and your application development efforts.

Two main reasons why developers choose Hazelcast as a replacement for Redis are:

  1. Scaling to future workloads: Redis has challenges scaling to handle future workloads. While Redis is typically chosen because it handles immediate requirements, the performance and manageability issues at larger scale put a huge burden on developers and DevOps engineers to resolve. One example of a scaling limitation we’ve seen is covered on our Hazelcast vs. Redis benchmark page.

  2. Stream processing for innovative applications: Redis does not provide stream processing capabilities to help you build applications that leverage streaming data. Note that Redis Streams is a message queue technology that competes with Apache Kafka, and does not cover stream processing functionality. On the other hand, Hazelcast Platform works well with Apache Kafka to help you build streaming applications.

The decision to replace Redis with Hazelcast should ultimately be based on simplifying your application development efforts, and with more emphasis today on streaming data sources, Hazelcast can help you build powerful streaming applications while also covering your Redis use cases. Check out our white paper on what we see as a practical comparison between Hazelcast and Redis.

The section below includes more technical details that you might be interested in.

Compare Hazelcast and Redis

Key architectural differences between Hazelcast Platform and Redis

Language. Hazelcast Platform is written in Java, while Redis is implemented in C. This lets you easily build distributed Java applications that embed Hazelcast Platform capabilities, like in a microservices architecture.

Threading. Redis is single-threaded. Hazelcast Platform can benefit from all available CPU cores as it scales.

Design. Hazelcast Platform is designed from the ground up for a distributed environment; Redis was initially intended to be used in standalone mode. Clustered Redis does not support SELECT commands, meaning it only supports a single database (namespace) per cluster. In contrast, Hazelcast Platform supports an unlimited number of maps and caches per cluster.

High availability. More on this in the failover section.

Hazelcast Platform

To reduce DevOps efforts and simplify deployment, Hazelcast leverages multicast discovery, where members use multicast UDP transmission to get to know each other automatically without any additional configuration. You don’t need to install software on every resource you add or manually rebalance your cluster.

It is possible to manually specify member addresses through TCP. You simply need to provide just one working address, regardless of whether your cluster consists of three or thirty nodes.

For cloud deployments, Hazelcast Platform supports automatic discovery of its member instances on Amazon EC2 and Google Compute Engine.

Hazelcast Platform provides a Discovery Service Provider Interface (SPI), which allows users to implement custom member discovery mechanisms to deploy Hazelcast Platform on any platform. Hazelcast Discovery SPI allows you to use third-party software like Zookeeper, Eureka, Consul, and more to implement a 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. A developer 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. (The script is included in Redis distributions.)

Adding a node to a Hazelcast Platform cluster is incredibly 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 Platform 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 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.

Benchmarks show that the performance of Hazelcast Platform outshines that of Redis. But to be clear, performance comparisons should not be a primary decision-making criterion anymore, as both technologies have proven to suit customers’ perfomance needs quite well. Benchmarks should mostly be used to show that in terms of performance, you can’t go wrong with either Hazelcast or Redis. But interestingly, Iin several cases, benchmarks run by other vendors have shown superior performance by their products because of unequal configurations that favor the other vendor.

One important point about Hazelcast performance is that superior speed is attained without needing to sacrifice other areas. For example, data safety features are kept intact in Hazelcast under high loads. On the other hand, Redis performs well at high loads because the system turns off replication to accommodate the load. This results in a system that is vulnerable to data loss should a master node fail, which is not a reasonable tradeoff for production systems. Details on this topic are covered in this blog post.

More benchmark information on Hazelcast vs. Redis is available here.

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 fails.

In a Hazelcast Platform cluster, all members are equal and hold primary data as well as a backup of the primary data from other members in the cluster. Thus, Hazelcast Platform 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 for 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.

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

Redis supports two modes of file system 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 Platform also supports file system persistence via the Hot Restart feature as well as abstractions for persisting to designated data stores such as SQL databases.

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

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

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

Hazelcast Platform also includes official support for the memcached protocol.

Fetching data from the server to the client and then extracting metadata on the client-side takes a great deal of time and uses excessive memory in the client. It is better to send 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 with both Hazelcast Platform and Redis.

Redis supports the 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 Platform 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, Hazelcast can route the tasks to cluster nodes a few different ways: randomly, based on address, or based on key ownership.

Hazelcast Platform 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 specific criteria.

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

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