Skylos skylos at gmail.com
Sun Feb 6 12:06:39 PST 2005


What if you stored a key that had a list of keys in it?

in perl, It could be something like

@newlist = qw/b c d/;
$oldkeys = $memd->get('keylist')
foreach my $oldkey (@{$oldkeys}) {
  unless (grep { $_ eq $oldkey } @newlist) {
$memd->set('keylist', \@newlist);

which will delete any keys not in the new list on the old list, then
set the keylist to your new list.  You might want to juggle timings
and locks and stuff for multiprocess things... but this is a method I
use - if I need to keep track of some set of keys that are in the
memcached, I keep track of it in a value.

The downside is that depending on how much overhead is in
storing/retrieving the list, you could blow your processor usage and
latency to hell.  (I did this with a hash during testing - arrays seem

An upside is that you can have more than just these keys in the cache
- use it for other things too, without having interference between the
code segments ennumerators...


On Sun, 6 Feb 2005 11:19:49 -0800 (PST), christopher at baus.net
<christopher at baus.net> wrote:
> I am doing something non-standard with memcached, so I am probably
> confusing the issue.  Most assume that the actual data will be stored in a
> backend database.  I assume that the canonical data will be in the cache.
>  I am using memcached to store proxy configuration information.
> So if the cache consists of
> x, y, z
> and the new set of keys consists of
> w, x, y
> I need the resulting keys in the cache to be:
> w, x, y
> The client doesn't know to delete z, because it doesn't know it is in the
> cache.  So that's why I need to hack in some sort of basic key set
> operations.  I don't want to delete all the keys and re-add them, because
> there will a significant amount of time with a limited set of keys.  I
> would rather the changes would be applied key by key.
> I looked at the code in more detail yesterday, and I think I could hack
> something like this in.  Although I don't think it would be something
> generally useful enough to make part of the distribution.
> Sincerely,
> Christopher

More information about the memcached mailing list