namespace bids

[Cahill, Earl]

For some time we have had the same memcached servers handling several
different nodes of information.  As we have seen memcached handle our
loads, we have cached more, and memcached has yet to miss a beat.  We
currently have millions of items cached, though, yes we could probably
expire some of those.

 

Recently we added a new 'node' of stuff, call it fred.  Well, it turns
out fred changes a bit more than the rest, and sometimes we would like
to wipe everything that has anything to do with fred.  Problem is the
key names in fred are rather dynamic, combining several types of data,
one of which is an ordered list.  That makes it kind of hard to know all
of fred's keys.  There are potentially a few hundred thousand such keys.
It also doesn't appear to be possible to walk everything currently in a
memcached instance for sufficiently large slabs.  We don't want to
restart the whole instance, as we would lose several million confs and
have to slam our netapp to rewarm the cache.  Ttls are fine, but it
would be nice to just wipe the whole node.

 

Seems like namespaces are what we want here, and I think we'd be willing
to pay for it.  As a pre-empt, the perl API does not really have name
space support.  In my reading, all it does is combine your 'namespace'
to keys, which as far as I can tell, aids little to our problem.

 

So my questions are, who can we pay to develop namespace support, and
how much would it cost?  We would want all the code contributed back to
trunk, and we would like to work off of trunk and not some branch or the
like.  We would like to be able to handle lots of namespaces, like
adding a namespace wouldn't be much more taxing than adding a normal
key.

 

Maybe just a question for brad, but if namespace support just happened,
in a good way, and all you had to was perhaps merge a few things, would
you be ok with it?

 

I think namespaces could help improve what I think is a pretty great
product.  Don't want to start a flame war, with other potential uses,
but I think there are many.

 

Thanks,

Earl 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20060201/b9209c20/attachment.html