> > I like this idea. It feels like a good 80/20 solution -- 80% of the > > benefits, 20% of the effort. More like 5% of the effort. I can't > > even enumerate all the places full vnode support would change, but an > > "active token range" concept would be relatively limited in scope. > > > It only addresses 1 of Sam's original 5 points, so I wouldn't call it > an "80% solution". > To support a form of DF, I think some tweaking of the replica placement could achieve this effect quite well. We could introduce a variable into replica placement, which I'm going to incorrectly call DF for the purposes of illustration. The key range for a node would be sub-divided by DF (1 by default) and this would be used to further distribution replica selection based on this "sub-partition".
Currently, the offset formula works out to be something like this: offset = replica For RandomPartitioner, DF placement might look something like: offset = replica + (token % DF) Now, I realize replica selection is actually much more complicated than this, but these formulas are for illustration purposes. Modifying replica placement & the partitioners to support this seems straightforward, but I'm unsure of what's required to get it working for ring management operations. On the surface, it does seem like this could be added without any kind of difficult migration support. Thoughts?
