Moving key hashing into the client

[Brad Oaks]

Hello Tomash,

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

On Jan 12, 2008 6:00 AM, Tomash Brechko <tomash.brechko at gmail.com> wrote:
> Hello,
>
> 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
>