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.