Hackathon / Multidimensional keys / Wildcard deletes

[Jan Miczaika]

Hi,

cleanup for the tags would work in the normal memcached garbage  
collector. When a key is deleted or the memcached verifies it is  
expired, the tag->key relationship is deleted, if set. One should then  
delete the tag when no keys are present anymore. This does introduce a  
bit more code and work to the garbage collector. The reads are not slower.

Regarding the protocol: implementing tags as additional tokens would  
break the existing protocol and thus involves protocol versioning. One  
could add a statement (similar to bytes) to tell the server if and how  
many tags are to be set.

use protocol_version 0.2\r\n
set <key> <flags> <exptime> [<num_tags> <tag> [...]] <bytes> <data>\r\n
delete_by_tag <tag>\r\n

The client could do a version\r\n first to check if the server supports tags.




----- Forwarded message from dustin at spy.net -----
    Date: Sat, 7 Jul 2007 14:43:24 -0700
    From: Dustin Sallings <dustin at spy.net>
Reply-To: Dustin Sallings <dustin at spy.net>
 Subject: Re: Hackathon / Multidimensional keys / Wildcard deletes
      To: Jan Miczaika <jan at hitflip.de>
      Cc: memcached at lists.danga.com, yya at hitflip.de


	There'd be indexing overhead, but you could have an O(1)
invalidation if the tags themselves were versioned.

	Assuming the cache time is short or you're accessing these records,
cleanup should pretty much take care of itself.

	Protocol-wise, would it make sense to have the tags be additional
tokens on the mutation line?  i.e.:

	<command name> <key> <flags> <exptime> <bytes> [<tag> [...]]\r\n

On Jul 6, 2007, at 6:14, Jan Miczaika wrote:

> Hello,
>
> I saw these proposed features for the Hackathon. Unfortunately I   
> can't take in person, wrong continent for me.
>
> I would like to suggest a feature which would probably address   
> these issues well: tagging keys. Each key would have 0...n tags   
> assigned to it. Flushing keys could be done by asking memcached to   
> flush all keys with a certain tag.
>
> The usage scenario: lets say we have a DVD. We have a number of   
> keys related to this dvd, maybe recommendations, comments,   
> categorization etc. I could tag each of these keys with the id of   
> the DVD (dvd:1234). Then I would tell memcached to flush all keys   
> with the tag dvd:1234, causing the database to recalculate all data   
> relating to dvd 1234 on the next access.
>
> Zend implemented similar functionality in their new framework:
> http://framework.zend.com/manual/en/ zend.cache.theory.html#zend.cache.tags
>
> The wildcard deletes could be done this way, more efficiently than   
> looping through the whole cache to see if a regex matches.   
> Multidimensional arrays could be partially simulated by using tags.
>
> I hope someone is interested ;-)
>
> Cheers
>
> Jan
>
>
>
>
>
> -- 
> Geschäftsführer / Managing Director
> Hitflip Media Trading GmbH
> Gürzenichstr. 7, 50667 Köln
> www.hitflip.de - new: www.hitflip.co.uk
>
> Tel. +49-(0)221-272407-27
> Fax. 0221-272407-22 (that's so 1990s)
> HRB 59046, Amtsgericht Köln
>
> Geschäftsführer: Andre Alpar, Jan Miczaika, Gerald Schönbucher
>

-- 
Dustin Sallings




----- End forwarded message -----




-- 
Geschäftsführer / Managing Director
Hitflip Media Trading GmbH
Gürzenichstr. 7, 50667 Köln
www.hitflip.de - new: www.hitflip.co.uk

Tel. +49-(0)221-272407-27
Fax. 0221-272407-22 (that's so 1990s)
HRB 59046, Amtsgericht Köln

Geschäftsführer: Andre Alpar, Jan Miczaika, Gerald Schönbucher