cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: Questions while evaluating Cassandra
Date Tue, 02 Mar 2010 13:44:45 GMT
On Tue, Mar 2, 2010 at 6:43 AM, Eran Kutner <> wrote:
> Is the procedure described in the description of ticket CASSANDRA-44 really
> the way to do schema changes in the latest release? I'm not sure what's your
> thoughts about this but our experience is that every release of our software
> requires schema changes because we add new column families for indexes.

Yes, that is how it is for 0.5 and 0.6.  0.7 will add online schema
changes (i.e., fix -44), Gary is working on that now.

> Any idea on the timeframe for 0.7?

We are trying for 3-4 months, i.e. roughly the same as as our last 4 releases.

> Our application needs a lot of range scans. Is there anything being done to
> improve the poor range scan performance as reflected here:
> ? is open, also for
the 0.7 release.  Johan is working on this.

> What is the reason for the replication strategy with two DCs? As far as I
> understand it means that only one replica will exist in the second DC. It
> also means that quorum reads will fail when attempted on the second DC while
> the first DC is down. Am I missing something?

 - That strategy is meant for doing reads w/ CL.ONE; it guarantees at
least one replica in each DC, for low latency with that CL
 -  Quorum is based on the whole cluster, not per-DC.
DatacenterShardStrategy will put multiple replicas in each DC, for use
with CL.DCQUORUM, that is, a majority of replicas in the same DC as
the coordinator node for the current request.  DCQOURUM is not yet
finished, though; currently it behaves the same as CL.ALL.

> Are there any plans to have a inter-cluster replication option? I mean
> having two clusters running in two DCs, each will be stand alone but they
> will replicate data between themselves.

No.  This is worse in every respect, since it means you get to
reinvent the existing repair, hinted handoff, etc code for when
replication breaks, poorly.

> This can avoid the problem mentioned
> above, as well as avoid the high cost of inter-DC traffic when doing
> Read-Repairs for every read.

Of course if you don't RR then you can read inconsistent data until
your next full repair.   Not a good trade.  Remember RR is done in the
background so the latency doesn't matter.

> From everything I've read I didn't understand if load balancing is local or
> global. In other words, what happens exactly when a new node is added? Will
> it only balance its two neighbors on the ring or will the re-balance
> propagate through the ring and all the nodes will be rebalanced evenly?

The former.  Cascading data moves around the ring is a Bad Idea.
(Since you read the Yahoo hbase/cassandra paper -- if hbase does this,
maybe that is why adding a new node basically kills their cluster for
several minutes?)

> I see that Hadoop support is coming in 0.6 but from following the ticket on
> Jira (CASSANDRA-342) I didn't understand if it will support the
> orderPreservingPartitioner or not.

It supports all partitioners.

> Do the clients have to be recompiled and deployed when a new version of
> Cassandra is deployed, or are new releases backward compatible?

The short answer is, we maintained backwards compatibility for 0.4 ->
0.5 -> 0.6, but we are going to break things in 0.7 moving from String
keys to byte[] and possibly other changes.


View raw message