cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan, Brent" <>
Subject Re: Cassandra client alternatives to mimic Couchbase sharding ???
Date Tue, 31 Dec 2013 15:06:25 GMT
Thanks Hannu!

I wasn’t aware of the TokenAwarePolicy and that’s exactly what I was talking about so
I’ll give that a try.  Because setting the consistency level doesn’t really work unless
I set it to ALL, but I really don’t want to pay that sort of performance penalty.  I’d
rather stick with QUORUM writes and use the TokenAwarePolicy which should avoid situations
where RowKey X can be written to replication node 1 for request 1 and then written to replication
node 2 for request 2.  This normally isn’t an issue unless the time drift across the cluster
> the time between 2 writes for the same row key.


From: Hannu Kröger <<>>
Reply-To: "<>" <<>>
Date: Tuesday, December 31, 2013 at 9:15 AM
To: "<>" <<>>
Subject: Re: Cassandra client alternatives to mimic Couchbase sharding ???


DataStax Cassandra Java Driver has the possibility to choose the coordinator node based on
the partition key (TokenAwarePolicy), however that probably does not solve the consistency
problem you are thinking about:

If you really want to have full consistency, you should read this and tune consitency level
accordingly if you haven't already:


2013/12/31 Ryan, Brent <<>>
Assuming that you have a 3 node cassandra cluster with replication factor of 3 (so all nodes
have the data)…

Does there exist a cassandra client that would allow a cassandra cluster to behave similarly
to a couchbase cluster where for a given RowKey X, the client would always communicate to
the same node in the cassandra cluster?  Essentially provides sharding at the client tier
by RowKey.  The main reason for doing this would be to avoid some of the issues you run into
with eventual consistency and allowing the cluster to resolve conflicts using server side

I’m not sure exactly if this would work like I’d want, but thought it might be an interesting
use case.  You might even be able to extend this behavior into the client further if the client
is aware of the sharding algorithm being applied to the cluster so that you always communicate
to a shard that has the data for a given row key.




View raw message