Motivation
We have high throughput and high QPM in some environments and we use query prioritization strategy to prioritize some query workloads over others. However, the query prioritization and routing strategy is currently only configurable on the Brokers/Historical servers.
Peons launch with a default server priority of 0, meaning all peon servers are eligible to serve all queries, regardless of the strategy defined on the Brokers. As a result, workload isolation doesn't apply here since real-time servers aren't segmented by priority in the same way as Historicals and Brokers.
Proposed changes
To enable priority-aware replica allocation for Peon servers, we can introduce a new supervisor spec property, serverPriorityToReplica. This allows the existing Broker-side prioritization strategy to extend naturally to Peons without additional architectural changes.
For example, serverPriorityToReplica: {"1": 2, "0": 1} will launch 2 CliPeon servers with priority 1 and 1 CliPeon server with priority 0.
In this setup:
- Tasks with
serverPriority = 1 would have higher fault tolerance and availability
- Tasks with
serverPriority = 0 would have a single replica and lower fault tolerance
This will work with the following Broker configurations and provide isolation:
druid.broker.select.tier=custom
druid.broker.select.tier.custom.priorities=[0]
or a different isolated broker that will route queries to Peons with priority 1:
druid.broker.select.tier=custom
druid.broker.select.tier.custom.priorities=[1]
Operational impact
None. By default, this property when unspecified will be null. Operators using the existing replicas configuration will continue to work as before, with all replicas assigned to the default server priority 0.
Motivation
We have high throughput and high QPM in some environments and we use query prioritization strategy to prioritize some query workloads over others. However, the query prioritization and routing strategy is currently only configurable on the Brokers/Historical servers.
Peons launch with a default server priority of 0, meaning all peon servers are eligible to serve all queries, regardless of the strategy defined on the Brokers. As a result, workload isolation doesn't apply here since real-time servers aren't segmented by priority in the same way as Historicals and Brokers.
Proposed changes
To enable priority-aware replica allocation for Peon servers, we can introduce a new supervisor spec property,
serverPriorityToReplica. This allows the existing Broker-side prioritization strategy to extend naturally to Peons without additional architectural changes.For example,
serverPriorityToReplica: {"1": 2, "0": 1}will launch 2 CliPeon servers with priority 1 and 1 CliPeon server with priority 0.In this setup:
serverPriority = 1would have higher fault tolerance and availabilityserverPriority = 0would have a single replica and lower fault toleranceThis will work with the following Broker configurations and provide isolation:
or a different isolated broker that will route queries to Peons with priority 1:
Operational impact
None. By default, this property when unspecified will be null. Operators using the existing
replicasconfiguration will continue to work as before, with all replicas assigned to the default server priority 0.