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 2022/10/07 01:10:42 UTC
[GitHub] [druid] techdocsmith commented on a diff in pull request #13181: Update retention rules doc
techdocsmith commented on code in PR #13181:
URL: https://github.com/apache/druid/pull/13181#discussion_r989580458
##########
docs/operations/rule-configuration.md:
##########
@@ -23,212 +23,242 @@ title: "Retaining or automatically dropping data"
-->
-In Apache Druid, Coordinator processes use rules to determine what data should be loaded to or dropped from the cluster. Rules are used for data retention and query execution, and are set via the [web console](./web-console.md).
+In Apache Druid, [Coordinator processes](../design/coordinator.md) use rules to determine what data to retain or drop from the cluster.
-There are three types of rules, i.e., load rules, drop rules, and broadcast rules. Load rules indicate how segments should be assigned to different historical process tiers and how many replicas of a segment should exist in each tier.
-Drop rules indicate when segments should be dropped entirely from the cluster. Finally, broadcast rules indicate how segments of different datasources should be co-located in Historical processes.
+There are three types of rules: [load](#load-rules), [drop](#drop-rules), and [broadcast](#broadcast-rules). See the sections below for more information on each type.
-The Coordinator loads a set of rules from the metadata storage. Rules may be specific to a certain datasource and/or a
-default set of rules can be configured. Rules are read in order and hence the ordering of rules is important. The
-Coordinator will cycle through all used segments and match each segment with the first rule that applies. Each segment
-may only match a single rule.
+The Coordinator loads a set of rules from the metadata storage. You can configure a default set of rules to apply to all data sources, and/or you can set specific rules for specific data sources.
-Note: It is recommended that the web console is used to configure rules. However, the Coordinator process does have HTTP endpoints to programmatically configure rules.
+## Set a rule
+
+To set a default retention rule for all data sources, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/_default`
+
+To set a retention rule for a specific data source, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/{dataSourceName}`
+
+The rules API accepts a list of rules. The payload you send in the API request for each rule is specific to the rules types outlined below.
+
+You can also set rules using the [web console](./web-console.md). Go into a data source and select **Actions** > **Edit retention rules**.
+
+### Rule order
+
+The order of rules is important. The Coordinator reads rules in the order in which they appear in the rules list. For example, in the following screenshot the Coordinator evaluates data against rule 1, then rule 2, then rule 3:
+
+
+
+In the web console you can use the up and down arrows on the right side of the interface to change the order of the rules.
+
+The Coordinator cycles through all used segments and matches each segment with the first rule that applies. Each segment can only match a single rule.
## Load rules
-Load rules indicate how many replicas of a segment should exist in a server tier. **Please note**: If a Load rule is used to retain only data from a certain interval or period, it must be accompanied by a Drop rule. If a Drop rule is not included, data not within the specified interval or period will be retained by the default rule (loadForever).
+Load rules define how Druid assigns segments to historical process tiers, and how many replicas of a segment exist in each tier.
+
+If you want to use a load rule to retain only data from a defined period of time, you must also define a drop rule. If you don't define a drop rule, Druid retains data that doesn't lie within your defined period according to the default rule, `loadForever`.
-### Forever Load Rule
+### Forever load rule
-Forever load rules are of the form:
+Forever load rules have type `loadForever` and the following example API payload:
```json
{
- "type" : "loadForever",
+ "type": "loadForever",
"tieredReplicants": {
"hot": 1,
- "_default_tier" : 1
+ "_default_tier": 1
}
}
```
+Set the following property:
+- `tieredReplicants`: a JSON object containing tier names and the number of replicas for each tier.
-* `type` - this should always be "loadForever"
-* `tieredReplicants` - A JSON Object where the keys are the tier names and values are the number of replicas for that tier.
+The forever load rule is the default rule Druid applies to data sources.
+### Interval load rule
-### Interval Load Rule
+Interval load rules have type `loadByInterval` and the following example API payload:
-Interval load rules are of the form:
```json
{
- "type" : "loadByInterval",
+ "type": "loadByInterval",
"interval": "2012-01-01/2013-01-01",
"tieredReplicants": {
"hot": 1,
- "_default_tier" : 1
+ "_default_tier": 1
}
}
```
-* `type` - this should always be "loadByInterval"
-* `interval` - A JSON Object representing ISO-8601 Intervals
-* `tieredReplicants` - A JSON Object where the keys are the tier names and values are the number of replicas for that tier.
+Set the following properties:
+- `interval`: a JSON object representing [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) intervals.
Review Comment:
this looks to be a string and not a JSON object
##########
docs/operations/rule-configuration.md:
##########
@@ -23,212 +23,242 @@ title: "Retaining or automatically dropping data"
-->
-In Apache Druid, Coordinator processes use rules to determine what data should be loaded to or dropped from the cluster. Rules are used for data retention and query execution, and are set via the [web console](./web-console.md).
+In Apache Druid, [Coordinator processes](../design/coordinator.md) use rules to determine what data to retain or drop from the cluster.
-There are three types of rules, i.e., load rules, drop rules, and broadcast rules. Load rules indicate how segments should be assigned to different historical process tiers and how many replicas of a segment should exist in each tier.
-Drop rules indicate when segments should be dropped entirely from the cluster. Finally, broadcast rules indicate how segments of different datasources should be co-located in Historical processes.
+There are three types of rules: [load](#load-rules), [drop](#drop-rules), and [broadcast](#broadcast-rules). See the sections below for more information on each type.
-The Coordinator loads a set of rules from the metadata storage. Rules may be specific to a certain datasource and/or a
-default set of rules can be configured. Rules are read in order and hence the ordering of rules is important. The
-Coordinator will cycle through all used segments and match each segment with the first rule that applies. Each segment
-may only match a single rule.
+The Coordinator loads a set of rules from the metadata storage. You can configure a default set of rules to apply to all data sources, and/or you can set specific rules for specific data sources.
Review Comment:
Maybe a link? See #rule-order to see how rule order impacts the way the Coordinator handles load rules.
##########
docs/operations/rule-configuration.md:
##########
@@ -23,212 +23,242 @@ title: "Retaining or automatically dropping data"
-->
-In Apache Druid, Coordinator processes use rules to determine what data should be loaded to or dropped from the cluster. Rules are used for data retention and query execution, and are set via the [web console](./web-console.md).
+In Apache Druid, [Coordinator processes](../design/coordinator.md) use rules to determine what data to retain or drop from the cluster.
-There are three types of rules, i.e., load rules, drop rules, and broadcast rules. Load rules indicate how segments should be assigned to different historical process tiers and how many replicas of a segment should exist in each tier.
-Drop rules indicate when segments should be dropped entirely from the cluster. Finally, broadcast rules indicate how segments of different datasources should be co-located in Historical processes.
+There are three types of rules: [load](#load-rules), [drop](#drop-rules), and [broadcast](#broadcast-rules). See the sections below for more information on each type.
-The Coordinator loads a set of rules from the metadata storage. Rules may be specific to a certain datasource and/or a
-default set of rules can be configured. Rules are read in order and hence the ordering of rules is important. The
-Coordinator will cycle through all used segments and match each segment with the first rule that applies. Each segment
-may only match a single rule.
+The Coordinator loads a set of rules from the metadata storage. You can configure a default set of rules to apply to all data sources, and/or you can set specific rules for specific data sources.
-Note: It is recommended that the web console is used to configure rules. However, the Coordinator process does have HTTP endpoints to programmatically configure rules.
+## Set a rule
+
+To set a default retention rule for all data sources, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/_default`
+
+To set a retention rule for a specific data source, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/{dataSourceName}`
+
+The rules API accepts a list of rules. The payload you send in the API request for each rule is specific to the rules types outlined below.
Review Comment:
```suggestion
The rules API accepts an array of rules. The payload you send in the API request for each rule is specific to the rules types outlined below.
```
##########
docs/operations/rule-configuration.md:
##########
@@ -23,212 +23,242 @@ title: "Retaining or automatically dropping data"
-->
-In Apache Druid, Coordinator processes use rules to determine what data should be loaded to or dropped from the cluster. Rules are used for data retention and query execution, and are set via the [web console](./web-console.md).
+In Apache Druid, [Coordinator processes](../design/coordinator.md) use rules to determine what data to retain or drop from the cluster.
-There are three types of rules, i.e., load rules, drop rules, and broadcast rules. Load rules indicate how segments should be assigned to different historical process tiers and how many replicas of a segment should exist in each tier.
-Drop rules indicate when segments should be dropped entirely from the cluster. Finally, broadcast rules indicate how segments of different datasources should be co-located in Historical processes.
+There are three types of rules: [load](#load-rules), [drop](#drop-rules), and [broadcast](#broadcast-rules). See the sections below for more information on each type.
-The Coordinator loads a set of rules from the metadata storage. Rules may be specific to a certain datasource and/or a
-default set of rules can be configured. Rules are read in order and hence the ordering of rules is important. The
-Coordinator will cycle through all used segments and match each segment with the first rule that applies. Each segment
-may only match a single rule.
+The Coordinator loads a set of rules from the metadata storage. You can configure a default set of rules to apply to all data sources, and/or you can set specific rules for specific data sources.
-Note: It is recommended that the web console is used to configure rules. However, the Coordinator process does have HTTP endpoints to programmatically configure rules.
+## Set a rule
+
+To set a default retention rule for all data sources, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/_default`
+
+To set a retention rule for a specific data source, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/{dataSourceName}`
Review Comment:
we can do a for example with `wikipedia` as the {datasourcename} .
##########
docs/operations/rule-configuration.md:
##########
@@ -23,212 +23,242 @@ title: "Retaining or automatically dropping data"
-->
-In Apache Druid, Coordinator processes use rules to determine what data should be loaded to or dropped from the cluster. Rules are used for data retention and query execution, and are set via the [web console](./web-console.md).
+In Apache Druid, [Coordinator processes](../design/coordinator.md) use rules to determine what data to retain or drop from the cluster.
-There are three types of rules, i.e., load rules, drop rules, and broadcast rules. Load rules indicate how segments should be assigned to different historical process tiers and how many replicas of a segment should exist in each tier.
-Drop rules indicate when segments should be dropped entirely from the cluster. Finally, broadcast rules indicate how segments of different datasources should be co-located in Historical processes.
+There are three types of rules: [load](#load-rules), [drop](#drop-rules), and [broadcast](#broadcast-rules). See the sections below for more information on each type.
-The Coordinator loads a set of rules from the metadata storage. Rules may be specific to a certain datasource and/or a
-default set of rules can be configured. Rules are read in order and hence the ordering of rules is important. The
-Coordinator will cycle through all used segments and match each segment with the first rule that applies. Each segment
-may only match a single rule.
+The Coordinator loads a set of rules from the metadata storage. You can configure a default set of rules to apply to all data sources, and/or you can set specific rules for specific data sources.
-Note: It is recommended that the web console is used to configure rules. However, the Coordinator process does have HTTP endpoints to programmatically configure rules.
+## Set a rule
+
+To set a default retention rule for all data sources, send a POST request to the following API:
Review Comment:
This isn't really enough information to do this task. Recommend researching a workable example on wikipedia data set and including the full request. For example something like this:
```
curl --location --request POST 'http://localhost:8888/druid/coordinator/v1/rules/_default' \
--header 'Content-Type: application/json' \
--data-raw '[{
"type": "broadcastForever"
}]'
```
we probably don't want to use that specific one, though b/c it overwrites what's there.
Also from my meager tests, it seems to take an array of rules as JSON objects. not just a single json object.
i think you may need to pass the whole list of rules every time. I don't see any other way to control the order.
##########
docs/operations/rule-configuration.md:
##########
@@ -23,212 +23,242 @@ title: "Retaining or automatically dropping data"
-->
-In Apache Druid, Coordinator processes use rules to determine what data should be loaded to or dropped from the cluster. Rules are used for data retention and query execution, and are set via the [web console](./web-console.md).
+In Apache Druid, [Coordinator processes](../design/coordinator.md) use rules to determine what data to retain or drop from the cluster.
Review Comment:
Not sure the Coordinator is the most critical information here.
What about:
You can use rules to configure Apache Druid to retain and and automatically drop data from the cluster. The [Coordinator service](../design/coordinator.md) manages and executes (?) the load rules.
##########
docs/operations/rule-configuration.md:
##########
@@ -23,212 +23,242 @@ title: "Retaining or automatically dropping data"
-->
-In Apache Druid, Coordinator processes use rules to determine what data should be loaded to or dropped from the cluster. Rules are used for data retention and query execution, and are set via the [web console](./web-console.md).
+In Apache Druid, [Coordinator processes](../design/coordinator.md) use rules to determine what data to retain or drop from the cluster.
-There are three types of rules, i.e., load rules, drop rules, and broadcast rules. Load rules indicate how segments should be assigned to different historical process tiers and how many replicas of a segment should exist in each tier.
-Drop rules indicate when segments should be dropped entirely from the cluster. Finally, broadcast rules indicate how segments of different datasources should be co-located in Historical processes.
+There are three types of rules: [load](#load-rules), [drop](#drop-rules), and [broadcast](#broadcast-rules). See the sections below for more information on each type.
-The Coordinator loads a set of rules from the metadata storage. Rules may be specific to a certain datasource and/or a
-default set of rules can be configured. Rules are read in order and hence the ordering of rules is important. The
-Coordinator will cycle through all used segments and match each segment with the first rule that applies. Each segment
-may only match a single rule.
+The Coordinator loads a set of rules from the metadata storage. You can configure a default set of rules to apply to all data sources, and/or you can set specific rules for specific data sources.
-Note: It is recommended that the web console is used to configure rules. However, the Coordinator process does have HTTP endpoints to programmatically configure rules.
+## Set a rule
+
+To set a default retention rule for all data sources, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/_default`
+
+To set a retention rule for a specific data source, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/{dataSourceName}`
+
+The rules API accepts a list of rules. The payload you send in the API request for each rule is specific to the rules types outlined below.
+
+You can also set rules using the [web console](./web-console.md). Go into a data source and select **Actions** > **Edit retention rules**.
Review Comment:
Consider leading with the UI example, then moving to API
##########
docs/operations/rule-configuration.md:
##########
@@ -23,212 +23,242 @@ title: "Retaining or automatically dropping data"
-->
-In Apache Druid, Coordinator processes use rules to determine what data should be loaded to or dropped from the cluster. Rules are used for data retention and query execution, and are set via the [web console](./web-console.md).
+In Apache Druid, [Coordinator processes](../design/coordinator.md) use rules to determine what data to retain or drop from the cluster.
-There are three types of rules, i.e., load rules, drop rules, and broadcast rules. Load rules indicate how segments should be assigned to different historical process tiers and how many replicas of a segment should exist in each tier.
-Drop rules indicate when segments should be dropped entirely from the cluster. Finally, broadcast rules indicate how segments of different datasources should be co-located in Historical processes.
+There are three types of rules: [load](#load-rules), [drop](#drop-rules), and [broadcast](#broadcast-rules). See the sections below for more information on each type.
-The Coordinator loads a set of rules from the metadata storage. Rules may be specific to a certain datasource and/or a
-default set of rules can be configured. Rules are read in order and hence the ordering of rules is important. The
-Coordinator will cycle through all used segments and match each segment with the first rule that applies. Each segment
-may only match a single rule.
+The Coordinator loads a set of rules from the metadata storage. You can configure a default set of rules to apply to all data sources, and/or you can set specific rules for specific data sources.
-Note: It is recommended that the web console is used to configure rules. However, the Coordinator process does have HTTP endpoints to programmatically configure rules.
+## Set a rule
+
+To set a default retention rule for all data sources, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/_default`
+
+To set a retention rule for a specific data source, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/{dataSourceName}`
+
+The rules API accepts a list of rules. The payload you send in the API request for each rule is specific to the rules types outlined below.
+
+You can also set rules using the [web console](./web-console.md). Go into a data source and select **Actions** > **Edit retention rules**.
+
+### Rule order
+
+The order of rules is important. The Coordinator reads rules in the order in which they appear in the rules list. For example, in the following screenshot the Coordinator evaluates data against rule 1, then rule 2, then rule 3:
+
+
+
+In the web console you can use the up and down arrows on the right side of the interface to change the order of the rules.
+
+The Coordinator cycles through all used segments and matches each segment with the first rule that applies. Each segment can only match a single rule.
## Load rules
-Load rules indicate how many replicas of a segment should exist in a server tier. **Please note**: If a Load rule is used to retain only data from a certain interval or period, it must be accompanied by a Drop rule. If a Drop rule is not included, data not within the specified interval or period will be retained by the default rule (loadForever).
+Load rules define how Druid assigns segments to historical process tiers, and how many replicas of a segment exist in each tier.
+
+If you want to use a load rule to retain only data from a defined period of time, you must also define a drop rule. If you don't define a drop rule, Druid retains data that doesn't lie within your defined period according to the default rule, `loadForever`.
-### Forever Load Rule
+### Forever load rule
-Forever load rules are of the form:
+Forever load rules have type `loadForever` and the following example API payload:
```json
{
- "type" : "loadForever",
+ "type": "loadForever",
"tieredReplicants": {
"hot": 1,
- "_default_tier" : 1
+ "_default_tier": 1
}
}
```
+Set the following property:
+- `tieredReplicants`: a JSON object containing tier names and the number of replicas for each tier.
-* `type` - this should always be "loadForever"
-* `tieredReplicants` - A JSON Object where the keys are the tier names and values are the number of replicas for that tier.
+The forever load rule is the default rule Druid applies to data sources.
+### Interval load rule
-### Interval Load Rule
+Interval load rules have type `loadByInterval` and the following example API payload:
-Interval load rules are of the form:
```json
{
- "type" : "loadByInterval",
+ "type": "loadByInterval",
"interval": "2012-01-01/2013-01-01",
"tieredReplicants": {
"hot": 1,
- "_default_tier" : 1
+ "_default_tier": 1
}
}
```
-* `type` - this should always be "loadByInterval"
-* `interval` - A JSON Object representing ISO-8601 Intervals
-* `tieredReplicants` - A JSON Object where the keys are the tier names and values are the number of replicas for that tier.
+Set the following properties:
+- `interval`: a JSON object representing [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) intervals.
+- `tieredReplicants`: a JSON object containing tier names and the number of replicas for each tier.
-### Period Load Rule
+### Period load rule
-Period load rules are of the form:
+Period load rules have type `loadByPeriod` and the following example API payload:
```json
{
- "type" : "loadByPeriod",
- "period" : "P1M",
- "includeFuture" : true,
+ "type": "loadByPeriod",
+ "period": "P1M",
+ "includeFuture": true,
"tieredReplicants": {
"hot": 1,
- "_default_tier" : 1
+ "_default_tier": 1
}
}
```
-* `type` - this should always be "loadByPeriod"
-* `period` - A JSON Object representing ISO-8601 Periods
-* `includeFuture` - A JSON Boolean indicating whether the load period should include the future. This property is optional, Default is true.
-* `tieredReplicants` - A JSON Object where the keys are the tier names and values are the number of replicas for that tier.
+Set the following properties:
+- `period`: a JSON object representing [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) periods. The period is from some time in the past to the future or to the current time, depending on the `includeFuture` flag.
+- `includeFuture`: a boolean flag to indicate whether the load period includes the future. Defaults to `true`.
+- `tieredReplicants`: a JSON object containing tier names and the number of replicas for each tier.
-The interval of a segment will be compared against the specified period. The period is from some time in the past to the future or to the current time, which depends on `includeFuture` is true or false. The rule matches if the period *overlaps* the interval.
+Druid compares a segment's interval to the period you specify in the rule. The rule matches if the period overlaps the segment interval.
-## Drop Rules
+## Drop rules
-Drop rules indicate when segments should be dropped from the cluster.
+Drop rules define when Druid drops segments from the cluster.
-### Forever Drop Rule
+### Forever drop rule
-Forever drop rules are of the form:
+Forever drop rules have type `dropForever`:
```json
{
- "type" : "dropForever"
+ "type": "dropForever"
}
```
-* `type` - this should always be "dropForever"
+Druid drops all segments with this rule from the cluster.
-All segments that match this rule are dropped from the cluster.
+### Interval drop rule
-
-### Interval Drop Rule
-
-Interval drop rules are of the form:
+Interval drop rules have type `dropByInterval` and the following example API payload:
```json
{
- "type" : "dropByInterval",
- "interval" : "2012-01-01/2013-01-01"
+ "type": "dropByInterval",
+ "interval": "2012-01-01/2013-01-01"
}
```
-* `type` - this should always be "dropByInterval"
-* `interval` - A JSON Object representing ISO-8601 Periods
+Set the following property:
+- `interval`: a JSON object representing [ISO-8601](https://en.wikipedia.org/wiki/ISO_8601) intervals.
Review Comment:
this looks like a string and not a JSON object
##########
docs/operations/rule-configuration.md:
##########
@@ -23,212 +23,242 @@ title: "Retaining or automatically dropping data"
-->
-In Apache Druid, Coordinator processes use rules to determine what data should be loaded to or dropped from the cluster. Rules are used for data retention and query execution, and are set via the [web console](./web-console.md).
+In Apache Druid, [Coordinator processes](../design/coordinator.md) use rules to determine what data to retain or drop from the cluster.
-There are three types of rules, i.e., load rules, drop rules, and broadcast rules. Load rules indicate how segments should be assigned to different historical process tiers and how many replicas of a segment should exist in each tier.
-Drop rules indicate when segments should be dropped entirely from the cluster. Finally, broadcast rules indicate how segments of different datasources should be co-located in Historical processes.
+There are three types of rules: [load](#load-rules), [drop](#drop-rules), and [broadcast](#broadcast-rules). See the sections below for more information on each type.
Review Comment:
```suggestion
Druid supports the following types of rules:
- [Load](#load-rules) to define tiers
- [Drop](#drop-rules) to drop segments from the cluster
- [Broadcast](#broadcast-rules) to load segments on all brokers, historicals, and indexers in the cluster
```
suggest reformatting for better legibility. avoid locative language above/below
##########
docs/operations/rule-configuration.md:
##########
@@ -23,212 +23,242 @@ title: "Retaining or automatically dropping data"
-->
-In Apache Druid, Coordinator processes use rules to determine what data should be loaded to or dropped from the cluster. Rules are used for data retention and query execution, and are set via the [web console](./web-console.md).
+In Apache Druid, [Coordinator processes](../design/coordinator.md) use rules to determine what data to retain or drop from the cluster.
-There are three types of rules, i.e., load rules, drop rules, and broadcast rules. Load rules indicate how segments should be assigned to different historical process tiers and how many replicas of a segment should exist in each tier.
-Drop rules indicate when segments should be dropped entirely from the cluster. Finally, broadcast rules indicate how segments of different datasources should be co-located in Historical processes.
+There are three types of rules: [load](#load-rules), [drop](#drop-rules), and [broadcast](#broadcast-rules). See the sections below for more information on each type.
-The Coordinator loads a set of rules from the metadata storage. Rules may be specific to a certain datasource and/or a
-default set of rules can be configured. Rules are read in order and hence the ordering of rules is important. The
-Coordinator will cycle through all used segments and match each segment with the first rule that applies. Each segment
-may only match a single rule.
+The Coordinator loads a set of rules from the metadata storage. You can configure a default set of rules to apply to all data sources, and/or you can set specific rules for specific data sources.
-Note: It is recommended that the web console is used to configure rules. However, the Coordinator process does have HTTP endpoints to programmatically configure rules.
+## Set a rule
+
+To set a default retention rule for all data sources, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/_default`
+
+To set a retention rule for a specific data source, send a POST request to the following API:
+
+`/druid/coordinator/v1/rules/{dataSourceName}`
+
+The rules API accepts a list of rules. The payload you send in the API request for each rule is specific to the rules types outlined below.
+
+You can also set rules using the [web console](./web-console.md). Go into a data source and select **Actions** > **Edit retention rules**.
+
+### Rule order
+
+The order of rules is important. The Coordinator reads rules in the order in which they appear in the rules list. For example, in the following screenshot the Coordinator evaluates data against rule 1, then rule 2, then rule 3:
+
+
+
+In the web console you can use the up and down arrows on the right side of the interface to change the order of the rules.
+
+The Coordinator cycles through all used segments and matches each segment with the first rule that applies. Each segment can only match a single rule.
Review Comment:
in keeping with using API examples, you may want to include how to list rules:
```
curl --location --request GET 'http://localhost:8888/druid/coordinator/v1/rules'
```
--
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: commits-unsubscribe@druid.apache.org
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