tag proposal

[Dustin Sallings]

On Oct 4, 2007, at 8:24 , Brian Aker wrote:

> It would be nice to do three additional things with tags:
>
> 1) Get a list of all active keys associated with a tag (even if it  
> is lossy). Two optimizations would be:
>      * Give me the count of objects within this tag
>      * For a read, take a snapshot version of the list to have read  
> consistency (aka take an MVCC approach)

	Tags aren't intended to be an index, just a mass invalidation  
mechanism.  It's *possible* to use them as an index, but not in any  
cheap way.

	Without indexing, you'd have to scan all of the stored items and for  
each one scan your tags and see if there is a match.  Without major  
changes to memcached, I don't see how you could do that without  
having the server hang.

	If something like that did exist, people would just start tagging  
thing with ``all'' and using it for a key dump.  If a key dump  
couldn't exist before, I think it'd be even less likely with tags.

> 2) Allow the "set" of an object with its tag name. This will solve  
> the problem of creating an object and then tagging the object.

	I don't see how there could be a problem here at all.  It's almost  
the same amount of information over the wire, but with two commands,  
you don't clutter up existing concepts.

	When we were originally covering tags  (in the first binary protocol  
discussion), I suggested leaving room for tags in set.  Brad  
disagreed and said small, orthogonal commands are much better.  I  
agree with his disagreement.

	If you can prove that setandtag is *considerably* cheaper than set 
+tag, then it could possibly be added as an extension.

> 3) Clear an object from a tag.

	You mean untagging an object?  It's not clear to me how that would  
ever be used.  I imagine people will be setting and tagging around  
the same time, and would never want to go back and say, ``no, that  
really *isn't* dependent on this information.''

	How would you imagine this being used?

> 4) Option to invalidate a tag, and blow away all keys associated  
> with it (think of it as a mini-operation to save on round trips)

	That's the purpose of invalidate_tag, however, it needs to execute  
in constant time.

>> 	[It's unclear whether it's worth the effort to ever release a tag  
>> once it's been added.  If we assume that tags live forever, we  
>> don't have to refcount them and a few things get easier.  Any  
>> opinions?]
>
> If you invalidate a tag, the tag should go away.

	OK, it's clear now.  :)

-- 
Dustin Sallings


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20071004/e89fde8e/attachment.htm