Moving key hashing into the client

Tomash Brechko tomash.brechko at
Sat Jan 12 11:00:47 UTC 2008


I'd like to share the raw idea, maybe it was already discussed here...

Currently clients send keys to memcached server, and the server
computes some hash function on them to decide where to store the key,
or where to find it.  However the client often too computes some hash
function on the key to decide which server to send the key to.  Could
we just send such precomputed value _along with the key_, and avoid
any computations on the server side?

Note that clients that work as part of one application have to agree
on their hash function to distribute keys consistently.  But it would
be OK if different applications compute hashes differently, as they do
not lookup the keys of each other.  So there's no real need to make a
centralized computations on the server, we may simply request that the
sent hash value is unsigned 32-bit integer (32-bit opaque actually,
that may be treated as integer by the server).  And the application
may always choose not to send key hash values, thus requesting the
server to compute it.  Legacy clients would work this way.

This would bring us back to protocol extensibility problem, but it was
agreed that we may always add new commands for new behaviours.

Is it worth implementing?

   Tomash Brechko

More information about the memcached mailing list