caching - Memcache tags simulation -

memcached great scalable cache layer have 1 big problem (for me) it cannot manage tags. , tags useful group invalidation.

i have done research , i'm aware solutions:

• memcache tag fork http://code.google.com/p/memcached-tag/
• code implementation emulate tags (ref. best way invalidate number of memcache keys using standard php libraries?)

one of favorite solution namespace, , solution explained on memcached wiki.

however don't understand why integrate namespace on key cache?

from understood namespace trick is: generate key have value of namespace (on cache). , if namespace->value cache entry evicted, can no longer compute key fetch cache... cache namespace virtually invalidate (i said virtually because cache still exist can no more compute key access).

so why can not implement like:

tag1->[key1, key2, key5] tag2->[key1, key3, key6] key1->["value" => value1, "tags" => [tag1, tag2]] key2->["value" => value2, "tags" => [tag1]] key3->["value" => value3, "tags" => [tag3]] etc... 

with implementation come problem if tag1->[key1, key2, key5] evicted can no more invalidate tag1 key. with

function load($cacheid) {    $cache = $memcache->get($cacheid);    if (is_array($cache)) {       $evicted = false;       // check no tags have been evicted       foreach ($cache["tags"] $tagid) {          if (!$memcache->get($tagid) {             $evicted = true;             break;          }       }       // if no tags have been evicted can return cache       if (!$evicted) {          return $cache       } else {          // not mandatory          $memcache->delete($cacheid);       }       // else return false       return false;    } } 

it's pseudo code

we sure return cache if of tags available.

and first thing can it's "each time need cache have check(/get) x tags , check on array". namespace have check(/get) namespace retrieve namespace value, main diff iterate under array... not think keys have many tags (i cannot imagine more 10 tags/key application), iterate under size 10 array it's quite speed..

so question is: think implementation? , limits? did forget something? etc

or maybe have missunderstand concept of namespace...

ps: i'm not looking cache layer memcached-tag or redis

i think forgetting implementation, it's trivial fix.

consider problem of multiple keys sharing tags:

key1 -> tag1 tag2 key2 -> tag1 tag2 tag1 -> key1 key2 tag2 -> key1 key2 

say load key1. double check both tag1 , tag2 exist. fine , key loads.

then tag1 somehow evicted cache.

your code invalidates tag1. should delete key1 , key2 because tag1 has been evicted, not happen.

then add new item key3. refers tag1:

key3 -> tag1 

when saving key, tag1 (re)created:

tag1 -> key3 

later, when loading key1 cache again check in pseudo code ensure tag1 exists succeeds. , (stale) data key1 allowed loaded.

obviously way around check values of tag1 data ensure key loading listed in array , consider key valid if true.

of course have performance issues depending on use case. if given key has 10 tags, each of tags used 10k keys, having search through array of 10k items find key , repeat 10 times each time load something.

at point, may become inefficient.

an alternative implementation (and 1 use), more appropriate when have high read write ratio.

if reads common case, implement tag capability in more permanent database backend (i'll assume have db of sorts anyway needs couple tables here).

when write item in cache, store key , tag in simple table (key , tag columns, 1 row each tag on key). writing key simple: "delete cache_tags id=:key; foreach (tags tag) insert cache_tags values(:key, :tag); (nb use extended insert syntax in real impl).

when invalidating tag, iterate on keys have tag: (select key cache_tags tag=:tag;) , invalidate each of them (and optionally delete key cache_tags table tidy up).

if key evicted memcache cache_tags metadata out of date, typically harmless. @ result in inefficiency when invalidating tag attempt invalidate key had tag has been evicted.

this approach gives "free" loading (no need check tags) expensive saving (which expensive anyway otherwise wouldn't need cached in first place!).

so depending on use case , expected load patterns , usage, i'd hope either original strategy (with more stringent checks on load) or "database backed tag" strategy fit needs.

hths