cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B. Todd Burruss" <bburr...@real.com>
Subject Re: Secondary Index information
Date Fri, 28 Jan 2011 16:53:07 GMT
batch_mutate doesn't guarantee consistency.  each mutation in the batch 
is guaranteed to be consistent based on your CL, but if it returns an 
error it means that it couldn't complete all mutations ... but the 
converse isn't true.  it may have successfully completed some 
mutations.  if you get an error you should retry the entire batch as 
long as the operation is idempotent.

http://wiki.apache.org/cassandra/FAQ#batch_mutate_atomic


On 01/28/2011 07:12 AM, Sasha Dolgy wrote:
> Hi Victor,
>
> In my research and playing around with nosql, specifically cassandra,
> I see the true benefit in defining search requirements and then
> creating CF's and the hierarchy based on this.  So for me, I see quite
> a bit of simplicity in defining alternate CF's to allow me to
> efficiently find a specific row.  For example, I have a CF for users
> with uid as the key and some random columns like name, birthday, etc,
> etc. etc.  I have another CF for user emails where email is the key
> and the user uid the column.  I am structuring my application to
> target specific rows based on the keys ... cheating on search.
> Suppose we have different definitions of simplicity ; )
>
> With regards to your second comment, consistency, I am using Hector
> and using the Batch_Mutation to ensure my writes are consistent
>
> Of course, maybe I'm way off here and have missed the plot entirely.
>
> Just trying to understand if secondary indexes degrade the the core
> benefits of cassandra
>
> On Fri, Jan 28, 2011 at 3:43 PM, Victor Kabdebon
> <victor.kabdebon@gmail.com>  wrote:
>> Dear Sasha,
>>
>> I am currently thinking about using secondary index in the future. I have
>> seen two pros :
>> _Simplicity, it is "more simple" to query based on a second index than going
>> for a first column then a second.
>> _ "Consistency" : depending on where you store your inverted index, it may
>> be unavailable to query because of a node down, or an error allows you to
>> insert in the first column but then you crash and cannot insert into the
>> inverted your inverse information. Because of that you cannot query and you
>> have to periodically check the consistency of the data in the double column.
>> That's what I am doing right now for my applications and making it simpler
>> and more consistent would be great.
>>
>> Remember : I don't know the details of the implementation, I take this
>> principle as if it was perfectly working.
>> But I am interested in experiences.

Mime
View raw message