HMINCRBY
dvirsky
I've been using redis for a couple of months and I'm just at awe of
how great it is. So first of all - to the guy(s) behind it - I love
you :)
Now here's the thing:
I'm working a lot with hashes, and one thing i'm missing is a multiple
HINCRBY command, aka probably HMINCRBY.
I'm using redis (among other things) for a text classifier, where each
word has a hash containing a count of its appearance in different
categories. This means that training the classifier with a document of
1000 words, I need to make at least 1000 HINCRBY queries. which is
(relatively) slow.
Is this on the roadmap?
And is there some guide I need to read first if I want to provide a
patch to do this myself?
Thanks,
Dvir
Tim Lossen
in one or more batches to the server, which should improve
the speed dramatically.
for example, using the ruby client:
redis.pipeline do
redis.hincrby 'foo', 'a'
redis.hincrby 'foo', 'b'
...
end
cheers
tim
On 2010-09-15, at 12:00 , dvirsky wrote:
> I'm using redis (among other things) for a text classifier, where each
> word has a hash containing a count of its appearance in different
> categories. This means that training the classifier with a document of
> 1000 words, I need to make at least 1000 HINCRBY queries. which is
> (relatively) slow.
Dvir Volk
--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To post to this group, send email to redi...@googlegroups.com.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
Damian Janowski
> yeah, I just thought of that writing this email, I'll try it soon.
> however, if you have hmset, why not have hmincrby?
Because you don't have MINCRBY?
Salvatore Sanfilippo
> yeah, I just thought of that writing this email, I'll try it soon.
> however, if you have hmset, why not have hmincrby?
Hello Dvir, unfortunately there is some place where we need to stop
the specialization of commands.
And MSET is a very general operation of "set M values", so it seemed
like an important one to have, one of the most importants actually.
The same as DEL that is variadic.
Most other operations make sense in the "M" variant, but we found the
performances with pipelining are very close. We think we are currently
better serving the community with a shorter list of commands than with
slightly better performances for multi-operations compared to what you
get with pipelining.
Cheers,
Salvatore
--
Salvatore 'antirez' Sanfilippo
http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele
Dvir Volk
--
Salvatore Sanfilippo
> alright, cool. indeed pipelining improved the performance.
> btw - it would be nice to be able to add up float values. I can see why it's
> more optimal to just use integers, but perhaps you can do a smart switch to
> a float value if an incrby/hincrby command wants to add a float.
> btw2 - is there a difference in integer value ranges between 64 and 32 bit
> compilation of redis?
Hey Dvir,
for floats you have currently two options.
Option 1: use ZINCRBY to increment and ZSCORE to get the value,
against a sorted set of course.
Option 2: take your float, multiply it by... 100 for instance (if you
are ok with three digits after the dot), floor() it, add it. Do the
reverse when you want to retrieve the score.
Redis supports integers up to 64 bit in both 32 and 64 bit instances.
Cheers,
Salvatore
Dvir Volk
Salvatore Sanfilippo
> Thanks. I multiplied by 10000 in my implementation.
Ok with this you have a range of:
+/- 922337203685477
still much better than a 32 bit, and hard to overflow in a reasonable time.
for instance with 1 million increments every second you need 30 years
to overflow :)
And this gives you three digits of precision after the dot.
Sounds cool :)
But note that there is another interestion option that I forgot to
mention, that is to use two keys: one for the integer part and one for
the comma. Wrapping both increments and readings of the value in
MULTI/EXEC. Can be useful when there is the need of greater precision,
but there is to handle overflow (still possible in a completely atomic
way).
Cheers,
Salvatore