The problem/use-case that the feature addresses
Our user wants to return score when querying the ranking through zrank, instead of querying through zscore again.
Currently, we can recommend users to use pipeline to solve this problem (avoid network waits), but I think this scenario should become a built-in feature of Redis, as it is so common.
Possible command formats:
1，
z[rev]rank key member [withscore]
2，
z[rev]rankwithscore key
Why not pipeline
For many clients, using pipeline not only requires accepting a new concept, but also requires adjustment in code, new pipeline class or other.
Comment From: RinChanNOWWW
I prefer the first format.
Comment From: oranagra
I think the first option is preferred since it is inline with other commands like ZRANGE.
speaking of ZRANGE, isn't it plain and simple to use ZRANGE WITHSCORES to get one items instead of ZRANK?
Comment From: RinChanNOWWW
speaking of ZRANGE, isn't it plain and simple to use ZRANGE WITHSCORES to get one items instead of ZRANK?
We just want to get the rank of a member by its name, so ZRANK might be better.
Comment From: itamarhaber
I like the idea. However, the 1st option will lock us into single-key ZRANK forever.
Comment From: yangbodong22011
I like the idea. However, the 1st option will lock us into single-key ZRANK forever.
@itamarhaber Are you thinking of a command like zmrank? Is it right? Will it support multiple member instead of multiple key? Like the following:
ZMRANK key member [member ...]
Comment From: oranagra
we are not likely to ever add a ZMRANK that works on multiple keys.
but letting ZRANK work on multiple members (like HSET does today), is a good point, and indeed the withscore option blocks it.
both can be solved by a plain pipeline of command, and both will require repeated lookup of the key, so i'm not sure which of them should be prioritized, arguably we can have both, by either two separate commands, or better yet, one command that can handle multiple members with or without score, we just need to get the syntax right, like:
ZGET key <count> member-1, member-2 ... member-n [withscore / withrank]
Comment From: itamarhaber
@yangbodong22011 sorry, I meant single-element instead of single-key.
@oran we can also go full-ugly (a la MIGRATE) so we don't add a new command and do
ZRANK <key | numkeys key [key...] [WITHSCORE]>
Comment From: oranagra
not sure if it's as ugly as MIGRATE, or maybe uglier? in migrate we add an empty string as key, here you suggest we choose a flavor by checking the number of arguments. right? i'm not sure i'm happy with that, sounds like something we're gonna regret. @guybe7 ?
Comment From: soloestoy
OMG, don't add another ugly command as MIGRATE, ZRANK key member [WITHSCORE] is good enough.
Comment From: guybe7
Definitely not anything that resembles MIGRATE
Comment From: yangbodong22011
I think implementing two commands is easy to understand and friendly to client developers:
z[rev]rank key member [withscore]
zm[rev]rank key 3 member1 member2 member2 [withscore]
Comment From: oranagra
well in theory it could also be z[m][rev]rand[withscore], but i'd rather not add so many commands, and instead i'd rather the rev and withscore be arguments.
so maybe just the variadic one can be a separate command.
so the existing zrank, will get rev and withscore arguments.
and we'll someday (or todayadd a similarzmrank`
Comment From: yangbodong22011
Agreed, it looks like we have two features that I or someone else will start implementing once approved by the @redis/core-team
zrank key member [withscore] [rev]
zmrank key num-member member [member ...] [withscores] [rev]
Comment From: oranagra
Looking at this again, trying to decide if it justifies special commands (we can add hundreds of them if we open that door), i wanna ask again why / if that combination is considered common.
Do you have any examples or numbers to show that this is a common use case that deserves a special command?
Also, i wonder if we have any performance concerns against pipeline (in which case i'd like to see a benchmark), or is it just about convenience for people who find it hard to use pipeline?
Comment From: soloestoy
This is from our customers, if you like I can invite them to discuss here directly.
Anyway, get the rank and the score from a sorted set is a very useful and common case, for example, in game ranking list players wanna know who is the top3 players and their score at the same time.
Also, i wonder if we have any performance concerns against pipeline (in which case i'd like to see a benchmark), or is it just about convenience for people who find it hard to use pipeline?
In this theory pipeline can solve everything, but it's not a good way, not only from the performance perspective but also from the convenience perspective. And pipeline cannot support atomicity.
And I remember that when adding GETEX/GETDEL commands I asked the same question, but you said new commands are better(https://github.com/redis/redis/pull/8327#issuecomment-762801080), I don't know why you have different opinions on the same type of requests.
Comment From: oranagra
And I remember that when adding GETEX/GETDEL commands I asked the same question, but you said new commands are better(https://github.com/redis/redis/pull/8327#issuecomment-762801080), I don't know why you have different opinions on the same type of requests.
It's not that i have different opinions, it's the same concern: on one hand i'd like common things to be easy to use, and on the other hand i don't wanna add hundreds of commands for every combination of commands.
I guess at the time i thought that GET+DEL is a common use case, and i'm asking here about RANK+SCORE since it seemed less obvious to me.
Comment From: madolson
I have heard of an AWS customer asking for zmrank with scores. It was, stereotypically, a game company who wanted to fetch your score + friends scores. They wanted both the rank as well as the actual scores. They currently multi-exec it, but they wanted something simpler. Generally I like the two outlined commands/updates:
zrank key member [withscore] [rev]
zmrank key num-member member [member ...] [withscores] [rev]