Patch: CPU efficiency, UDP support, and other changes

[Cahill, Earl]

Well, went through this recently in the 'namespace bids' thread.  Really
I want to be able to clear a set of arbitrarily associated keys, all at
the same time.  Kind of like an on delete cascade-ish thing.

Like have any number of keys associated with a user, and then if the
user makes a change, wipe all his keys, so that the user gets fresh
stuff on his next hit.  But to be able to do it without keeping track of
all the keys associated with the user.  And to have the namespaces scale
to about the level of keys now.  Then if we have millions of users, it
just works as nicely as memcached does now.  I would envision all the
keys for a given namespace to reside on the same server, which I think
could simplify things.

Also (and please no one go nuts on me), I would like to build a
row-level query cache that could work with foreign keys, and namespaces
I think could help with that.

Earl

> -----Original Message-----
> From: Steven Grimm [mailto:sgrimm at facebook.com]
> Sent: Thursday, May 04, 2006 4:17 PM
> To: Cahill, Earl
> Cc: memcached at lists.danga.com
> Subject: Re: Patch: CPU efficiency, UDP support, and other changes
> 
> Cahill, Earl wrote:
> > Now if you could just add some real namespace support . . . .
Wouldn't
> > facebook be interested in such a thing?
> >
> Depends on what you mean by namespace support. We partition our keys
to
> different sets of servers based on prefixes (all the keys that start
> with "xyz" go to one pool of servers and all the "abc" keys go to a
> different pool) but that's purely a client-side change. The memcached
> servers have no idea what keys they're going to be asked to deal with.
> The motivation for partitioning the key space was mostly to cut down
on
> network traffic for multi-key "get" requests, though it has other
> benefits as well.
> 
> What did you have in mind that would require server support?
> 
> -Steve