Try Redis Cloud Essentials for Only $5/Month!

Learn More

Object->Hash Storage

Back to Glossary

The native Redis datatype hash(map) may, at first glance, seem very similar to a JSON object or other record data type. It is actually quite a bit simpler, allowing only for each field to be either a string or number and not allowing for sub-fields. However, by pre-computing the ‘path’ of each field, you can flatten an object and store it in a Redis Hashmap.

Take the this example:

{
    "colour":"blue",
    "make":"saab",
    "model":{
       "trim" : "aero",
       "name" : 93
    },
    "features":[ "powerlocks", "moonroof" ]
}

Using JSONPath we can represent each item in one level with a hashmap.

> HSET car3 colour blue
> HSET car3 make saab
> HSET car3 model.trim aero
> HSET car3 model.name 93
> HSET car3 features[0] powerlocks
> HSET car3 features[1] moonroof

(Shown as individual commands for clarity, in a script you would want to variadicly use HSET)

This provides a way to can get the entire object:

> HGETALL car3
 1) "colour"
 2) "blue"
 3) "make"
 4) "saab"
 5) "model.trim"
 6) "aero"
 7) "model.name"
 8) "93"
 9) "features[0]"
10) "powerlocks"
11) "features[1]"
12) "moonroof"

Or individual parts of the object:

> HGET car3 model.trim
"aero"

While this can provide a quick, useful method to access store objects in Redis, it does have downsides:

This pattern has significant overlap with ReJSON. If ReJSON is available, it is very often a better choice. Storing objects this way does have one advantage over ReJSON of being integrated with another Redis command: SORT. However, the SORT command is both a complex topic (beyond the scope of this pattern) and computationally complex which can be wielded in ways that don’t scale well if not very carefully managed.