True consistancy, btw, pretty much is only possible in a transactional environment.
On Thu, Aug 2, 2012 at 12:56 AM, Jeffrey Kesselman <jef...@gmail.com> wrote: > Roshni, > > Thats not what consistancy in ACID means. Its not consistancy of reading > the ame data, its referntial integrity between related pecies of data. > > "Consistency > Data is in a consistent state when a transaction starts and when it ends. For > example, in an application that transfers funds from one account to > another, the consistency property ensures that the total value of funds in > both the accounts is the same at the start and end of each transaction. " > > http://publib.boulder.ibm.com/infocenter/cicsts/v3r2/index.jsp?topic=%2Fcom.ibm.cics.ts.productoverview.doc%2Fconcepts%2Facid.html > > A lot of people i nthe NoSql wqorld use the term "consistancy" when what > they mean is "durability." > > " Durability After a transaction successfully completes, changes to data > persist and are not undone, even in the event of a system failure. " > > Many NoSql databses (includiogn Cassandra) are eventuallydurable, in the > sense that a read immediately after a write may noit reflect that write, > but at soem l;ater point, it will. > > None p[rovide true consistancy that I am aware of. > > > > : > > On Thu, Aug 2, 2012 at 12:24 AM, Roshni Rajagopal < > roshni.rajago...@wal-mart.com> wrote: > >> Hi Ivan, >> >> Cassandra supports 'tunable consistency' . If you always read and write >> at a quorum (or local quorum for multi data center) from one , you can >> guarantee that the results will be consistent as in all the data will be >> compared and the latest will be returned, and no data will be out of date. >> This is at a loss of performance- it will be fastest to just read and write >> once rather than check a quorum of nodes. >> >> What you chose depends on what your application needs are. Is it ok if >> some users receive out of date data (it isn't earth shattering if someone >> doesn't know what you're eating right now), or is it a banking transaction >> system where all entities must be consistently updated. >> >> So designing in cassandra priortizes de-normalization. You cannot have >> referential integrity that 2 tables (col families in cassandra) are in sync >> because the database has designed it to be so using foreign keys. The >> application needs to ensure that all data in column families are accurate >> and not out of sync, because data elements may be duplicated in different >> col families. >> >> >> You cannot have 2 different entities and ensure that changes to both will >> be done and then only be visible to others. >> >> >> Regards, >> >> >> From: Jeffrey Kesselman <jef...@gmail.com<mailto:jef...@gmail.com>> >> Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" < >> user@cassandra.apache.org<mailto:user@cassandra.apache.org>> >> To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" < >> user@cassandra.apache.org<mailto:user@cassandra.apache.org>> >> Subject: Re: Does Cassandra support operations in a transaction? >> >> Short story is that few if any of the NoSql systems supprot transactions >> natively. Thats oen of the big compromises they make. What they call >> "eventual consistancy" is actually eventual Durabiltiy in ACID terms. >> >> Consistancy, as meant by the C in ACID, is not gauranteed at all. >> >> On Wed, Aug 1, 2012 at 6:21 AM, Ivan Jiang <wiwi1...@gmail.com<mailto: >> wiwi1...@gmail.com>> wrote: >> Hi, >> I am a new guy to Cassandra, I wonder if available to call Cassandra >> in one Transaction such as in Relation-DB. >> >> Thanks in advance. >> >> Best Regards, >> Ivan Jiang >> >> >> >> -- >> It's always darkest just before you are eaten by a grue. >> >> This email and any files transmitted with it are confidential and >> intended solely for the individual or entity to whom they are addressed. If >> you have received this email in error destroy it immediately. *** Walmart >> Confidential *** >> > > > > -- > It's always darkest just before you are eaten by a grue. > -- It's always darkest just before you are eaten by a grue.
