On Oct 23, 7:55 pm, dormando <[email protected]> wrote:
> > You have to know the key to map it to a server and RAM location, but I
> > do not see any reason why you should have to store it.
> > The only explanation seems to distinguish values after a hash
> > collision, since you can not even iterate over the keys.
>
> I might provide it as an engine at some point, but in order to do that you
> have to change the hash table somewhat significantly, and you lose enough
> bytes that it's not worth while:
>
> 1) you have to expand the hash table size enough so there're generally few
> collissions, and when there are you can store in the bucket to the right
> of the intended one. Right now I think the hash table is 1/3rd the total
> item store size as a performance tradeoff.
1/3! Very nice. Is there any paper showing how to do this?
>
> 2) You have to store the hashed value with the items, so when pulling them
> off of the LRU, you can look up their hash table entry and remove them.
> Presently we do that by recalculating the hash from the key.
>
> So if your keys are already short it'd be a toss-up for the byte tradeoff.
> If you generally have long keys, you should really just hash them in the
> client anyway, as that saves you in a lot of other ways :P
OK
>
> > I'm using the binary protocol. The problem is that both md5 and sha1
> > return \n, \r and spaces in the key, which leads to this message: "Key
> > contains invalid characters". Is there any way to use a byte array as
> > key instead of a string?
>
> Are you absolutely sure? Which client is this?
I'm using the last spymemcached release 2.7.3.
This is caused by validateKey method in MemcachedClient:
for(byte b : keyBytes) {
if(b == ' ' || b == '\n' || b == '\r' || b == 0) {
throw new IllegalArgumentException("Key contains invalid
characters: ``" + key + "''");
What java client do you recommend?
>
> With the binary protocol, keys are binary blobs and it doesn't matter
> what's in them. There may be an option you have to swith off in the
> client, or the client may not actually be using binprot (run memcached
> with -vvv to see what it thinks of your connecting clients).
>
> -Dormando
I have items with 24 byte keys and 12 byte values. Hence, I was
expecting an item size around 36 bytes, rounded to a slab of 48 bytes.
The smaller slab size I get in memcached is 96 bytes, but even so the
items are been stored in 128 bytes.
What I'm doing wrong?
