incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre Chalamet" <pie...@chalamet.net>
Subject RE: Second Cassandra users survey
Date Mon, 07 Nov 2011 07:45:17 GMT
I do not want to use HBase because Cassandra is way far easier to deploy and
it is working pretty well - and for the 99% of our apps the model fits
perfectly. The other 1% has a workaround by ordering writes. I assume the
trade off anyway :)

Don't miss the point: I love Cassandra and the way it works, and I
understand the limitation/advantages of the architecture - I'm just saying
it could be nice to have something stronger (understand more guarantee) when
updating several columns - the pain area is with updating regular column and
counter in order to keep everything consistent for one key. Actually,
everything is under control as you say - so it's not a real problem and we
can live without.

But since this is a discussion about wishes, I'm not shy asking for the moon
:)


-----Original Message-----
From: Radim Kolar [mailto:hsn@sendmail.cz] 
Sent: Monday, November 07, 2011 8:02 AM
To: user@cassandra.apache.org
Subject: Re: Second Cassandra users survey

> Yeah, I can use HBase too.
but why you are not using hbase if its feature set fits your needs 
better and  want to have same functionality in cassandra? Its good that 
both projects are different in this area. From rest of your post it 
looks like you want to have cassandra ACID compliant, which is against 
its design ideas. If you want ACID compliant nosql engine then there are 
few others not only hbase.

> Cassandra is more like read uncommitted.
yes.
> Even if row mutations in one CF for one key are atomic on one server ,
stuff
> is not rolled back when the CL can't be satisfied at the coordinator
level.
> Data won't be visible at QUORUM level, but when using weaker CL, invalid
> data can appear imho.
Thats right. Its responsibility of application designer to code 
application in that way - use correct CL. In SQL databases its server 
responsibility to deal with inconsistent data, but in nosql its client 
responsibility. In reality its not problem because you have your 
applications under control. This problem might be worked around by 
cassandra core if additional settings are added to CF - minimum CL 
levels for read/write. Submit feature request to jira if you are 
interested in that.


Mime
View raw message