>>> I envision vnodes as Cassandra master being a shared cache,memtables, and manager for what we today consider a Cassandra instance.
It might be kind of problematic when you are moving the nodes you want the data associated with the node to move too, otherwise it will be a pain to cleanup after that (Something like nt clean). I think a vnode should be as much isolated as possible to reduce the impact when it is moving (which will become a normal cluster operation), Just my 2 cents. Regards, </VJ> On Wed, Mar 21, 2012 at 5:41 PM, Edward Capriolo <edlinuxg...@gmail.com>wrote: > I just see vnodes as a way to make the problem smaller and by making the > problem smaller the overall system is more agile. Aka rather then 1 node > streaming 100 gb the 4 nodes stream 25gb. Moves by hand are not so bad > because the take 1/4th the time. > > The most simple vnode implementation is vmware. Just make sure that 3 vm > nodes consecutive nodes so not end up on the same host. This is wasteful > because we have 4 jvms. > > I envision vnodes as Cassandra master being a shared cache,memtables, and > manager for what we today consider a Cassandra instance. Makes it simple > to think about. > > On Wednesday, March 21, 2012, Peter Schuller <peter.schul...@infidyne.com> > wrote: > >> Software wise it is the same deal. Each node streams off only disk 4 > >> to the new node. > > > > I think an implication on software is that if you want to make > > specific selections of partitions to move, you are effectively > > incompatible with deterministically generating the mapping of > > partition to responsible node. I.e., it probably means the vnode > > information must be kept as state. It is probably difficult to > > reconcile with balancing solutions like consistent hashing/crush/etc. > > > > -- > > / Peter Schuller (@scode, http://worldmodscode.wordpress.com) > > >
