cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Prescod <>
Subject Re: Memcached protocol?
Date Sun, 04 Apr 2010 23:52:15 GMT
On Sun, Apr 4, 2010 at 2:13 PM, Ryan Daum <> wrote:
> I'm the author/maintainer of jmemcached; I'd be willing to do this and it'd be quite
easy to do, but Cassandra is missing a number of things which would make it so we could only
support a subset of the memcache protocol.

Yes, I had presumed that I would need to give up on the various
functions that depended upon the previous value being available. The
only one of these that I use in my applications is "add", to use
Memcached as a hacky lock server. I'm willing to give that up though:
there are many other components like Zookeeper and MySQL that can do
locking. As soon as you have more than one Memcached server and a risk
of partition, you already start to run into issues with depending on
previous memcached values being "correct".

So I'd propose you implement the subset for now. I have another idea
about how to handle the longer term issue, though.

My understanding of
is that it will allow writes that are meant to be "merged" with other
writes, like appends, increments and conditional sets. If I understand
it correctly, you would register six "handlers" for increment,
decrement, append text, prepend text, set-if-nonexistent,

Vector clocks are slated to be implemented in Cassandra 0.7

In order to strictly implement Memcached behaviour (where the result
is returned immediately), you'd need to do a READ just after your
WRITE, to force the conflict engine to detect and resolve the

A configuration file would probably allow the end-user to determine
how slow/consistent this read should be:


If you use memcached's clustering technique, rather than cassandra's,
then all consistency levels would be equivalent.

If there were a race condition in a multi-node situation (two writes
before the nodes were consistent), probably both clients would have
their writes rejected. They could either continue on that basis or
retry with exponential back-off.

> ...
> that said, if people see a use case for this, I would do it.

I personally think that it would hit a nice 80/20 point, and once
vector clocks are implemented it might be easy to get to 99% memcached

 Paul Prescod

View raw message