incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chen Xinli <chen.d...@gmail.com>
Subject Re: cassandra for a inbox search with high reading qps
Date Wed, 18 Aug 2010 06:19:43 GMT
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.daqi@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

Mime
View raw message