incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vijay <>
Subject Re: RFC: Cassandra Virtual Nodes
Date Tue, 20 Mar 2012 02:37:14 GMT
I also did create a ticket with some of the
reason why I would like to see vnodes in cassandra.
It can also potentially reduce the SSTable seeks which a node has to do to
query data in SizeTireCompaction if extended to the filesystem.

But 110% agree with Peter, we need to take incremental steps and start with
the existing bootstrapping.
May be we can start it by making a set of Ranges/Token to a node insted of
one token. And then may be building things around the movement of those

I have been thinking about this for a while but having trouble to get to a
point where i am comfortable changing big chunks of code.


On Mon, Mar 19, 2012 at 4:45 PM, Peter Schuller <
> wrote:

> (I may comment on other things more later)
> > As a side note: vnodes fail to provide solutions to node-based
> limitations
> > that seem to me to cause a substantial portion of operational issues such
> > as impact of node restarts / upgrades, GC and compaction induced
> latency. I
> Actually, it does. At least assumign DF > RF (as in the original
> proposal, and mine). The impact of a node suffering from a performance
> degradation is mitigated because the effects are spread out over DF-1
> (N-1 in the original post) nodes instead of just RF nodes.
> > think some progress could be made here by allowing a "pack" of
> independent
> > Cassandra nodes to be ran on a single host; somewhat (but nowhere near
> > entirely) similar to a pre-fork model used by some UNIX-based servers.
> I have pretty significant knee-jerk negative reactions to that idea to
> be honest, even if the pack is limited to a handful of instances. In
> order for vnodes to be useful with random placement, we'd need much
> more than a handful of vnodes per node (cassandra instances in a
> "pack" in that model).
> --
> / Peter Schuller (@scode,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message