SORTSTORE command proposal
Aníbal Rojas
Being able to SORT on LISTs and SETs in Redis is cool. Having a
ordered set is cool, being able to SORTSTORE is cooler ;)
SETs provide commands to store the result of UNION, INTERSECTION
and DIFF commands, something useful.
Now imagine being able start with a LIST or SET, SORT according
to the BY, GET and/or LIMIT options and generating the corresponding
ZSET, _server_ side. Isn't it heaven?
Actually I am modeling a problem that will avoid transferring a
lot of data client side and back if being able to do this.
Your thoughts?
--
Aníbal Rojas
Ruby on Rails Web Developer
http://www.google.com/profiles/anibalrojas
Salvatore Sanfilippo
>
> Hello,
>
> Being able to SORT on LISTs and SETs in Redis is cool. Having a
> ordered set is cool, being able to SORTSTORE is cooler ;)
>
> SETs provide commands to store the result of UNION, INTERSECTION
> and DIFF commands, something useful.
>
> Now imagine being able start with a LIST or SET, SORT according
> to the BY, GET and/or LIMIT options and generating the corresponding
> ZSET, _server_ side. Isn't it heaven?
>
> Actually I am modeling a problem that will avoid transferring a
> lot of data client side and back if being able to do this.
>
> Your thoughts?
Hello Anibal,
you can find the proposal already in the TODO list indeed.
It's *very* useful indeed (imagine to set an EXPIRE on this just to
use as a cache when real-time sorting is not important) but I think
I'll use the syntax proposed in the TODO list, that is:
SORT ... BY ... STORE <keyname>
I think it should really not do any difference.
Cheers,
Salvatore
--
Salvatore 'antirez' Sanfilippo
http://invece.org
"Once you have something that grows faster than education grows,
you’re always going to get a pop culture.", Alan Kay
Aníbal Rojas
Salvatore,
Great news, but where is the TODO list, can't find in the Wiki...
(maybe is just because is Sunday) :)
--
Aníbal
On Nov 2, 9:02 am, Salvatore Sanfilippo <anti...@gmail.com> wrote:
> 2009/11/1 Aníbal Rojas <anibalro...@gmail.com>:
>
>
>
>
> > Hello,
>
> > Being able to SORT on LISTs and SETs in Redis is cool. Having a
> > ordered set is cool, being able to SORTSTORE is cooler ;)
>
> > SETs provide commands to store the result of UNION, INTERSECTION
> > and DIFF commands, something useful.
>
> > Now imagine being able start with a LIST or SET, SORT according
> > to the BY, GET and/or LIMIT options and generating the corresponding
> > ZSET, _server_ side. Isn't it heaven?
>
> > Actually I am modeling a problem that will avoid transferring a
> > lot of data client side and back if being able to do this.
>
> > Your thoughts?
>
> Hello Anibal,
>
> you can find the proposal already in the TODO list indeed.
> It's *very* useful indeed (imagine to set an EXPIRE on this just to
> use as a cache when real-time sorting is not important) but I think
> I'll use the syntax proposed in the TODO list, that is:
>
> SORT ... BY ... STORE <keyname>
>
> I think it should really not do any difference.
>
> Cheers,
> Salvatore
>
> --
Salvatore Sanfilippo
>
>
> Salvatore,
>
> Great news, but where is the TODO list, can't find in the Wiki...
> (maybe is just because is Sunday) :)
Sorry no TODO in the Wiki, it changes a bit too often ;) It's in the
Git repository and in the tar.gz (but the only up-to-date version is
on Git).
Salvatore Sanfilippo
>
>
> Salvatore,
>
> Great news, but where is the TODO list, can't find in the Wiki...
> (maybe is just because is Sunday) :)
Hello again,
ok "STORE" option implemented in Redis git.
Tested it a bit, should work. Will write tests and docs later...
Aníbal Rojas
Are you planning to support UNION, INTER and DIFF on ZSETs?
--
Aníbal
Sent from my mobile device
Salvatore Sanfilippo
> Wow! Will have to fork and submit the patches in the Ruby driver.
>
> Are you planning to support UNION, INTER and DIFF on ZSETs?
not sure in the short time, but in the long run it can be *very*
interesting, since with ordered sets this algorithms can be
implemented in a very efficient way. I think that an operator
supporting intersection with optional LIMIT is particularly useful
because this allows to implement tag systems in an efficient way even
when it's needed, for instance, to paginate all the objects having
tags foo,bar,and zaaap, that is an extremely useful operation to use
in practice that's basically impossible to implement in an efficient
way with SQL dbs.
Cheers,
Salvatore
Ericson Smith
Salvatore Sanfilippo
> Seconded!
> I'm working on something with Redis right now that has exactly this problem.
> An intersection with LIMIT is absolutely essential. It would be great with
> ZSETS, but a good beginning is with standard sets as well.
Hello Ericson,
maybe there is already a solution suitable for you if you don't need
real-timeness.
Basically it's like this:
SINTERSTORE myintersection set1 set2 set2 ... setN
EXPIRE myintersection <time to live>
SORT myintersection BY none LIMIT ...
Of course you have to deal with myintersection expiring, and call
again SINTERSTORE in order to rebuild it.
But with our current Sets this problem is really without good
solutions, because to perform the *full* intersection is needed every
time even if we only need to get the top 10 items. Instead with sorted
sets there are algorithms to make this much more faster.