Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of prescod@gmail.com designates
 74.125.83.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:from:date
         :x-google-sender-auth:message-id:subject:to:content-type;
        b=KVpsyJ1jZe3fAxnVLmCGekLaDUj6YeYKslOlpBWW2k7832GZL+4BYY/7qsmF7U45AS
         Bg4FC3KHJ226Vgrp56+QW56Kn5KL0O4YWyRwwnTRfZtkZ9mEui8zIwufvuY5C9X/2oV1
         RgUUi5MHO1VseaXhxyi2x1EjAmSkmSdF7ZbSU=
MIME-Version: 1.0
Sender: prescod@gmail.com
In-Reply-To: <l2s22dabfc71004041413s9690a2bdve76ed782eddb2ecd@mail.gmail.com>
References: <l2i1cb725391004041247nde9119afieb2e954e0711dc76@mail.gmail.com>
	<l2s22dabfc71004041413s9690a2bdve76ed782eddb2ecd@mail.gmail.com>
From: Paul Prescod <paul@prescod.net>
Date: Sun, 4 Apr 2010 16:52:15 -0700
Message-ID: <u2l1cb725391004041652x6797a01dh4acac21fcf50cd51@mail.gmail.com>
Subject: Re: Memcached protocol?
To: user@cassandra.apache.org
Content-Type: text/plain; charset=UTF-8

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