incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Low <>
Subject Re: RFC: Cassandra Virtual Nodes
Date Tue, 20 Mar 2012 16:10:57 GMT
On 20 March 2012 14:55, Jonathan Ellis <> wrote:
> Here's how I see Sam's list:
> * Even load balancing when growing and shrinking the cluster
> Nice to have, but post-bootstrap load balancing works well in practice
> (and is improved by TRP).

Post-bootstrap load balancing without vnodes necessarily streams more
data than is necessary.  Vnodes streams the minimal amount.

In fact, post-bootstrap load balancing currently streams a constant
fraction of your data - the network traffic involved in a rebalance
increases linearly with the size of your cluster.  With vnodes it
decreases linearly.

Including removing the ops overhead of running the load balance and
calculating new tokens, this makes removing post-bootstrap load
balancing a pretty big deal.

> * Greater failure tolerance in streaming
> Directly addressed by TRP.


> * Evenly distributed impact of streaming operations
> Not a problem in practice with stream throttling.

Throttling slows them down, increasing rebuild times so increasing downtime.

> * Possibility for active load balancing
> Not really a feature of vnodes per se, but as with the other load
> balancing point, this is also improved by TRP.

Again with the caveat that more data is streamed with TRP.  Vnodes
removes the need for any load balancing with RP.

> * Distributed rebuild
> This is the 20% that TRP does not address.  Nice to have?  Yes.  Can I
> live without it?  I have so far.  Is this alone worth the complexity
> of vnodes?  No, it is not.  Especially since there are probably other
> approaches that we can take to mitigate this, one of which Rick has
> suggested in a separate sub-thread.

Distributed rebuild means you can store more data per node with the
same failure probabilities.  This is frequently a limiting factor on
how much data you can store per node, increasing cluster sizes
unnecessarily.  I'd argue that this alone is worth the complexity of


View raw message