<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
The original message described adding dependency relationships between
arbitrary keys, though, which is not quite the same thing as namespaces.<br>
<br>
We're already doing something pretty similar to that namespace
proposal; it works just fine. I happen to think that the
namespace-based technique is the best we're going to get without
killing memcached's performance, but I'd love to be proven wrong.<br>
<br>
-Steve<br>
<br>
<br>
Paul T wrote:
<blockquote
cite="mid20061016184539.68892.qmail@web36209.mail.mud.yahoo.com"
type="cite">
<pre wrap="">The efficient implementation of 'namespaces' is
described here :
<a class="moz-txt-link-freetext" href="http://lists.danga.com/pipermail/memcached/2006-July/002551.html">http://lists.danga.com/pipermail/memcached/2006-July/002551.html</a>
No need to broadcast nothing, the expiration is
effectievly client side.
No substantial impact on performance either.
Rgds.Paul.
</pre>
<blockquote type="cite">
<pre wrap="">A key and its dependencies may be spread across
multiple servers,
memcached being a distributed system. How will a
server know when it's
safe to delete something? Bear in mind that at some
installations (ours
included, but others as well) "multiple servers"
means well in excess of
100, so "broadcast to all the other servers when
something happens" is
not an option unless you're VERY frugal in the use
of broadcasts.
What happens when a server with one of the dependent
keys crashes or its
memcached instance is restarted?
Can you set different expiration times on different
keys in a dependency
graph? What happens if the parent key's expiration
time passes and you
try to fetch a child key? (Expiration is lazy in
memcached.)
What will the performance impact be on operations
not involving key
dependencies? Busy memcached installations handle a
couple tens of
thousands of requests a second, so whatever the
implementation for this
looks like, it needs to be able to keep up with that
kind of load.
Don't get me wrong -- if what you describe can be
made to work well, it
will definitely be useful! But I suspect it'll be
trickier than it
appears to make it bulletproof.
-Steve
Martin Kihlgren wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hello list.
My name is Martin Kihlgren, and I am currently
</pre>
</blockquote>
<pre wrap="">employed by a company
</pre>
<blockquote type="cite">
<pre wrap="">that heavily relies on memcached.
We are doing lots of caching, simply.
And, unfortunately, a whole lot of invalidations.
Today we got to know of
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-freetext" href="http://search.cpan.org/dist/Cache-Memcached-Managed/lib/Cache/Memcached/Managed.pm#SYNOPSIS">http://search.cpan.org/dist/Cache-Memcached-Managed/lib/Cache/Memcached/Managed.pm#SYNOPSIS</a>
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">and I thought about the implications.
It would be so very much nicer to have this
</pre>
</blockquote>
<pre wrap="">functionality built into
</pre>
<blockquote type="cite">
<pre wrap="">memcached :O
The scheme I would imagine is:
* The addition of key dependency, in at least one
</pre>
</blockquote>
<pre wrap="">level.
</pre>
<blockquote type="cite">
<pre wrap=""> * A key can be declared depending on another
</pre>
</blockquote>
<pre wrap="">key.
</pre>
<blockquote type="cite">
<pre wrap=""> * A key can not be dropped unless all keys
</pre>
</blockquote>
<pre wrap="">depending on it are
</pre>
<blockquote type="cite">
<pre wrap=""> dropped.
* If a key having dependent keys MUST be
</pre>
</blockquote>
<pre wrap="">dropped, the whole
</pre>
<blockquote type="cite">
<pre wrap=""> set of dependent keys are dropped as well.
This would make it very easy for us to create
</pre>
</blockquote>
<pre wrap="">group keys having
</pre>
<blockquote type="cite">
<pre wrap="">dependent keys, and then just delete the group key
</pre>
</blockquote>
<pre wrap="">thus forcing all
</pre>
<blockquote type="cite">
<pre wrap="">dependent keys to be dropped.
Much simpler and more efficient than storing the
</pre>
</blockquote>
<pre wrap="">set of keys in the
</pre>
<blockquote type="cite">
<pre wrap="">group in memcache (thus having to worry about
</pre>
</blockquote>
<pre wrap="">memcache dropping the
</pre>
<blockquote type="cite">
<pre wrap="">group key before the individual keys in the group
</pre>
</blockquote>
<pre wrap="">are dropped) and
</pre>
<blockquote type="cite">
<pre wrap="">also much better than storing the group keys on
</pre>
</blockquote>
<pre wrap="">disk or in db.
</pre>
<blockquote type="cite">
<pre wrap="">Is this something you have discussed? Or is it
</pre>
</blockquote>
<pre wrap="">already in some edge
</pre>
<blockquote type="cite">
<pre wrap="">version of memcached? Or is it something that is
</pre>
</blockquote>
<pre wrap="">possible to do with
</pre>
<blockquote type="cite">
<pre wrap="">the current codebase?
regards,
//Martin Kihlgren
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
<a class="moz-txt-link-freetext" href="http://mail.yahoo.com">http://mail.yahoo.com</a>
</pre>
</blockquote>
<br>
</body>
</html>