Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of sandeep.tata@gmail.com
 designates 74.125.44.155 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=FDVb6wPvdPchraF/Yc41yBE012gcBuObTJ59gUSl9HVv9LP+yVgw1iUtWEfpRG0udK
         3EtCmC8Gx/REMAc3ZlPmioyycdnlhTT1XS/bAMnFWZ5xr4k79fBz8k2hdJynH+lkZrkk
         FxFa01DcyJ4qtIHq4TPPmw8Esw6NTN53qJvA4=
MIME-Version: 1.0
In-Reply-To: <e06563880904220936l651b474dp163b3877ffaa1b65@mail.gmail.com>
References: <e06563880904220854x756a9925oa0afa8c2bf581017@mail.gmail.com>
	 <a073486d0904220932rfcedad9l478d809fe9982524@mail.gmail.com>
	 <e06563880904220936l651b474dp163b3877ffaa1b65@mail.gmail.com>
Date: Wed, 22 Apr 2009 10:08:54 -0700
Message-ID: <a073486d0904221008q73022da2kb427bc8d18a32304@mail.gmail.com>
Subject: Re: Row vs CF
From: Sandeep Tata <sandeep.tata@gmail.com>
To: cassandra-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, each CF has its own memtable. The writes are atomic in the sense
that I can still do an all-or-nothing write to multiple CFs (the
CommitLog still logs the whole row). Having multiple CFs with their
own memtable simply means that concurrent operations may not be
*isolated* from each other. So, if I have 2 operations:

Op1: Write(key1, CF1:col1=3Dnew, CF2:col2=3Dnew)
Op2: Read(key1, CF1:col1, CF2:col2)

Assuming both columns had "old" as the previous value, based on the
exec schedule Op2 could return one of:

old, old  <-- Op2 before Op1
old, new <-- Op1 writes CF2, then Op2 gets scheduled
new, old <-- Op1 writes CF1, then Op2 gets scheduled
new, new <-- Op1 before Op2

But with time (eventually), re-execution of Op2 will always return the
last result.

I agree that this is of limited value right now, but atomicity without
isolation can still be useful. It'll save the app some cleanup and
book-keeping code.


On Wed, Apr 22, 2009 at 9:36 AM, Jonathan Ellis <jbellis@gmail.com> wrote:
> On Wed, Apr 22, 2009 at 11:32 AM, Sandeep Tata <sandeep.tata@gmail.com> w=
rote:
>> Having multiple CFs in a row could be useful for writes. Consider the
>> case when you use one CF to store the data and another to store some
>> kind of secondary index on that data. It will be useful to apply
>> updates to both families atomically.
>
> Except that's not how it works, each Memtable (CF) has its own
> executor thread so even if you put multiple CFs in a Row it's not
> going to be atomic with the current system, and it's a big enough
> change to try to add some kind of coordination there that I don't
> think it's worth it. =A0(And you have seen that I am not scared of big
> changes, so that should give you pause. :)
>
> Back to YAGNI. :) =A0Row doesn't fit in the current execution model, so
> rather than leaving it as a half-baked creation, better to excise it
> and if we ever decide to support atomic updates across CFs then that
> would be the time to add it or something like it back.
>
> -Jonathan
>