Thanks for your reply. Cassandra, in our case, is used for searching purposes not for data storage. We can build the cassandra keyspace data daily/weekly when system load is lower.
We have modified the cassandra code to add a value filter which makes the data-repair not working. The value filter, as I say, is to filter the columns of a key, and only the desired column is returned. The filter is done in local cassandra, not in thrift client; So we have to disable data-repair. Cassandra has met most of our needs except that: if a node fails, after a while, recovers, joins the cluster and doing hinted handoff, then a reading is forward to this node, the data returned is out of date. The node failure is not frequently; if it happens unfortunately, we should keep the reading consitency. 2010/8/18 Benjamin Black <b...@b3k.us> > On Tue, Aug 17, 2010 at 7:55 PM, Chen Xinli <chen.d...@gmail.com> wrote: > > Hi, > > > > We are going to use cassandra for searching purpose like inbox search. > > The reading qps is very high, we'd like to use ConsitencyLevel.One for > > reading and disable read-repair at the same time. > > > > In 0.7 you can set a probability for read repair, but disabling it is > a spectacularly bad idea. Any write problems on a node will result in > persistent inconsistency. > > > For reading consistency in this condition, the writing should use > > ConsistencyLevel.ALL. But the writing will fail if one node fails. > > You are free to read and write with consistency levels where R+W < N, > it just means you have weaker consistency guarantees. > > > We want such a ConsistencyLevel for writing/reading that : > > 1. writing will success if there is node alive for this key > > 2. reading will not forward to a node that's just recovered and doing > hinted > > handoff > > > > So that, if some node fails, others nodes for replica will receive the > data > > and surve reading successfully; > > when the failure node recovers, it will receive hinted handoff from > other > > nodes and it'll not surve reading until hinted handoff is done. > > > > Does cassandra support the cases already? or should I modify the code to > > meet our requirements? > > > > You are phrasing these requirements in terms of a specific > implementation. What are your actual consistency goals? If node > failure is such a common occurrence in your system, you are going to > have _numerous_ problems. > > > b > -- Best Regards, Chen Xinli
