Redis set vs hash

Question

In many Redis tutorials (such as this one), data is stored in a set, but with multiple values combined together in a string (i.e. a user account might be stored in the set as two entries, "user:1000:username" and "user:1000:password").

However, Redis also has hashes. It seems that it would make more sense to have a "user:1000" hash, which contains a "username" entry and a "password" entry. Rather than concatenating strings to access a particular value, you just access them directly in the hash.

So why isn't it used as much? Are these just old tutorials? Or do Redis hashes have performance issues?

Cheesy

I think you are referring to the command SET, which is actually using the Strings datatype. It is just a key/value pair, as opposed to the actual Sets datatype (which uses SADD to add to the set). – Mascot

You are correct, it is using the SET command. I didn't realize this was a separate datatype, but that makes sense. – Cheesy

I don't know about perfomance difference and write small benchmark test github.com/logrusorgru/redisbm But different hash parameters (such as the number of fields) return a different result. And set/get is not always slower. – Multiangular

Answer 1

Redis hashes are good for storing more complex data, like you suggest in your question. I use them for exactly that - to store objects with multiple attributes that need to be cached (specifically, inventory data for a particular product on an e-commerce site). Sure, I could use a concatenated string - but that adds unneeded complexity to my client code, and updating an individual field is not possible.

You may be right - the tutorials may simply be from before Hashes were introduced. They were clearly designed for storing Object representations: http://oldblog.antirez.com/post/redis-weekly-update-1.html

I suppose one concern would be the number of commands Redis must service when a new item is inserted (n number of commands, where n is the number of fields in the Hash) when compared to a simple String SET command. I haven't found this to be a problem yet on a service which hits Redis about 1 million times per day. Using the right data structure to me is more important than a negligible performance impact.

(Also, please see my comment regarding Redis Sets vs. Redis Strings - I think your question is referring to Strings but correct me if I'm wrong!)

Mascot

Hi Mike, two questions. First, 1 million hits per day is about 12 req/s which with Redis-benchmark you see 30K on a low-end EC2 machine or 120K on a high-end laptop. How about more than 12 times per second? Do you think if you have few thousands per second SET will be a better choice than HASH? The second question is about what you said "n number of commands, where n is the number of fields in the Hash", if you need to store an item with two parameters it will be 2 times SET for storing separately same as hash if it does the same thing. You sure HASH hits the Redis as many as its fields? tnx – Ferrol

Answer 2

Hashes are one of the most efficient methods to store data in Redis, even going so far as to recommending them for use whenever effectively possible.

http://redis.io/topics/memory-optimization

Use hashes when possible

Small hashes are encoded in a very small space, so you should try representing your data using hashes every time it is possible. For instance if you have objects representing users in a web application, instead of using different keys for name, surname, email, password, use a single hash with all the required fields.

Unwind

would be a better answer if you showed an example – Haaf

@ChristianMatthew No, not really, actually. – Nappe

Answer 3

Use case comparison:

Sets provide with a semantic interface to store data as a set in Redis server. The use cases for this kind of data would be more for an analytics purpose, for example how many people browse the product page and how many end up purchasing the product.

Hashes provide a semantic interface to store simple and complex data objects in the Redis server. For example, user profile, product catalog, and so on.

Ref: Learning Redis

Lavine

Answer 4

• Use cases for SETS

  • Uniqueness:

    We have to enforce our application to make sure every username can be used by one single person. If someone signup with a username, we first look up set of usernames

    SISMEMBER setOfUsernames newUsername
    

  • Creating relationships between different records:

    Imagine you have Like functionality in your app. you might have a separate set for every single user and store the ID's of the images that user has liked so far.

  • Find common attributes that people like

    In dating apps, users usually pick different attributes, and those attributes are stored in sets. And to help people match easily, our app might check the intersection of those common attributes

    SINTER user#45:likesSet user#34:likesSet
    

  • When we have lists of items and order does not matter

    For example, if you want to restrict API addresses that want to reach your app or block emails to send you emails, you can store them in a set.

• Use cases for Hash

Redis Hashes are usually used to store complex data objects: sessions, users etc. Hashes are more memory-optimized.

Nowell