On Mar 9, 2008, at 6:21, Tomash Brechko wrote:
Indeed, when we say the client implements the Ketama consistent
hashing algorithm, we mostly mean the idea of mapping servers onto
points on the ring, but not necessarily the same implementation as in
libketama.
I ensured my client could be configured to provide the same results
as libketama by using libketama to generate a test case that must pass
before I can generate a jar.
While developing Cache::Memcached::Fast we considered using libketama,
but it does too many things (I/O, shared memory, synchronization),
The shared memory thing really tripped me up for a while. It's
basically a cache, but one that I was having trouble invalidating. It
might be beneficial for short-lived processes, but that's not my target.
plus it uses MD5 hash, which I think is an overkill: there's no
requirement for server name hash to be irreversible, plus MD5 is 16
bytes when only 4 bytes are needed. It's not a question of
performance of course, as server additions/deletions are rare, but
more a matter of minimalistic approach.
As someone mentioned, ketama does use all of the md5, but I look at
md5 as an implementation detail. I implemented md5 (with the byte
reuse) to be compatible, but I wouldn't recommend it as it will be
slower than other options.
At this point, ketama is a baseline as it is the de facto standard.
--
Dustin Sallings
