Redis and Hazelcast both provide Key/Value structures, but they work quite differently when you want to query. By query we mean the ability to retrieve data when you do not know the key, so you are querying by specific properties of the value.
The most fundamental difference is that Hazelcast is able to store complex objects and understand the object graph. Redis is unable to do this, in order to reason about graphs the developer has to model the graph in a series of key/value entries where part of the key represents a property and its value. Redis does not provide the ability to division data using concepts such as tables, everything is stored in one namespace, e.g. the Database. Hence the need to come up with complex namespace schemes within keys. This StackOverflow post describes this approach.
On the other hand, Hazelcast provides a Predicate API and SQL like where clauses and projections to query out data. These Querying API can be used on Complex Objects and JSON. Hazelcast also has a more flexible namespace in that you can have many Maps and name these appropriately, for example, Customer, Invoice, Orders. This then negates the need to pollute the key namespace with these concerns, your keys can just describe the actual value being saved.
Here’s a code sample of a SQL like query on a Hazelcast Map, you’ll see it’s in Java but the concept is the same in all the languages supported by Hazelcast. For more information view our documentation.
IMap<String, Employee> map = hazelcastInstance.getMap( "employee" );
Set employees = map.values( new SqlPredicate( "active AND age < 30" ) );
NOTE: Starting with Hazelcast IMDG 4.1 there will be support for full ANSI SQL Querying.
Finally, Redis does not natively support indexes, instead, the application programmer has to create their own index structures and update these themselves, as well as referring to them. This is described in the Redis Documentation.
Hazelcast has native support for indexes. They can be applied via configuration (XML|YAML) or dynamically via the API. Indexes can be applied at any level of the object graph. Compound Indexes are supported. For more information view our documentation.