誤解してたんだけど、複数のキーで値を取得できるmget対応、server_keyの実装というあたりを読んでネームスペース的に使えるのかと思ってたけど別にそういうわけじゃないのね。memcachedそのものが対応していないのは当然なのだけど、PerlのCache::Memcached::Managedでは出来てるみたいだし、普段使ってる、同僚が書いたPecl::Memcacheのラッパーには実装されてるので、つい勘違いした。そうかそうか。

ネームスペース的な実装はやっぱり独自にやらないといけないらしい。
memcachedのFAQにはこうある。

Namespaces

memcached does not support namespaces. However, there are some options to simulate them.
Simulating Namespaces with key prefixes

If you simply want to avoid key colision between different types of data, simply prefix your key with a useful string. For example: "user_12345", "article_76890".
Deleting by Namespace

While memcached does not support any type of wildcard deleting or deletion by namespace (since there are not namespaces), there are some tricks that can be used to simulate this. They do require extra trips to the memcached servers however.

Example, in PHP, for using a namespace called foo:

$ns_key = $memcache->get("foo_namespace_key");
// if not set, initialize it
if($ns_key===false) $memcache->set("foo_namespace_key", rand(1, 10000));
// cleverly use the ns_key
$my_key = "foo_".$ns_key."_12345";
$my_val = $memcache->get($my_key);

//To clear the namespace do:
$memcache->increment("foo_namespace_key");


手元の実装もこれに習っていて要は、

  • ネームスペースもcacheとして格納し、値の取得はそのcacheを介して取得するようにする
  • ネームスペースごと削除するときには、対応する値を変更(increment)し、キャッシュを取得できないようにすることで擬似的に削除する

という実装になるらしい。なるほど。


気になる点は、

  • 取得時のmemcachedへのアクセスが倍になる
  • 格納時の容量がちょっと増える

といったところ。memcachedは高速だし、容量だってちょっとなんだから大したことではないんだけれども、実際の運用を見てみた限りでは、memcachedが混雑しているのか値が格納されているはずなのにDBにアクセスしに行く場面が頻繁に見られるので、なんとなくmemcachedへのアクセスを減らしたいかもと思ってしまう。悩ましい。