On Mon, Nov 22, 2010 at 5:48 PM, David Jeske <dav...@gmail.com> wrote: > > > On Mon, Nov 22, 2010 at 2:44 PM, David Jeske <dav...@gmail.com> wrote: >> >> On Mon, Nov 22, 2010 at 2:39 PM, Edward Capriolo <edlinuxg...@gmail.com> >> wrote: >>> >>> Return messages such as "your data was written to at least 1 node but >>> not enough to make your write-consistency count". Do not help the >>> situation. As the client that writes the data would be aware of the >>> inconsistency, but the other clients would not. Thus it only makes >>> sense to pass or fail entirely. (Thought it could be an interesting >>> error message) > > > I should have thought about that before I sent it. Let me rephrase. > Doesn't the current return message actually mean "your data was written to > between 0 and N nodes, but not enoguh to make your write-consistency count"? > > I agree with you that "your data was written to at least 1 node but not > enough to make your write consistency count" is not that useful. However, > the current "failure" seems to merge a "real failure" (i.e. your data will > never show up) with a "possible failure" (your data might show up) > Personally I'd really ilke to know if "my data was not written at all", and > that has a very different meaning than "my data was sort-of-written, but not > replicated as widely as I'd like, but it someday might be, or it someday > might not". > >
If you get an UnavailableException or a TimedOutException you client needs to retry the write. The point is Cassandra has "tunable consistency" you can say things such as: I want to write to any node and so even if all replicas for key are down so it will get there later "WRITE.ANY" or I want to write to all nodes and get an exception if it does not pass on all nodes. "WRITE.ALL" or I want to write to One node that is a replica "WRITE.ONE" or I want consistent data "Read.QUORUM + WRITE.QUORUM" Also from your comments above you are not taking into account there are two halves of the equation. Read and Write. If you mix the two levels you can solve many of those concerns. Cassandra is a distributed system. It is NOT just like hbase. If you are worried about the edge cases associated with node failures Cassandra may not be for you. See http://en.wikipedia.org/wiki/CAP_theorem. However as you pointed out in item #5 if you lose a region server you are not going to be able to read or write that data (at all) http://www.mail-archive.com/hbase-u...@hadoop.apache.org/msg09989.html This poster talks about 3-4 minutes of outage. If you want consistency like hbase you have to live with that outage.
