cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Prescod <p...@prescod.net>
Subject Re: Memcached protocol?
Date Sun, 04 Apr 2010 23:52:15 GMT
On Sun, Apr 4, 2010 at 2:13 PM, Ryan Daum <ryan@thimbleware.com> 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 http://issues.apache.org/jira/browse/CASSANDRA-580
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,
set-if-old-value-is-the-same.

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
conflict.

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

 * http://wiki.apache.org/cassandra/API#ConsistencyLevel

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
compatibility.

 Paul Prescod

Mime
View raw message