2010-03-16

Reacting to "Memcached is not a store"

I keep seeing "Memcached is not a key value store. It is a cache. Hence the name." This is strongly reinforced by statements made in the memcached mailing list itself.

This is short sighted.

Memcached is a number of things. It is an idea (fast key value store, with distributed hash function scaling), it is a network protocol (two of them, in fact), it is a selection of client libraries and APIs (most based on libmemcached), and it is a server implementation. In fact, now, is is now a number of server implementations, because now there are a number of different things that implement the memcached protocol.

Only one of which is the open source community edition of the memcached server, version 1.4, downloadable from http://memcached.org/

Despite what you may get told, especially on the memcached mailing list, you can in fact use memcached as a store, not just as a cache.

Yes,if you fill it up, it may either error or evict something, but you have to live with if you fill up a MySQL tablespace disk, it crashes or errors on you too. Yes, it's not persistent. But, frankly, there is a lot of data that doesn't HAVE to be persistent, or at least doesn't have to persist in that format. MySQL, Postgres, Oracle, and MSSQL have temp tables and memory tables, and people are ok with that.

But it's not even "not persistent". You can get various kinds of "persistent memcached" by using Gear6 which can persist to flash, or by using Tokyo Cabinet, which has a memcached interface. There are a number of other stores that are adding memcached interfaces. I have seen people working to use libmemcached to add memcache "memcapable" interfaces to NDB cluster, to "embedded" InnoDB, and even to the filesystem. And more are coming.

I've also seen work to do crazy stuff like put a full relational SQL interface on top off of memcached, or a simple "cut down" SQL that just does primary key inserts and lookups for the "e-blob pattern", or the NDB Cluster API on top of it. It's all good.

So when someone sneers "memcache is a cache, not a store", don't be discouraged. They have reasons to say that, but IMO, they are not very good reasons.

Use it as a store, just know what it does and doesn't do. Just like when you chose any other data store.

2 comments:

  1. Right, some people are okay compromising the "C" or the "I" in ACID to gain some other advantage they need, like scalability or fast writes. But they still consider it a data store that's "eventually consistent."

    So what's wrong with compromising the "D" if you can gain something worthwhile by doing so?

    ReplyDelete
  2. Memcache is definitely more a protocol than a single product.

    If SimpleDB is persistent, and it is for sure, why wouldn't KumoFS be considered as a store, just for the sake of speaking the memcache protocol?

    ReplyDelete