Patch: CPU efficiency, UDP support, and other changes

[Paul T]

Memcached is (a bit) more than 'just' a hash table.

For example - memcached has 'increment' / 'decrement'.

Now if only memcached would get built-in append(key,
string) (which would *append* the string to current
value of the key - kind of similiar to increment only
for strings) so - if memcahed would get a built-in
'append' then it would be easy to implement the
desired cascading functionality as an external layer,
using  mamecached *itself* for storing the list of
dependencies.

The pseudocode will be something like this:

CascacdingPut( key, value, logical_group ) {
   m->set( key, value );
   m->append( "_group:" + logical_group, key ); 
}

CascadingDropGroup( logical_group ) {

   $list_of_keys_as_string 
        = m->get( "_group:" + logical_group );

   @list_of_keys = split $list_of_keys_as_string;

   foreach key in @list_of_keys {
        m->delete( key );
   }

   m->delete( "_group:" + logical_group );
}

I would vote for adding 'append' to the core - keeps
the architecture consistent yet opens the door for all
those 'cascading' things (or whatever else the
application layer would demand).

Rgds.Paul.

--- David Ulevitch <davidu at everydns.net> wrote:

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


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com