incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Kutcharian <d...@venarc.com>
Subject Re: Relation between Atomic Batches and Consistency Level
Date Tue, 18 Mar 2014 17:37:11 GMT
Alright, this is much better. The main thing I’m trying to figure out is that if there is
a way to stop the batch if the first statement fails or there is a better pattern/construct
for Cassandra to handle that scenario.

- Drew

On Mar 18, 2014, at 4:46 AM, Jonathan Lacefield <jlacefield@datastax.com> wrote:

> Okay your question is clear to me know.  
> 
> My understanding, after talking this through with some of the engineers here, is that
we have 2 levels of success with batches:
> 
> 1)  Did the batch make it to the batch log table? [yes or no]
>         - yes = success
>         - no = not success
> 2)  Did each statement in the batch succeed? [yes or no]
>       - yes = success
>       - no = not success
>       - the case you are interested in.
> 
> If 1 and 2 are both successful - you will receive a success message
> if 1 is successful but 2 is not successful (your case) - you will receive a message stating
the batch succeeded but not all replicas are live yet
>       - in this case, the batch will be retried by Cassandra.  This is the target scenario
for atomic batches (to take the burden off of the client app to monitor, maintain, and retry
batches)
>       - i am going to test this, was shooting for last night but didn't get to it, to
see what actually happens inside the batch
>       - you could test this scenario with a trace to see what occurs (i.e. if statement
1 fails is statement 2 tried)
> if 1 is not successful then the batch "fails"
>      - this is because it couldn't make it to the batchlog table for execution
> 
> Hope this helps.  I believe this is the best i can do for you at the moment.  
> 
> Thanks,
> 
> Jonathan Lacefield
> Solutions Architect, DataStax
> (404) 822 3487
> 
> 
> 
> 
> 
> 
> On Mon, Mar 17, 2014 at 4:05 PM, Drew Kutcharian <drew@venarc.com> wrote:
> I have read that blog post which actually was the source of the initial confusion ;)
> 
> If I write normally (no batch) at Quorum, then a hinted write wouldn’t count as a valid
write so the write wouldn’t succeed, which means I would have to retry. That’s a pretty
well defined outcome.
> 
> Now if I write a logged batch at Quorum, then a by definition, a hinted write shouldn’t
be considered a valid response, no?
> 
> - Drew
> 
> 
> On Mar 17, 2014, at 11:23 AM, Jonathan Lacefield <jlacefield@datastax.com> wrote:
> 
>> Hello,
>> 
>>   Have you seen this blog post, it's old but still relevant.  I think it will answer
your questions.  http://www.datastax.com/dev/blog/atomic-batches-in-cassandra-1-2.
>> 
>>   I think the answer lies in how Cassandra defines a batch "In the context of a Cassandra
batch operation, atomic means that if any of the batch succeeds, all of it will."
>> 
>>   My understanding is that in your scenario if either statement succeeded, you batch
would succeed.  So #1 would get "hinted" and #2 would be applied, assuming no other failure
events occur, like the coordinator fails, the client fails, etc.
>> 
>>   Hope that helps.
>> 
>> Thanks,
>> 
>> Jonathan
>> 
>> Jonathan Lacefield
>> Solutions Architect, DataStax
>> (404) 822 3487
>> 
>> 
>> 
>> 
>> 
>> 
>> On Mon, Mar 17, 2014 at 1:38 PM, Drew Kutcharian <drew@venarc.com> wrote:
>> Hi Jonathan,
>> 
>> I’m still a bit unclear on this. Say I have two CQL3 tables:
>> - user (replication of 3)
>> - user_email_index (replication of 3)
>> 
>> Now I create a new logged batch at quorum consistency level and put two inserts in
there:
>> #1 Insert into the “user" table with partition key of a timeuuid of the user 
>> #2 Insert into the “user_email_index" with partition key of user’s email address

>> 
>> As you can see, there is a chance that these two insert statements will be executed
on two different nodes because they are keyed by different partition keys. So based on the
docs for Logged Batches, a batch will be applied “eventually” in an "all or nothing”
fashion. So my question is, what happens if insert #1 fails (say replicas are unavailable),
would insert #2 get applied? Would the whole thing be rejected and return an error to the
client? 
>> 
>> PS. I’m aware of the isolation guarantees and that’s not an issue. All I need
to make sure is that if the first the statement failed, the whole batch needs to fail.
>> 
>> Thanks,
>> 
>> Drew
>> 
>> On Mar 17, 2014, at 5:33 AM, Jonathan Lacefield <jlacefield@datastax.com> wrote:
>> 
>>> Hello,
>>> 
>>>   Consistency is declared at the statement level, i.e. batch level when writing,
but enforced at each batch row level.  My understanding is that each batch (and all of it's
contents) will be controlled through a specific CL declaration.  So batch A could use a CL
of QUORUM while batch B could use a CL of ONE.   
>>> 
>>>   The detail that may help sort this out for you is that batch statements do
not provide isolation guarantees: www.datastax.com/documentation/cql/3.0/cql/cql_reference/batch_r.html.
 This means that you write the batch as a batch but the reads are per row.  If you are reading
records contained in the batch, you will read results of partially updated batches.  Taking
this into account for your second question, you should expect that your read CL will preform
as it would for any individual row mutation. 
>>> 
>>>   Hope this helps.
>>> 
>>> Jonathan
>>> 
>>> Jonathan Lacefield
>>> Solutions Architect, DataStax
>>> (404) 822 3487
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Sat, Mar 15, 2014 at 12:23 PM, Drew Kutcharian <drew@venarc.com> wrote:
>>> Hi Guys,
>>> 
>>> How do Atomic Batches and Consistency Level relate to each other? More specifically:
>>> 
>>> - Is consistency level set/applicable per statement in the batch or the batch
as a whole?
>>> 
>>> - Say if I write a Logged Batch at QUORUM and read it back at QUORUM, what can
I expect at normal, single node replica failure or double node replica failure scenarios?
>>> 
>>> Thanks,
>>> 
>>> Drew
>>> 
>> 
>> 
> 
> 


Mime
View raw message