I also did create a ticket https://issues.apache.org/jira/browse/CASSANDRA-3768 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 ranges. 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. Regards, </VJ> On Mon, Mar 19, 2012 at 4:45 PM, Peter Schuller <peter.schul...@infidyne.com > 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, http://worldmodscode.wordpress.com) >
