tag proposal

[Steven Grimm]

Tobias Lütke wrote:
> This also means that the number of tags in the system will be quite
> large. There will be one or more tags for each row in the articles
> table. I expect the amount of tags to be vastly larger then the amount
> of keys in future memcached servers.
>   

Which is why I'm kind of skeptical about the whole tags thing, honestly. 
It seems like an optimization for the rare case (invalidation) at the 
expense of the vastly more common case (getting values by ID) by virtue 
of reducing the amount of memory available for keys and values. Fewer 
items in the cache equals lower hit rate.

Obviously different applications have different usage. I can tell you 
that in our application, gets outnumber deletes by at least two orders 
of magnitude across the board, and many of our objects are so small that 
any tag would likely eat more memory than the value being cached. (Not, 
perhaps, than the object header, but certainly more than the value.)

Also, invalidating a tag means broadcasting a "delete by tag" request to 
all the memcached servers since you have no way of knowing which servers 
have objects with which tags. For large sites with lots of memcached 
servers, or even medium-sized sites using the "run a memcached instance 
on each web host" approach, that means a ton of outgoing requests, 
almost all of which are likely to not invalidate anything at all if the 
tags are relatively sparse.

Not saying the feature isn't worth adding; there are doubtless valid use 
cases for it. But whatever implementation finally arrives, IMO, 
shouldn't impose any per-object memory overhead on objects that have no 
tags at all. Or if it does, it should be surrounded by #ifdef so that 
sites that don't need it don't see their available cache memory drop 
substantially when they upgrade.

-Steve