Patch: CPU efficiency, UDP support, and other changes

[David Ulevitch]

Memcached is a hash table for all the pros and cons that come with  
being a hash table.

I can't imagine support for this.  Try a SQL cache or an Object  
Persistence database.

-david

On May 4, 2006, at 5:15 PM, Cahill, Earl wrote:

> 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