jlehva
commented
9 years ago Here's benchmarking with Sets vs Sorted Sets when doing union (Redis version 2.8.18):
ZUNIONSTORE with 5 Sorted Sets each containing 1 million unique values:
127.0.0.1:6379> ZUNIONSTORE event:zunion:subs 5 event:z1:subs event:z2:subs event:z3:subs event:z4:subs event:z5:subs (integer) 5000000 (37.83s)
SUNIONSTORE with 5 Sets each containing 1 million unique values:
127.0.0.1:6379> SUNIONSTORE event:sunion:subs 5 event:s1:subs event:s2:subs event:s3:subs event:s4:subs event:s5:subs (integer) 5000000 (3.48s)
rs
I was wondering is there a reason why the event subscribers (event:eventName:subs) are saved as Sorted Set (ZSET in Redis) instead of Set (SET in Redis). I was unable to figure out a use case for ordering subscribers of an event. Also it seems that the pushd is setting the score for sorted set values to 0 which means they are not in an order anyway.
My concern is that it's slower to handle Sorted Sets than Sets. Especially doing Unions for Sorted Sets takes roughly 10 times more time if you compare to Sets.
The use case why I ended up thinking about this is as follows:
I got a system that releases messages. Each message contains n amount of keywords. Those keywords each have a matching event and I should be pushing those messages to the events as they get released.
The problem is that a single user might have subscribed to keywords that are both found from the same message. That causes the same message to be sent twice for the same userwhich is not very optimal.
I was thinking of a solution that takes Union (ZUNIONSTORE with TTL) of each events subscribers and then sends the message to that Union. That way the users would receive the message only once. Instead of ZUNIONSTORE I would like to use SUNIONSTORE but it's not possible to do that for Sorted Sets (event:eventName:subs).