kfaraz commented on PR #13367:
URL: https://github.com/apache/druid/pull/13367#issuecomment-1315222672

   Yeah, I thought of making round-robin a balancer strategy but then decided 
against it as balancing is the one thing it would not be used for. Balancing 
with round-robin would again cause issues similar to the ones I believe 
`random` would face during assignments.
   Also, the contract for the two are fairly different. We could make them 
conform to each other, I guess.
   
   > Also, I think that if RoundRobin strategy is considered superior to Random 
principally and practically, we should probably implement that as a 
BalancerStrategy and recommend it over random too.
   
   I don't think `RandomBalancerStrategy` is ever recommended for a real use 
case. It is really a bare bones impl mostly for testing purposes and is 
effectively no-op as it always returns null for balancing, meaning "segment is 
already optimally placed".
   
   > even the round-robin allocation might create holes in servers since it 
also skips them incase a segment is already scheduled on the server.
   
   I agree, round-robin would also create holes but these would be filled in 
the next round itself. After any number of rounds, this would be expected to 
have a near uniform distribution. 
   
   `random` would do it too, if we always passed the complete list of servers 
to the strategy (rather than only eligible servers) and kept generating random 
numbers until we found an eligible server. The problem is primarily the range 
of the generated number, which keeps changing, thus defeating the 
pseudo-randomness. But given enough rounds, this too might attain a uniform 
distribution.
   
   But it would be best to validate this hypothesis 🙂. I will write out some 
simulation tests and share the results here.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to