2

What is best practice in redis when we need to store multiple objects of same category?

Currently I store the whole object as json string.

For ex: Books.

{
   title:...,
   author:...
}

Option 1:

set book:1 book1
set book:2 book2
set book:3 book3

usage: get book:1 will give me the book object.

Option 2: hash

hset book 1 book1
hset book 2 book2
hset book 3 book3

usage: hget book 1 will give me the whole book object

Is there any huge difference in terms of performance or usage etc? Please share if you think of any other approach!

RamPrakash
  • 2,218
  • 3
  • 25
  • 54

1 Answers1

2

String vs Hash for storing JSON objects

Most of the relevant operations for Hashes and Strings are equivalent to each other in time complexity(GET/HGET/MGET/HMGET/SET/HSET). The only downside of using strings(GET/SET) is if you're concerned about being able to scan over the entire set of books as the SCAN and KEYS commands operate over the entire keyspace (every key in Redis) - even if your pattern was books:*, Redis would still need to iterate over all the keys. Whereas HSCAN and HGETALL operate only over the hash. In other words, if you're storing a lot of stuff in Redis, and you want to be able to iterate over all your books, a HASH can save you some time.

Storing JSON in Redis

You asked a question in the comments whether storing JSON is bad practice, there's definitely nothing wrong with it, and it's very common, the only downside of using JSON is that you can only GET/SET the entire string, and each time you pull the data out of Redis your app has to marshall the data from JSON and Serialize it back to JSON whenever you want to ship an update to the database. If that's a concern, it can be overcome with the RedisJson Module, but that's a whole separate topic.

slorello
  • 901
  • 5
  • 6
  • are you saying each object should be a separate hash!? I have updated my question. please check. – RamPrakash Jun 21 '21 at 20:29
  • 1
    Precisely, if you were using Option 2 each instance of a book would be stored separately as a hash under its own key, consequentially your keyspace would O(n) where n is the number of books. If you were doing it with flat strings (option 1) each FIELD would be stored under it's own key, so your keyspace would be O(n*m) where n is still the number of books, and m is the number of fields you're specifying.. – slorello Jun 21 '21 at 20:48
  • You are super confusing. I am not talking about object's individual fields. I am storing the whole object as binary string / json string. Is that a bad practice!? – RamPrakash Jun 21 '21 at 22:34
  • Sorry, it wasn't clear from your first edit that you were storing everything in JSON - it sounded like you were going to store each field for each book in a separate key, which was my original answer was so slated towards using a hash. I'd probably come down on storing each in its own key as a JSON object if that's an available solution for you. See my answer. – slorello Jun 22 '21 at 13:29