On 20 March 2012 14:55, Jonathan Ellis <jbel...@gmail.com> 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. Agreed. > * 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 vnodes. Richard.
