HGETALL vs HMGET

[Rob Faraj]

I have a hash of 15 or so fields. I'm retrieving about 10 of them for a particular query. I originally was going to do this with hmget; however, is there a point where it makes more sense from a performance standpoint to choose hgetall over hmget? Thanks in advance.

[Dvir Volk]

From tests I did, if  the difference is big it's definitely worth doing HMGET, can boost performance a lot.

btw if you're getting all the fields and know in advance the order, the fastest would be HVALS. but that's risky.

On Thu, Mar 10, 2011 at 12:27 AM, Rob Faraj <rfa...@gmail.com> wrote:

I have a hash of 15 or so fields. I'm retrieving about 10 of them for a particular query. I originally was going to do this with hmget; however, is there a point where it makes more sense from a performance standpoint to choose hgetall over hmget? Thanks in advance.

--
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.

--

Dvir Volk

System Architect, Do@, http://doat.com

[Rob Faraj]

Unfortunately I cannot use HVALS because different keys are not always added at the same time. Sounds as if HMGET is the better choice for my current situation. I wonder if HGETALL is ever a better choice over HMGET. Maybe when retrieving the whole hash?

[Dvir Volk]

they should be more or less the same when retrieving everything, since the only difference is whether you are pushing the field names up or receiving them downstream.

HGETALL is most useful if you're working in "schemaless" mode where some hashes may contain more fields than others and you don't know even that in advance.

[Pieter Noordhuis]

Hi Rob,

HGETALL can definitely be a win over HMGET once your hashes are a
little bit larger. By default, Redis stores small hashes in a
compressed linear structure. This means that doing HMGET against such
a structure does a linear search for every key you want to retrieve.
On a small scale, this is barely noticeable (since probably the entire
compressed structure will be in the processor's cache). I would say
there is a sweet spot for going for HGETALL (since that only does a
single linear sweep), but I don't know where it is. If you use the
unstable branch of Redis, you'll have nice per-command statistics on
their total and average running time, so you can benchmark where it
makes sense to switch to HGETALL for you.

Cheers,
Pieter

[Salvatore Sanfilippo]

On Thu, Mar 10, 2011 at 9:33 AM, Pieter Noordhuis <pcnoo...@gmail.com> wrote:
> If you use the
> unstable branch of Redis, you'll have nice per-command statistics on
> their total and average running time, so you can benchmark where it
> makes sense to switch to HGETALL for you.

What just to echo with Pieter about this:

$redis-cli info commandstats
# Commandstats
cmdstat_hset:calls=16329,usec=144147,usec_per_call=8.83
cmdstat_hget:calls=363,usec=2040,usec_per_call=5.62
cmdstat_info:calls=3,usec=648,usec_per_call=216.00

Cheers,
Salvatore

p.s. time per call may appear large compared to your instance since
this is an MBA 11"

--
Salvatore 'antirez' Sanfilippo
open source developer - VMware

http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele