Moving key hashing into the client
bradoaks at gmail.com
Sat Jan 12 13:52:07 UTC 2008
Are you sure about the server computing a hash?
I don't believe the server computes a hash at all for the purposes of
determining on what machine the key will be stored. I believe that
*all* of this happens on the client side and that the servers don't
"know" about one another in any regard.
I'm using memcached 1.1.12 with the Perl client Cache::Memcached
version 1.24 in our environment.
Others will likely chime in too and let us know with more authority.
On Jan 12, 2008 6:00 AM, Tomash Brechko <tomash.brechko at gmail.com> wrote:
> 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