This message was deleted.

Overwhelmed? how? Is there an error? Where do you see the bottleneck? How many segments are you dealing with ? min/avg/max size? You can pre-load segments into a historical and it will announce what it has. But the coordinator is still calling the shots about which segments should be where, so it might be difficult to override that. There are a few parameters that control the speed of balancing and replication. On Historicals: •

druid.segmentCache.numLoadingThreads

- controls the size of the thread pool used for downloading segments from Deep Storage. On Coordinator: •

druid.coordinator.loadqueuepeon.type

=

http

(this is the new default over zookeeper based curator method.) Coordinator dynamic config: •

maxSegmentsToMove

- defaults to 5, in larger clusters 100-200 is normal. When historicals are added, segments need to move around historicals, this controls the number of segments moved per coordination cycle (1 minute bey default). •

replicationThrottleLimit

- defaults to 10, this controls the rate at which segments are replicated per cycle. Like above, 10 is quite small for larger clusters.

thanks for the reply. we ended up updating the parameters you listed above from other tips we found, wiped the historicals and let the coordinator do all the work. after about 15 hours we had all segments online and much less problems. one last question, do replicas improve query performance when people are querying the same interval ?

Yes. All replicas of a segment are fair game for the brokers to use, so when concurrency on the same data grows, having more historicals able to answer queries on that data helps a lot.

excellent! thanks