You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@druid.apache.org by GitBox <gi...@apache.org> on 2021/06/10 06:56:15 UTC

[GitHub] [druid] clintropolis commented on a change in pull request #11257: Reduce method invocation of reservoir sampling

clintropolis commented on a change in pull request #11257:
URL: https://github.com/apache/druid/pull/11257#discussion_r648885387



##########
File path: server/src/main/java/org/apache/druid/server/coordinator/duty/BalanceSegments.java
##########
@@ -180,22 +181,29 @@ private void balanceTier(
       int maxSegmentsToMove
   )
   {
+    if (maxSegmentsToMove <= 0) {
+      return new Pair<>(0, 0);
+    }
+
     final BalancerStrategy strategy = params.getBalancerStrategy();
     final int maxIterations = 2 * maxSegmentsToMove;
     final int maxToLoad = params.getCoordinatorDynamicConfig().getMaxSegmentsInNodeLoadingQueue();
     int moved = 0, unmoved = 0;
 
+    Iterator<BalancerSegmentHolder> segmetnsToMove = strategy.pickSegmentsToMove(

Review comment:
       nit: typo `segmetnsToMove` -> `segmentsToMove`

##########
File path: server/src/main/java/org/apache/druid/server/coordinator/ReservoirSegmentSampler.java
##########
@@ -31,6 +32,42 @@
 
   private static final EmittingLogger log = new EmittingLogger(ReservoirSegmentSampler.class);
 
+  static List<BalancerSegmentHolder> getRandomBalancerSegmentHolders(
+      final List<ServerHolder> serverHolders,
+      Set<String> broadcastDatasources,
+      int k

Review comment:
       does it make sense to retain the `percentOfSegmentsToConsider` functionality to allow short-circuiting iterateAllSegments across all servers? We update the docs https://github.com/apache/druid/blob/master/docs/configuration/index.md#dynamic-configuration accordingly either way

##########
File path: server/src/main/java/org/apache/druid/server/coordinator/BalancerStrategy.java
##########
@@ -71,13 +71,60 @@
    * @return {@link BalancerSegmentHolder} containing segment to move and server it currently resides on, or null if
    *         there are no segments to pick from (i. e. all provided serverHolders are empty).
    */
+  @Deprecated

Review comment:
       this doesn't really seem deprecated so much as no longer called at all, maybe we should remove it?

##########
File path: server/src/main/java/org/apache/druid/server/coordinator/ReservoirSegmentSampler.java
##########
@@ -31,6 +32,42 @@
 
   private static final EmittingLogger log = new EmittingLogger(ReservoirSegmentSampler.class);
 
+  static List<BalancerSegmentHolder> getRandomBalancerSegmentHolders(
+      final List<ServerHolder> serverHolders,
+      Set<String> broadcastDatasources,
+      int k
+  )
+  {
+    List<BalancerSegmentHolder> holders = new ArrayList<>(k);
+    int numSoFar = 0;
+
+    for (ServerHolder server : serverHolders) {
+      if (!server.getServer().getType().isSegmentReplicationTarget()) {
+        // if the server only handles broadcast segments (which don't need to be rebalanced), we have nothing to do
+        continue;
+      }
+
+      for (DataSegment segment : server.getServer().iterateAllSegments()) {
+        if (broadcastDatasources.contains(segment.getDataSource())) {
+          // we don't need to rebalance segments that were assigned via broadcast rules
+          continue;
+        }
+
+        if (numSoFar < k) {
+          holders.add(new BalancerSegmentHolder(server.getServer(), segment));
+          numSoFar++;
+          continue;
+        }
+        int randNum = ThreadLocalRandom.current().nextInt(numSoFar + 1);
+        if (randNum < k) {
+          holders.set(randNum, new BalancerSegmentHolder(server.getServer(), segment));
+        }

Review comment:
       i think it would be worth adding some code comments here to describe that this algorithm has 2 phases, where it picks the first `k` segments from the servers, in order, then iterates through the server list randomly replacing these picked segments with decreasing frequency the more segments have been iterated.
   
   Im also somewhat curious/nervous about random this pick method is compared to the previous one, though I'm not entirely sure how it would be measured.
   
   I think we should add a new coordinator dynamic config property, https://github.com/apache/druid/blob/master/server/src/main/java/org/apache/druid/server/coordinator/CoordinatorDynamicConfig.java,  to allow falling back to the old algorithm in case there are any unpredictable strange behavior caused by this new algorithm, maybe `useBatchedSegmentSampler` or .. i'm not sure, naming is hard.




-- 
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@druid.apache.org
For additional commands, e-mail: commits-help@druid.apache.org