Performance comparison of using Redis hashes vs many keys

user_13493805 0
Viewed 5779

Okay, I'm currently planning on using Redis as a front end cache to my NoSQL database. I will be storing a lot of frequently used user data in the Redis database. I was wondering if making a key-value entry for each user would be better or using the Redis hash where the field is the user id and the value is a large json object. What do you think would be better?

I saw this article to sort of answer the question, but it doesn't discuss the limitations on value size.

redis caching database
1 Answers

Choosing hash over string has many benefits and some drawbacks depending on the use cases. If you are going to choose hash, it is better to design your json object as hash fields & values such as;

127.0.0.1:6379> hset user:1 ssn 10101010101 name john surname wick date 2020-02-02 location continental
(integer) 5
127.0.0.1:6379> hgetall user:1
 1) "ssn"
 2) "10101010101"
 3) "name"
 4) "john"
 5) "surname"
 6) "wick"
 7) "date"
 8) "2020-02-02"
 9) "location"
10) "continental"

Here are the benefits of hash over strings when you do a proper data modeling.

  • On the performance side most of the commands for both strings and hash have same complexity.
  • Access/update/delete individual json fields on hashes easier when it is compared to the strings. You don't have to get the whole string, decode, make changes and set it again. You may use HDEL, HSET or HGET for those operations without getting the whole object.
  • If the size of your string object increases, you will suffer from network and bandwidth while transferring(get/set) the whole object. As it is stated in the documentation

Speed of RAM and memory bandwidth seem less critical for global performance especially for small objects. For large objects (>10 KB), it may become noticeable though.

  • Hashes are more memory friendly than string if you make good benchmark to design your data size. As it is stated in the documentation and an example use case by instagram engineering you may get a huge benefit with the special encoding.

Hashes, Lists, Sets composed of just integers, and Sorted Sets, when smaller than a given number of elements, and up to a maximum element size, are encoded in a very memory efficient way that uses up to 10 times less memory (with 5 time less memory used being the average saving).

On the other hand, depending on your use case(s);

  • ziplist doesn't come for free, it is a tradeoff between memory and cpu.
  • You can't partially expire hash fields. If you divide into the multiple strings then you may EXPIRE them but in hashes only the top level key can be expired with all the values.
user_21889220
Related