[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for Trino](../index.md) > [Step-by-step guides](index.md) > Clusters > Managing resource groups # Managing resource groups in Managed Service for Trino In Managed Service for Trino, you can manage [resource group](../concepts/resource-groups.md) configurations, i.e.: * [Get information about the current configuration](#get). * [Set up a configuration when creating a cluster](#set-at-create). * [Set up or update a configuration for an existing cluster](#set-at-update). * [Delete a configuration](#delete). ## Getting information about a resource group configuration {#get} {% list tabs group=instructions %} - Management console {#console} 1. In the [management console](https://console.yandex.cloud), navigate to the relevant folder. 1. Navigate to **Managed Service for Trino**. 1. Click the cluster name. 1. Go to the **Resource management** section. - CLI {#cli} If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install). The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id ` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions. To get the description of resource groups and selector rules in the Managed Service for Trino cluster, run this command: ```bash yc managed-trino cluster get-resource-groups ``` You can get the cluster ID and name with the [list of clusters in the folder](cluster-list.md#list-clusters). - REST API {#api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Call the [Cluster.Get](../api-ref/Cluster/get.md) method, e.g., via the following [cURL](https://curl.se/) request: ```bash curl \ --request GET \ --header "Authorization: Bearer $IAM_TOKEN" \ --url 'https://trino.api.cloud.yandex.net/managed-trino/v1/clusters/' ``` You can get the cluster ID with the [list of clusters in the folder](#list-clusters). 1. The description of resource groups and selector rules in the Managed Service for Trino cluster is in the `resourceGroups` field of the [server response](../api-ref/Cluster/get.md#yandex.cloud.trino.v1.Cluster). - gRPC API {#grpc-api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Clone the [cloudapi](https://github.com/yandex-cloud/cloudapi) repository: ```bash cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi ``` Below, we assume that the repository contents reside in the `~/cloudapi/` directory. 1. Call the [ClusterService.Get](../api-ref/grpc/Cluster/get.md) method, e.g., via the following [gRPCurl](https://github.com/fullstorydev/grpcurl) request: ```bash grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/trino/v1/cluster_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d '{ "cluster_id": "" }' \ trino.api.cloud.yandex.net:443 \ yandex.cloud.trino.v1.ClusterService.Get ``` You can get the cluster ID with the [list of clusters in the folder](#list-clusters). 1. The description of resource groups and selector rules in the Managed Service for Trino cluster is in the `resource_groups` field of the [server response](../api-ref/grpc/Cluster/get.md#yandex.cloud.trino.v1.Cluster). {% endlist %} ## Setting up a resource group configuration when creating a cluster {#set-at-create} {% list tabs group=instructions %} - Management console {#console} 1. In the [management console](https://console.yandex.cloud), select the folder where you want to create a Managed Service for Trino cluster. 1. Navigate to **Managed Service for Trino**. 1. Click **Create cluster** and set the cluster parameters. 1. Go to the **Resource management** section. 1. In the **CPU quota period** field, set the CPU quota calculation period for resource groups. 1. Click **Add group** and set up the resource group: 1. Optionally, select a parent group. 1. Specify a name for the resource group. A group name can be a template that uses variable placeholders in `${}` format. A template name may contain the following types of variables: * Built-in variables. `USER` for username, `SOURCE` for query source. * User-defined variables. These are declared in selector rule properties: **User** and **Source**. When routing queries, Managed Service for Trino will create group instances with dynamically generated names. 1. In the **Max queued** field, set the maximum number of queries per queue (must be higher than `1`). Once this limit is reached, new queries will be rejected with an error. 1. Optionally, set a soft limit on the number of running queries in the **Soft concurrency limit** field. Once the limit is reached, the group will run new queries only if sibling groups are unable to accept queries or are above their soft limits. Otherwise, new queries will be queued. 1. In the **Hard concurrency limit** field, set the maximum number of running queries (must be higher than `1`). Once this limit is reached, new queries will be queued. 1. Optionally, set the maximum amount of memory available to the group in the **Soft memory limit, %** field. Once this limit is reached, new queries will be queued. 1. Optionally, set a soft limit on CPU time in the **Soft CPU limit** field. Once this limit is reached, the maximum number of running queries will be reduced until the end of the current CPU quota calculation period. This value cannot be greater than **Hard CPU limit**. To set **Soft CPU limit**, you also need to set **CPU quota period**. 1. Optionally, set a hard limit on CPU time in the **Hard CPU limit** field. Once this limit is reached, new queries will be queued. To set **Hard CPU limit**, you also need to set **CPU quota period**. 1. Optionally, set a [query scheduling policy](../concepts/resource-groups.md#policy) in the **Scheduling policy** field. The possible values are `fair`, `weighted`, `weighted_fair`, or `query_priority`. The default value is `none` (the `fair` policy applies). 1. Optionally, set the group weight used in the `weighted` and `weighted_fair` scheduling policies in the **Scheduling weight** field. Learn more about group trees in [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). 1. Optionally, add other resource groups in the same way. 1. Click **Add rule** and set up the rule: 1. Optionally, in the **User** field, specify the name of the user who submitted the query or a Java regular expression. The rule applies if the user name matches the regular expression. If you skip this setting, the rule applies to queries from all users. 1. Optionally, in the **Group** field, specify the name of the user group that submitted the query or a Java regular expression. The rule applies if the user group name matches the regular expression. If not specified, the rule applies to queries from users of any groups. 1. Optionally, in the **Query type** field, select the query type. The possible values are: * `SELECT`: `SELECT` queries. * `EXPLAIN`: `EXPLAIN` queries, except `EXPLAIN ANALYZE`. * `DESCRIBE`: `DESCRIBE`, `DESCRIBE INPUT`, and `DESCRIBE OUTPUT` queries, as well as `SHOW` queries, e.g., `SHOW CATALOGS` or `SHOW SCHEMAS`. * `INSERT`: `INSERT`, `CREATE TABLE AS`, and `REFRESH MATERIALIZED VIEW` queries. * `MERGE`: `MERGE` queries. * `DELETE`: `DELETE` queries. * `ANALYZE`: `ANALYZE` queries. * `DATA_DEFINITION`: `CREATE`, `ALTER`, and `DROP` queries for schemas, tables, views, and materialized views, as well as queries that manage prepared statements, access permissions, sessions, and transactions. * `ALTER_TABLE_EXECUTE`: `ALTER TABLE ... EXECUTE` queries. 1. Optionally, in the **Source** field, specify the name of the query source or a Java regular expression. The rule applies if the query source name matches the regular expression. If not specified, the rule applies to queries from all sources. 1. In the **Resource group** field, select the resource group to run the query in. A target group cannot have sub-groups. 1. Optionally, in the **Tags** field, specify tags separated by commas. The rule applies only if the query contains all the specified tags. If not specified, the rule applies to queries with any tags. {% note warning %} A query that does not satisfy any of the specified rules is rejected with an error. To avoid this, add to the end of the description a rule without any restrictive conditions, containing only the **Resource group** property. {% endnote %} Learn more about selector rules in [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). 1. Optionally, add other selector rules in the same way. 1. Click **Create**. - CLI {#cli} If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install). The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id ` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions. To specify a resource group configuration: 1. Create a file with a description of resource groups and selector rules in JSON or YAML format. Below is an example of the `resource-groups.yaml` file. ```yaml rootGroups: # Root resource group 1 - name: "" softMemoryLimit: "" softConcurrencyLimit: hardConcurrencyLimit: softCpuLimit: hardCpuLimit: maxQueued: schedulingPolicy: "" schedulingWeight: subGroups: # Resource sub-group 1 - name: "" ... subGroups: [] # Resource sub-group 2 - name: "" ... subGroups: [] ... # Resource sub-group N - name: "" ... subGroups: [] # Root resource group 2 - name: "" ... # Root resource group N - name: "" ... selectors: # Selector rule 1 - user: "" userGroup: "" queryType: "" source: "" clientTags: [""] group: "" # Selector rule 2 - ... ... # Selector rule N - ... cpuQuotaPeriod: "" ``` Where: * `rootGroups`: Resource group tree description. The `name`, `hardConcurrencyLimit`, and `maxQueued` settings are required. * `name`: Group name. A group name can be a template that uses variable placeholders in `${}` format. A template name may contain the following types of variables: * Built-in variables. `USER` for username, `SOURCE` for query source. * User-defined variables. These are declared in selector rule properties: `user`, `userGroup`, and `source`. When routing queries, Managed Service for Trino will create group instances with dynamically generated names. * `softMemoryLimit`: Maximum amount of memory available to the group. Once this limit is reached, new queries will be queued. You can set `softMemoryLimit` in one of the following ways: * As a percentage of the total available memory, e.g., `10%`. * As an absolute memory value, e.g., `1GB`. You can use one of these suffixes: `B`, `kB`, `MB`, `GB`, `TB`, or `PB`. * `softConcurrencyLimit`: Soft limit on the number of running queries. Once the limit is reached, the group will run new queries only if sibling groups are unable to accept queries or are above their soft limits. Otherwise, new queries will be queued. * `hardConcurrencyLimit`: Hard limit on the number of running queries. Once this limit is reached, new queries will be queued. * `softCpuLimit`: Soft limit on CPU time. Once this limit is reached, `hardConcurrencyLimit` will be reduced until the end of the current CPU quota calculation period. `softCpuLimit` cannot be greater than `hardCpuLimit`. * `hardCpuLimit`: Hard limit on CPU time. Once this limit is reached, new queries will be queued. {% note info %} If at least one of the two (`softCpuLimit` or `hardCpuLimit`) is specified, make sure to specify `cpuQuotaPeriod` as well. {% endnote %} * `maxQueued`: Maximum number of queries per queue. Once this limit is reached, new queries will be rejected with an error. * `schedulingPolicy`: [Queue scheduling policy](../concepts/resource-groups.md#policy). The possible values are: * `FAIR` * `WEIGHTED` * `WEIGHTED_FAIR` * `QUERY_PRIORITY` If not specified, the `FAIR` policy will apply. * `schedulingWeight`: Group weight used in the `WEIGHTED` and `WEIGHTED_FAIR` scheduling policies. If not specified, the group weight is `1`. * `subGroups`: Descriptions of sub-groups. * `selectors`: Selector rule description. The `group` property is required. * `user`: Name of the user who submitted the query or a Java regular expression. The rule applies if the user name matches the regular expression. If not specified, the rule applies to queries from all users. * `userGroup`: Name of the user group that submitted the query or a Java regular expression for user groups. The rule applies if the user group name matches the regular expression. If not specified, the rule applies to queries from users of any groups. * `queryType`: Type of the request. The possible values are: * `SELECT`: `SELECT` queries. * `EXPLAIN`: `EXPLAIN` queries, except `EXPLAIN ANALYZE`. * `DESCRIBE`: `DESCRIBE`, `DESCRIBE INPUT`, and `DESCRIBE OUTPUT` queries, as well as `SHOW` queries, e.g., `SHOW CATALOGS` or `SHOW SCHEMAS`. * `INSERT`: `INSERT`, `CREATE TABLE AS`, and `REFRESH MATERIALIZED VIEW` queries. * `MERGE`: `MERGE` queries. * `DELETE`: `DELETE` queries. * `ANALYZE`: `ANALYZE` queries. * `DATA_DEFINITION`: `CREATE`, `ALTER`, and `DROP` queries for schemas, tables, views, and materialized views, as well as queries that manage prepared statements, access permissions, sessions, and transactions. * `ALTER_TABLE_EXECUTE`: `ALTER TABLE ... EXECUTE` queries. * `source`: Query source name or a Java regular expression. The rule applies if the query source name matches the regular expression. If not specified, the rule applies to queries from all sources. * `clientTags`: Tag list. The rule applies only if the query contains all the specified tags. If not specified, the rule applies to queries with any tags. * `group`: Full name of the target resource group. It includes the names of all its parent groups, separated by dots, starting from the root group. A group name can use variable placeholders in `${}` format. A target group cannot have sub-groups. {% note warning %} A query that does not satisfy any of the specified rules is rejected with an error. To avoid this, add to the end of the description a rule without any restrictive conditions, containing only the `group` property. {% endnote %} * `cpuQuotaPeriod`: CPU quota calculation period for resource groups. It takes an integer value in seconds, minutes, or hours, e.g., `140s`, `30m`, or `1h`. For more information about the group tree and selector rules, see [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). 1. View the description of the CLI command for creating a cluster: ```bash yc managed-trino cluster create --help ``` 1. Run this command: ```bash yc managed-trino cluster create \ ... --resource-groups-from-file resource-groups.yaml ``` For available cluster parameters and their descriptions, see [this guide](cluster-create.md#create-cluster). - Terraform {#tf} 1. Create a Terraform configuration file describing your [infrastructure](cluster-create.md). 1. Add the `resource_groups` section to the cluster description: ```hcl resource_groups = jsonencode( { "rootGroups" : [ # Root resource group 1 { "name" : "", "softMemoryLimit" : "", "softConcurrencyLimit" : , "hardConcurrencyLimit" : , "softCpuLimit" : , "hardCpuLimit" : , "maxQueued" : , "schedulingPolicy" : "", "schedulingWeight" : , "subGroups" : [ # Resource sub-group 1 { ... "subGroups" : [] }, # Resource sub-group 2 { ... "subGroups" : [] }, ... # Resource sub-group N { ... "subGroups" : [] } ] }, # Root resource group 2 { ... }, ... # Root resource group N { ... } ], "selectors" : [ # Selector rule 1 { "user" : "", "userGroup" : "", "queryType" : "", "source" : "", "clientTags" : [""], "group" : "" }, # Selector rule 2 { ... }, ... # Selector rule N { ... } ], "cpuQuotaPeriod" : "" } ) ``` Where: * `rootGroups`: Resource group tree description. The `name`, `hardConcurrencyLimit`, and `maxQueued` settings are required. * `name`: Group name. A group name can be a template that uses variable placeholders in `${}` format. A template name may contain the following types of variables: * Built-in variables. `USER` for username, `SOURCE` for query source. * User-defined variables. These are declared in selector rule properties: `user`, `userGroup`, and `source`. When routing queries, Managed Service for Trino will create group instances with dynamically generated names. * `softMemoryLimit`: Maximum amount of memory available to the group. Once this limit is reached, new queries will be queued. You can set `softMemoryLimit` in one of the following ways: * As a percentage of the total available memory, e.g., `10%`. * As an absolute memory value, e.g., `1GB`. You can use one of these suffixes: `B`, `kB`, `MB`, `GB`, `TB`, or `PB`. * `softConcurrencyLimit`: Soft limit on the number of running queries. Once the limit is reached, the group will run new queries only if sibling groups are unable to accept queries or are above their soft limits. Otherwise, new queries will be queued. * `hardConcurrencyLimit`: Hard limit on the number of running queries. Once this limit is reached, new queries will be queued. * `softCpuLimit`: Soft limit on CPU time. Once this limit is reached, `hardConcurrencyLimit` will be reduced until the end of the current CPU quota calculation period. `softCpuLimit` cannot be greater than `hardCpuLimit`. * `hardCpuLimit`: Hard limit on CPU time. Once this limit is reached, new queries will be queued. {% note info %} If at least one of the two (`softCpuLimit` or `hardCpuLimit`) is specified, make sure to specify `cpuQuotaPeriod` as well. {% endnote %} * `maxQueued`: Maximum number of queries per queue. Once this limit is reached, new queries will be rejected with an error. * `schedulingPolicy`: [Queue scheduling policy](../concepts/resource-groups.md#policy). The possible values are: * `FAIR` * `WEIGHTED` * `WEIGHTED_FAIR` * `QUERY_PRIORITY` If not specified, the `FAIR` policy will apply. * `schedulingWeight`: Group weight used in the `WEIGHTED` and `WEIGHTED_FAIR` scheduling policies. If not specified, the group weight is `1`. * `subGroups`: Descriptions of sub-groups. * `selectors`: Selector rule description. The `group` property is required. * `user`: Name of the user who submitted the query or a Java regular expression. The rule applies if the user name matches the regular expression. If not specified, the rule applies to queries from all users. * `userGroup`: Name of the user group that submitted the query or a Java regular expression for user groups. The rule applies if the user group name matches the regular expression. If not specified, the rule applies to queries from users of any groups. * `queryType`: Type of the request. The possible values are: * `SELECT`: `SELECT` queries. * `EXPLAIN`: `EXPLAIN` queries, except `EXPLAIN ANALYZE`. * `DESCRIBE`: `DESCRIBE`, `DESCRIBE INPUT`, and `DESCRIBE OUTPUT` queries, as well as `SHOW` queries, e.g., `SHOW CATALOGS` or `SHOW SCHEMAS`. * `INSERT`: `INSERT`, `CREATE TABLE AS`, and `REFRESH MATERIALIZED VIEW` queries. * `MERGE`: `MERGE` queries. * `DELETE`: `DELETE` queries. * `ANALYZE`: `ANALYZE` queries. * `DATA_DEFINITION`: `CREATE`, `ALTER`, and `DROP` queries for schemas, tables, views, and materialized views, as well as queries that manage prepared statements, access permissions, sessions, and transactions. * `ALTER_TABLE_EXECUTE`: `ALTER TABLE ... EXECUTE` queries. * `source`: Query source name or a Java regular expression. The rule applies if the query source name matches the regular expression. If not specified, the rule applies to queries from all sources. * `clientTags`: Tag list. The rule applies only if the query contains all the specified tags. If not specified, the rule applies to queries with any tags. * `group`: Full name of the target resource group. It includes the names of all its parent groups, separated by dots, starting from the root group. A group name can use variable placeholders in `${}` format. A target group cannot have sub-groups. {% note warning %} A query that does not satisfy any of the specified rules is rejected with an error. To avoid this, add to the end of the description a rule without any restrictive conditions, containing only the `group` property. {% endnote %} * `cpuQuotaPeriod`: CPU quota calculation period for resource groups. It takes an integer value in seconds, minutes, or hours, e.g., `140s`, `30m`, or `1h`. For more information about the group tree and selector rules, see [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). {% note info %} You can also create a separate JSON file describing resource groups and selector rules and provide it in the `resource_groups` parameter as follows: ```hcl resource_groups = file("resource-groups.json") ``` {% endnote %} 1. Make sure the settings are correct. 1. In the command line, navigate to the directory that contains the current Terraform configuration files defining the infrastructure. 1. Run this command: ```bash terraform validate ``` Terraform will show any errors found in your configuration files. 1. Confirm resource changes. 1. Run this command to view the planned changes: ```bash terraform plan ``` If you described the configuration correctly, the terminal will display a list of the resources to update and their parameters. This is a verification step that does not apply changes to your resources. 1. If everything looks correct, apply the changes: 1. Run this command: ```bash terraform apply ``` 1. Confirm updating the resources. 1. Wait for the operation to complete. For more information, see [this Terraform provider guide](../../terraform/resources/trino_access_control.md). - REST API {#api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Create a file named `body.json` and paste the following code into it: ```json { ... "trino": { ... "resourceManagement": { "resourceGroups": { "rootGroups": [ { "name" : "", "softMemoryLimit" : "", "softConcurrencyLimit" : "", "hardConcurrencyLimit" : "", "softCpuLimit" : "", "hardCpuLimit" : "", "maxQueued" : "", "schedulingPolicy" : "", "schedulingWeight" : "", "subGroups": [ { ... "subGroups" : [] }, { ... "subGroups" : [] }, ... { ... "subGroups" : [] } ] }, { }, ... { } ], "selectors": [ { "user": "", "userGroup": "", "queryType": "", "source": "", "clientTags": [""], "group": "" }, { }, ... { } ], "cpuQuotaPeriod": "" } ... }, } } ``` Where: * `rootGroups`: Resource group tree description. The `name`, `hardConcurrencyLimit`, and `maxQueued` settings are required. * `name`: Group name. A group name can be a template that uses variable placeholders in `${}` format. A template name may contain the following types of variables: * Built-in variables. `USER` for username, `SOURCE` for query source. * User-defined variables. These are declared in selector rule properties: `user`, `userGroup`, and `source`. When routing queries, Managed Service for Trino will create group instances with dynamically generated names. * `softMemoryLimit`: Maximum amount of memory available to the group. Once this limit is reached, new queries will be queued. You can set `softMemoryLimit` in one of the following ways: * As a percentage of the total available memory, e.g., `10%`. * As an absolute memory value, e.g., `1GB`. You can use one of these suffixes: `B`, `kB`, `MB`, `GB`, `TB`, or `PB`. * `softConcurrencyLimit`: Soft limit on the number of running queries. Once the limit is reached, the group will run new queries only if sibling groups are unable to accept queries or are above their soft limits. Otherwise, new queries will be queued. * `hardConcurrencyLimit`: Hard limit on the number of running queries. Once this limit is reached, new queries will be queued. * `softCpuLimit`: Soft limit on CPU time. Once this limit is reached, `hardConcurrencyLimit` will be reduced until the end of the current CPU quota calculation period. `softCpuLimit` cannot be greater than `hardCpuLimit`. * `hardCpuLimit`: Hard limit on CPU time. Once this limit is reached, new queries will be queued. {% note info %} If at least one of the two (`softCpuLimit` or `hardCpuLimit`) is specified, make sure to specify `cpuQuotaPeriod` as well. {% endnote %} * `maxQueued`: Maximum number of queries per queue. Once this limit is reached, new queries will be rejected with an error. * `schedulingPolicy`: [Queue scheduling policy](../concepts/resource-groups.md#policy). The possible values are: * `FAIR` * `WEIGHTED` * `WEIGHTED_FAIR` * `QUERY_PRIORITY` If not specified, the `FAIR` policy will apply. * `schedulingWeight`: Group weight used in the `WEIGHTED` and `WEIGHTED_FAIR` scheduling policies. If not specified, the group weight is `1`. * `subGroups`: Descriptions of sub-groups. * `selectors`: Selector rule description. The `group` property is required. * `user`: Name of the user who submitted the query or a Java regular expression. The rule applies if the user name matches the regular expression. If not specified, the rule applies to queries from all users. * `userGroup`: Name of the user group that submitted the query or a Java regular expression for user groups. The rule applies if the user group name matches the regular expression. If not specified, the rule applies to queries from users of any groups. * `queryType`: Type of the request. The possible values are: * `SELECT`: `SELECT` queries. * `EXPLAIN`: `EXPLAIN` queries, except `EXPLAIN ANALYZE`. * `DESCRIBE`: `DESCRIBE`, `DESCRIBE INPUT`, and `DESCRIBE OUTPUT` queries, as well as `SHOW` queries, e.g., `SHOW CATALOGS` or `SHOW SCHEMAS`. * `INSERT`: `INSERT`, `CREATE TABLE AS`, and `REFRESH MATERIALIZED VIEW` queries. * `MERGE`: `MERGE` queries. * `DELETE`: `DELETE` queries. * `ANALYZE`: `ANALYZE` queries. * `DATA_DEFINITION`: `CREATE`, `ALTER`, and `DROP` queries for schemas, tables, views, and materialized views, as well as queries that manage prepared statements, access permissions, sessions, and transactions. * `ALTER_TABLE_EXECUTE`: `ALTER TABLE ... EXECUTE` queries. * `source`: Query source name or a Java regular expression. The rule applies if the query source name matches the regular expression. If not specified, the rule applies to queries from all sources. * `clientTags`: Tag list. The rule applies only if the query contains all the specified tags. If not specified, the rule applies to queries with any tags. * `group`: Full name of the target resource group. It includes the names of all its parent groups, separated by dots, starting from the root group. A group name can use variable placeholders in `${}` format. A target group cannot have sub-groups. {% note warning %} A query that does not satisfy any of the specified rules is rejected with an error. To avoid this, add to the end of the description a rule without any restrictive conditions, containing only the `group` property. {% endnote %} * `cpuQuotaPeriod`: CPU quota calculation period for resource groups. It takes an integer value in seconds, minutes, or hours, e.g., `140s`, `30m`, or `1h`. For more information about the group tree and selector rules, see [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). 1. Call the [Cluster.Create](../api-ref/Cluster/create.md) method, e.g., via the following [cURL](https://curl.se/) request: ```bash curl \ --request POST \ --header "Authorization: Bearer $IAM_TOKEN" \ --url 'https://trino.api.cloud.yandex.net/managed-trino/v1/clusters' --data '@body.json' ``` 1. View the [server response](../api-ref/Cluster/create.md#yandex.cloud.operation.Operation) to make sure your request was successful. - gRPC API {#grpc-api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and place it in an environment variable: ```bash export IAM_TOKEN="" ``` 1. Clone the [cloudapi](https://github.com/yandex-cloud/cloudapi) repository: ```bash cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi ``` Below, we assume that the repository contents reside in the `~/cloudapi/` directory. 1. Create a file named `body.json` and paste the following code into it: ```json { ... "trino": { ... "resource_management": { "resource_groups": { "root_groups": [ { "name" : "", "soft_memory_limit" : "", "soft_concurrency_limit" : "", "hard_concurrency_limit" : "", "soft_cpu_limit" : "", "hard_cpu_limit" : "", "max_queued" : "", "scheduling_policy" : "", "scheduling_weight" : "", "sub_groups": [ { ... "sub_groups" : [] }, { ... "sub_groups" : [] }, ... { ... "sub_groups" : [] } ] }, { }, ... { } ], "selectors": [ { "user": "", "user_group": "", "query_type": "", "source": "", "client_tags": [""], "group": "" }, { }, ... { } ], "cpu_quota_period": "" } ... }, } } ``` Where: * `root_groups`: Resource group tree description. The `name`, `hard_concurrency_limit`, and `max_queued` settings are required. * `name`: Group name. A group name can be a template that uses variable placeholders in `${}` format. A template name may contain the following types of variables: * Built-in variables. `USER` for username, `SOURCE` for query source. * User-defined variables. These are declared in selector rule properties: `user`, `user_group`, and `source`. When routing queries, Managed Service for Trino will create group instances with dynamically generated names. * `soft_memory_limit`: Maximum amount of memory available to the group. Once this limit is reached, new queries will be queued. You can set `soft_memory_limit` in one of the following ways: * As a percentage of the total available memory, e.g., `10%`. * As an absolute memory value, e.g., `1GB`. You can use one of these suffixes: `B`, `kB`, `MB`, `GB`, `TB`, or `PB`. * `soft_concurrency_limit`: Soft limit on the number of running queries. Once the limit is reached, the group will run new queries only if sibling groups are unable to accept queries or are above their soft limits. Otherwise, new queries will be queued. * `hard_concurrency_limit`: Hard limit on the number of running queries. Once this limit is reached, new queries will be queued. * `soft_cpu_limit`: Soft limit on CPU time. Once this limit is reached, `hard_concurrency_limit` will be reduced until the end of the current CPU quota calculation period. `soft_cpu_limit` cannot be greater than `hard_cpu_limit`. * `hard_cpu_limit`: Hard limit on CPU time. Once this limit is reached, new queries will be queued. {% note info %} If at least one of the two (`soft_cpu_limit` or `hard_cpu_limit`) is specified, make sure to specify `cpu_quota_period` as well. {% endnote %} * `max_queued`: Maximum number of queries per queue. Once this limit is reached, new queries will be rejected with an error. * `scheduling_policy`: [Queue scheduling policy](../concepts/resource-groups.md#policy). The possible values are: * `FAIR` * `WEIGHTED` * `WEIGHTED_FAIR` * `QUERY_PRIORITY` If not specified, the `FAIR` policy will apply. * `scheduling_weight`: Group weight used in the `WEIGHTED` and `WEIGHTED_FAIR` scheduling policies. If not specified, the group weight is `1`. * `sub_groups`: Descriptions of sub-groups. * `selectors`: Selector rule description. The `group` property is required. * `user`: Name of the user who submitted the query or a Java regular expression. The rule applies if the user name matches the regular expression. If not specified, the rule applies to queries from all users. * `user_group`: Name of the user group that submitted the query or a Java regular expression for user groups. The rule applies if the user group name matches the regular expression. If not specified, the rule applies to queries from users of any groups. * `query_type`: Type of the request. The possible values are: * `SELECT`: `SELECT` queries. * `EXPLAIN`: `EXPLAIN` queries, except `EXPLAIN ANALYZE`. * `DESCRIBE`: `DESCRIBE`, `DESCRIBE INPUT`, and `DESCRIBE OUTPUT` queries, as well as `SHOW` queries, e.g., `SHOW CATALOGS` or `SHOW SCHEMAS`. * `INSERT`: `INSERT`, `CREATE TABLE AS`, and `REFRESH MATERIALIZED VIEW` queries. * `MERGE`: `MERGE` queries. * `DELETE`: `DELETE` queries. * `ANALYZE`: `ANALYZE` queries. * `DATA_DEFINITION`: `CREATE`, `ALTER`, and `DROP` queries for schemas, tables, views, and materialized views, as well as queries that manage prepared statements, access permissions, sessions, and transactions. * `ALTER_TABLE_EXECUTE`: `ALTER TABLE ... EXECUTE` queries. * `source`: Query source name or a Java regular expression. The rule applies if the query source name matches the regular expression. If not specified, the rule applies to queries from all sources. * `client_tags`: Tag list. The rule applies only if the query contains all the specified tags. If not specified, the rule applies to queries with any tags. * `group`: Full name of the target resource group. It includes the names of all its parent groups, separated by dots, starting from the root group. A group name can use variable placeholders in `${}` format. A target group cannot have sub-groups. {% note warning %} A query that does not satisfy any of the specified rules is rejected with an error. To avoid this, add to the end of the description a rule without any restrictive conditions, containing only the `group` property. {% endnote %} * `cpu_quota_period`: CPU quota calculation period for resource groups. It takes an integer value in seconds, minutes, or hours, e.g., `140s`, `30m`, or `1h`. For more information about the group tree and selector rules, see [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). For available cluster parameters and their descriptions, see [this guide](cluster-create.md#create-cluster). 1. Call the [ClusterService.Create](../api-ref/grpc/Cluster/create.md) method, e.g., via the following [gRPCurl](https://github.com/fullstorydev/grpcurl) request: ```bash grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/trino/v1/cluster_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d @ \ trino.api.cloud.yandex.net:443 \ yandex.cloud.trino.v1.ClusterService.Create \ < body.json ``` 1. Check the [server response](../api-ref/grpc/Cluster/create.md#yandex.cloud.operation.Operation) to make sure your request was successful. {% endlist %} ## Setting up or updating a resource group configuration in a cluster {#set-at-update} {% list tabs group=instructions %} - Management console {#console} 1. In the [management console](https://console.yandex.cloud), navigate to the relevant folder. 1. Navigate to **Managed Service for Trino**. 1. Click the cluster name. 1. Go to the **Resource management** section. 1. In the **CPU quota period** field, set the new CPU quota calculation period for resource groups. 1. To add a new resource group, click **Add group** and set up the group: 1. Optionally, select a parent group. 1. Specify a name for the resource group. A group name can be a template that uses variable placeholders in `${}` format. A template name may contain the following types of variables: * Built-in variables. `USER` for username, `SOURCE` for query source. * User-defined variables. These are declared in selector rule properties: **User** and **Source**. When routing queries, Managed Service for Trino will create group instances with dynamically generated names. 1. In the **Max queued** field, set the maximum number of queries per queue (must be higher than `1`). Once this limit is reached, new queries will be rejected with an error. 1. Optionally, set a soft limit on the number of running queries in the **Soft concurrency limit** field. Once the limit is reached, the group will run new queries only if sibling groups are unable to accept queries or are above their soft limits. Otherwise, new queries will be queued. 1. In the **Hard concurrency limit** field, set the maximum number of running queries (must be higher than `1`). Once this limit is reached, new queries will be queued. 1. Optionally, set the maximum amount of memory available to the group in the **Soft memory limit, %** field. Once this limit is reached, new queries will be queued. 1. Optionally, set a soft limit on CPU time in the **Soft CPU limit** field. Once this limit is reached, the maximum number of running queries will be reduced until the end of the current CPU quota calculation period. This value cannot be greater than **Hard CPU limit**. To set **Soft CPU limit**, you also need to set **CPU quota period**. 1. Optionally, set a hard limit on CPU time in the **Hard CPU limit** field. Once this limit is reached, new queries will be queued. To set **Hard CPU limit**, you also need to set **CPU quota period**. 1. Optionally, set a [query scheduling policy](../concepts/resource-groups.md#policy) in the **Scheduling policy** field. The possible values are `fair`, `weighted`, `weighted_fair`, or `query_priority`. The default value is `none` (the `fair` policy applies). 1. Optionally, set the group weight used in the `weighted` and `weighted_fair` scheduling policies in the **Scheduling weight** field. Learn more about group trees in [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). 1. Optionally, add other resource groups in the same way. 1. To edit a resource group: 1. Click ![trash-bin](../../_assets/console-icons/pencil.svg) next to the group. 1. Update the group parameters and click **Edit**. 1. To add a new selector rule, click **Add rule** and set up the rule: 1. Optionally, in the **User** field, specify the name of the user who submitted the query or a Java regular expression. The rule applies if the user name matches the regular expression. If you skip this setting, the rule applies to queries from all users. 1. Optionally, in the **Group** field, specify the name of the user group that submitted the query or a Java regular expression. The rule applies if the user group name matches the regular expression. If not specified, the rule applies to queries from users of any groups. 1. Optionally, in the **Query type** field, select the query type. The possible values are: * `SELECT`: `SELECT` queries. * `EXPLAIN`: `EXPLAIN` queries, except `EXPLAIN ANALYZE`. * `DESCRIBE`: `DESCRIBE`, `DESCRIBE INPUT`, and `DESCRIBE OUTPUT` queries, as well as `SHOW` queries, e.g., `SHOW CATALOGS` or `SHOW SCHEMAS`. * `INSERT`: `INSERT`, `CREATE TABLE AS`, and `REFRESH MATERIALIZED VIEW` queries. * `MERGE`: `MERGE` queries. * `DELETE`: `DELETE` queries. * `ANALYZE`: `ANALYZE` queries. * `DATA_DEFINITION`: `CREATE`, `ALTER`, and `DROP` queries for schemas, tables, views, and materialized views, as well as queries that manage prepared statements, access permissions, sessions, and transactions. * `ALTER_TABLE_EXECUTE`: `ALTER TABLE ... EXECUTE` queries. 1. Optionally, in the **Source** field, specify the name of the query source or a Java regular expression. The rule applies if the query source name matches the regular expression. If not specified, the rule applies to queries from all sources. 1. In the **Resource group** field, select the resource group to run the query in. A target group cannot have sub-groups. 1. Optionally, in the **Tags** field, specify tags separated by commas. The rule applies only if the query contains all the specified tags. If not specified, the rule applies to queries with any tags. {% note warning %} A query that does not satisfy any of the specified rules is rejected with an error. To avoid this, add to the end of the description a rule without any restrictive conditions, containing only the **Resource group** property. {% endnote %} Learn more about selector rules in [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). 1. Optionally, add other selector rules in the same way. 1. To edit a selector rule: 1. Click ![pencil](../../_assets/console-icons/pencil.svg) in the line with this rule. 1. Edit the rule parameters. 1. Click **Save changes**. - CLI {#cli} If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install). The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id ` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions. To specify a resource group configuration: 1. If no description of resource groups and selector rules in the Managed Service for Trino cluster has been given yet, create a description file in JSON or YAML format. Below is an example of the `resource-groups.yaml` file. ```yaml rootGroups: # Root resource group 1 - name: "" softMemoryLimit: "" softConcurrencyLimit: hardConcurrencyLimit: softCpuLimit: hardCpuLimit: maxQueued: schedulingPolicy: "" schedulingWeight: subGroups: # Resource sub-group 1 - name: "" ... subGroups: [] # Resource sub-group 2 - name: "" ... subGroups: [] ... # Resource sub-group N - name: "" ... subGroups: [] # Root resource group 2 - name: "" ... # Root resource group N - name: "" ... selectors: # Selector rule 1 - user: "" userGroup: "" queryType: "" source: "" clientTags: [""] group: "" # Selector rule 2 - ... ... # Selector rule N - ... cpuQuotaPeriod: "" ``` Where: * `rootGroups`: Resource group tree description. The `name`, `hardConcurrencyLimit`, and `maxQueued` settings are required. * `name`: Group name. A group name can be a template that uses variable placeholders in `${}` format. A template name may contain the following types of variables: * Built-in variables. `USER` for username, `SOURCE` for query source. * User-defined variables. These are declared in selector rule properties: `user`, `userGroup`, and `source`. When routing queries, Managed Service for Trino will create group instances with dynamically generated names. * `softMemoryLimit`: Maximum amount of memory available to the group. Once this limit is reached, new queries will be queued. You can set `softMemoryLimit` in one of the following ways: * As a percentage of the total available memory, e.g., `10%`. * As an absolute memory value, e.g., `1GB`. You can use one of these suffixes: `B`, `kB`, `MB`, `GB`, `TB`, or `PB`. * `softConcurrencyLimit`: Soft limit on the number of running queries. Once the limit is reached, the group will run new queries only if sibling groups are unable to accept queries or are above their soft limits. Otherwise, new queries will be queued. * `hardConcurrencyLimit`: Hard limit on the number of running queries. Once this limit is reached, new queries will be queued. * `softCpuLimit`: Soft limit on CPU time. Once this limit is reached, `hardConcurrencyLimit` will be reduced until the end of the current CPU quota calculation period. `softCpuLimit` cannot be greater than `hardCpuLimit`. * `hardCpuLimit`: Hard limit on CPU time. Once this limit is reached, new queries will be queued. {% note info %} If at least one of the two (`softCpuLimit` or `hardCpuLimit`) is specified, make sure to specify `cpuQuotaPeriod` as well. {% endnote %} * `maxQueued`: Maximum number of queries per queue. Once this limit is reached, new queries will be rejected with an error. * `schedulingPolicy`: [Queue scheduling policy](../concepts/resource-groups.md#policy). The possible values are: * `FAIR` * `WEIGHTED` * `WEIGHTED_FAIR` * `QUERY_PRIORITY` If not specified, the `FAIR` policy will apply. * `schedulingWeight`: Group weight used in the `WEIGHTED` and `WEIGHTED_FAIR` scheduling policies. If not specified, the group weight is `1`. * `subGroups`: Descriptions of sub-groups. * `selectors`: Selector rule description. The `group` property is required. * `user`: Name of the user who submitted the query or a Java regular expression. The rule applies if the user name matches the regular expression. If not specified, the rule applies to queries from all users. * `userGroup`: Name of the user group that submitted the query or a Java regular expression for user groups. The rule applies if the user group name matches the regular expression. If not specified, the rule applies to queries from users of any groups. * `queryType`: Type of the request. The possible values are: * `SELECT`: `SELECT` queries. * `EXPLAIN`: `EXPLAIN` queries, except `EXPLAIN ANALYZE`. * `DESCRIBE`: `DESCRIBE`, `DESCRIBE INPUT`, and `DESCRIBE OUTPUT` queries, as well as `SHOW` queries, e.g., `SHOW CATALOGS` or `SHOW SCHEMAS`. * `INSERT`: `INSERT`, `CREATE TABLE AS`, and `REFRESH MATERIALIZED VIEW` queries. * `MERGE`: `MERGE` queries. * `DELETE`: `DELETE` queries. * `ANALYZE`: `ANALYZE` queries. * `DATA_DEFINITION`: `CREATE`, `ALTER`, and `DROP` queries for schemas, tables, views, and materialized views, as well as queries that manage prepared statements, access permissions, sessions, and transactions. * `ALTER_TABLE_EXECUTE`: `ALTER TABLE ... EXECUTE` queries. * `source`: Query source name or a Java regular expression. The rule applies if the query source name matches the regular expression. If not specified, the rule applies to queries from all sources. * `clientTags`: Tag list. The rule applies only if the query contains all the specified tags. If not specified, the rule applies to queries with any tags. * `group`: Full name of the target resource group. It includes the names of all its parent groups, separated by dots, starting from the root group. A group name can use variable placeholders in `${}` format. A target group cannot have sub-groups. {% note warning %} A query that does not satisfy any of the specified rules is rejected with an error. To avoid this, add to the end of the description a rule without any restrictive conditions, containing only the `group` property. {% endnote %} * `cpuQuotaPeriod`: CPU quota calculation period for resource groups. It takes an integer value in seconds, minutes, or hours, e.g., `140s`, `30m`, or `1h`. For more information about the group tree and selector rules, see [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). 1. If a description of resource groups and selector rules has already been given, open `resource-groups.yaml` and edit it as needed. You can: * Add new resource groups and selector rules. * Update the parameters of existing groups and rules. * Delete the groups and rules you no longer need. 1. Run this command: ```bash yc managed-trino cluster set-resource-groups \ --from-file resource-groups.yaml ``` You can get the cluster name and ID with the [list of clusters](cluster-list.md#list-clusters) in the folder. - Terraform {#tf} 1. Open the current Terraform configuration file with the infrastructure plan. To learn how to create this file, refer to [Creating a cluster](cluster-create.md). 1. If no description of resource groups and selector rules in the Managed Service for Trino cluster has been given yet, add the `resource_groups` section to the cluster description: ```hcl resource_groups = jsonencode( { "rootGroups" : [ # Root resource group 1 { "name" : "", "softMemoryLimit" : "", "softConcurrencyLimit" : , "hardConcurrencyLimit" : , "softCpuLimit" : , "hardCpuLimit" : , "maxQueued" : , "schedulingPolicy" : "", "schedulingWeight" : , "subGroups" : [ # Resource sub-group 1 { ... "subGroups" : [] }, # Resource sub-group 2 { ... "subGroups" : [] }, ... # Resource sub-group N { ... "subGroups" : [] } ] }, # Root resource group 2 { ... }, ... # Root resource group N { ... } ], "selectors" : [ # Selector rule 1 { "user" : "", "userGroup" : "", "queryType" : "", "source" : "", "clientTags" : [""], "group" : "" }, # Selector rule 2 { ... }, ... # Selector rule N { ... } ], "cpuQuotaPeriod" : "" } ) ``` Where: * `rootGroups`: Resource group tree description. The `name`, `hardConcurrencyLimit`, and `maxQueued` settings are required. * `name`: Group name. A group name can be a template that uses variable placeholders in `${}` format. A template name may contain the following types of variables: * Built-in variables. `USER` for username, `SOURCE` for query source. * User-defined variables. These are declared in selector rule properties: `user`, `userGroup`, and `source`. When routing queries, Managed Service for Trino will create group instances with dynamically generated names. * `softMemoryLimit`: Maximum amount of memory available to the group. Once this limit is reached, new queries will be queued. You can set `softMemoryLimit` in one of the following ways: * As a percentage of the total available memory, e.g., `10%`. * As an absolute memory value, e.g., `1GB`. You can use one of these suffixes: `B`, `kB`, `MB`, `GB`, `TB`, or `PB`. * `softConcurrencyLimit`: Soft limit on the number of running queries. Once the limit is reached, the group will run new queries only if sibling groups are unable to accept queries or are above their soft limits. Otherwise, new queries will be queued. * `hardConcurrencyLimit`: Hard limit on the number of running queries. Once this limit is reached, new queries will be queued. * `softCpuLimit`: Soft limit on CPU time. Once this limit is reached, `hardConcurrencyLimit` will be reduced until the end of the current CPU quota calculation period. `softCpuLimit` cannot be greater than `hardCpuLimit`. * `hardCpuLimit`: Hard limit on CPU time. Once this limit is reached, new queries will be queued. {% note info %} If at least one of the two (`softCpuLimit` or `hardCpuLimit`) is specified, make sure to specify `cpuQuotaPeriod` as well. {% endnote %} * `maxQueued`: Maximum number of queries per queue. Once this limit is reached, new queries will be rejected with an error. * `schedulingPolicy`: [Queue scheduling policy](../concepts/resource-groups.md#policy). The possible values are: * `FAIR` * `WEIGHTED` * `WEIGHTED_FAIR` * `QUERY_PRIORITY` If not specified, the `FAIR` policy will apply. * `schedulingWeight`: Group weight used in the `WEIGHTED` and `WEIGHTED_FAIR` scheduling policies. If not specified, the group weight is `1`. * `subGroups`: Descriptions of sub-groups. * `selectors`: Selector rule description. The `group` property is required. * `user`: Name of the user who submitted the query or a Java regular expression. The rule applies if the user name matches the regular expression. If not specified, the rule applies to queries from all users. * `userGroup`: Name of the user group that submitted the query or a Java regular expression for user groups. The rule applies if the user group name matches the regular expression. If not specified, the rule applies to queries from users of any groups. * `queryType`: Type of the request. The possible values are: * `SELECT`: `SELECT` queries. * `EXPLAIN`: `EXPLAIN` queries, except `EXPLAIN ANALYZE`. * `DESCRIBE`: `DESCRIBE`, `DESCRIBE INPUT`, and `DESCRIBE OUTPUT` queries, as well as `SHOW` queries, e.g., `SHOW CATALOGS` or `SHOW SCHEMAS`. * `INSERT`: `INSERT`, `CREATE TABLE AS`, and `REFRESH MATERIALIZED VIEW` queries. * `MERGE`: `MERGE` queries. * `DELETE`: `DELETE` queries. * `ANALYZE`: `ANALYZE` queries. * `DATA_DEFINITION`: `CREATE`, `ALTER`, and `DROP` queries for schemas, tables, views, and materialized views, as well as queries that manage prepared statements, access permissions, sessions, and transactions. * `ALTER_TABLE_EXECUTE`: `ALTER TABLE ... EXECUTE` queries. * `source`: Query source name or a Java regular expression. The rule applies if the query source name matches the regular expression. If not specified, the rule applies to queries from all sources. * `clientTags`: Tag list. The rule applies only if the query contains all the specified tags. If not specified, the rule applies to queries with any tags. * `group`: Full name of the target resource group. It includes the names of all its parent groups, separated by dots, starting from the root group. A group name can use variable placeholders in `${}` format. A target group cannot have sub-groups. {% note warning %} A query that does not satisfy any of the specified rules is rejected with an error. To avoid this, add to the end of the description a rule without any restrictive conditions, containing only the `group` property. {% endnote %} * `cpuQuotaPeriod`: CPU quota calculation period for resource groups. It takes an integer value in seconds, minutes, or hours, e.g., `140s`, `30m`, or `1h`. For more information about the group tree and selector rules, see [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). {% note info %} You can also create a separate JSON file describing resource groups and selector rules and provide it in the `resource_groups` parameter as follows: ```hcl resource_groups = file("resource-groups.json") ``` {% endnote %} 1. If a description of resource groups and selector rules has already been given, edit the `resource_groups` section or JSON file as needed. You can: * Add new resource groups and selector rules. * Update the parameters of existing groups and rules. * Delete the groups and rules you no longer need. 1. Make sure the settings are correct. 1. In the command line, navigate to the directory that contains the current Terraform configuration files defining the infrastructure. 1. Run this command: ```bash terraform validate ``` Terraform will show any errors found in your configuration files. 1. Confirm resource changes. 1. Run this command to view the planned changes: ```bash terraform plan ``` If you described the configuration correctly, the terminal will display a list of the resources to update and their parameters. This is a verification step that does not apply changes to your resources. 1. If everything looks correct, apply the changes: 1. Run this command: ```bash terraform apply ``` 1. Confirm updating the resources. 1. Wait for the operation to complete. For more information, see [this Terraform provider guide](../../terraform/resources/trino_access_control.md). - REST API {#api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Create a file named `body.json` and paste the following code into it: ```json { "updateMask": "", "trino": { "resourceManagement": { "resourceGroups": { "rootGroups": [ { "name" : "", "softMemoryLimit" : "", "softConcurrencyLimit" : "", "hardConcurrencyLimit" : "", "softCpuLimit" : "", "hardCpuLimit" : "", "maxQueued" : "", "schedulingPolicy" : "", "schedulingWeight" : "", "subGroups": [ { ... "subGroups" : [] }, { ... "subGroups" : [] }, ... { ... "subGroups" : [] } ] }, { }, ... { } ], "selectors": [ { "user": "", "userGroup": "", "queryType": "", "source": "", "clientTags": [""], "group": "" }, { }, ... { } ], "cpuQuotaPeriod": "" } ... }, } } ``` Where: * `updateMask`: Comma-separated list of parameters to update. {% note warning %} When you update a cluster, all parameters of the object you are modifying will be reset to their defaults unless explicitly provided in the request. To avoid this, list the settings you want to change in the `updateMask` parameter. {% endnote %} * `rootGroups`: Resource group tree description. The `name`, `hardConcurrencyLimit`, and `maxQueued` settings are required. * `name`: Group name. A group name can be a template that uses variable placeholders in `${}` format. A template name may contain the following types of variables: * Built-in variables. `USER` for username, `SOURCE` for query source. * User-defined variables. These are declared in selector rule properties: `user`, `userGroup`, and `source`. When routing queries, Managed Service for Trino will create group instances with dynamically generated names. * `softMemoryLimit`: Maximum amount of memory available to the group. Once this limit is reached, new queries will be queued. You can set `softMemoryLimit` in one of the following ways: * As a percentage of the total available memory, e.g., `10%`. * As an absolute memory value, e.g., `1GB`. You can use one of these suffixes: `B`, `kB`, `MB`, `GB`, `TB`, or `PB`. * `softConcurrencyLimit`: Soft limit on the number of running queries. Once the limit is reached, the group will run new queries only if sibling groups are unable to accept queries or are above their soft limits. Otherwise, new queries will be queued. * `hardConcurrencyLimit`: Hard limit on the number of running queries. Once this limit is reached, new queries will be queued. * `softCpuLimit`: Soft limit on CPU time. Once this limit is reached, `hardConcurrencyLimit` will be reduced until the end of the current CPU quota calculation period. `softCpuLimit` cannot be greater than `hardCpuLimit`. * `hardCpuLimit`: Hard limit on CPU time. Once this limit is reached, new queries will be queued. {% note info %} If at least one of the two (`softCpuLimit` or `hardCpuLimit`) is specified, make sure to specify `cpuQuotaPeriod` as well. {% endnote %} * `maxQueued`: Maximum number of queries per queue. Once this limit is reached, new queries will be rejected with an error. * `schedulingPolicy`: [Queue scheduling policy](../concepts/resource-groups.md#policy). The possible values are: * `FAIR` * `WEIGHTED` * `WEIGHTED_FAIR` * `QUERY_PRIORITY` If not specified, the `FAIR` policy will apply. * `schedulingWeight`: Group weight used in the `WEIGHTED` and `WEIGHTED_FAIR` scheduling policies. If not specified, the group weight is `1`. * `subGroups`: Descriptions of sub-groups. * `selectors`: Selector rule description. The `group` property is required. * `user`: Name of the user who submitted the query or a Java regular expression. The rule applies if the user name matches the regular expression. If not specified, the rule applies to queries from all users. * `userGroup`: Name of the user group that submitted the query or a Java regular expression for user groups. The rule applies if the user group name matches the regular expression. If not specified, the rule applies to queries from users of any groups. * `queryType`: Type of the request. The possible values are: * `SELECT`: `SELECT` queries. * `EXPLAIN`: `EXPLAIN` queries, except `EXPLAIN ANALYZE`. * `DESCRIBE`: `DESCRIBE`, `DESCRIBE INPUT`, and `DESCRIBE OUTPUT` queries, as well as `SHOW` queries, e.g., `SHOW CATALOGS` or `SHOW SCHEMAS`. * `INSERT`: `INSERT`, `CREATE TABLE AS`, and `REFRESH MATERIALIZED VIEW` queries. * `MERGE`: `MERGE` queries. * `DELETE`: `DELETE` queries. * `ANALYZE`: `ANALYZE` queries. * `DATA_DEFINITION`: `CREATE`, `ALTER`, and `DROP` queries for schemas, tables, views, and materialized views, as well as queries that manage prepared statements, access permissions, sessions, and transactions. * `ALTER_TABLE_EXECUTE`: `ALTER TABLE ... EXECUTE` queries. * `source`: Query source name or a Java regular expression. The rule applies if the query source name matches the regular expression. If not specified, the rule applies to queries from all sources. * `clientTags`: Tag list. The rule applies only if the query contains all the specified tags. If not specified, the rule applies to queries with any tags. * `group`: Full name of the target resource group. It includes the names of all its parent groups, separated by dots, starting from the root group. A group name can use variable placeholders in `${}` format. A target group cannot have sub-groups. {% note warning %} A query that does not satisfy any of the specified rules is rejected with an error. To avoid this, add to the end of the description a rule without any restrictive conditions, containing only the `group` property. {% endnote %} * `cpuQuotaPeriod`: CPU quota calculation period for resource groups. It takes an integer value in seconds, minutes, or hours, e.g., `140s`, `30m`, or `1h`. For more information about the group tree and selector rules, see [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). 1. Call the [Cluster.Update](../api-ref/Cluster/update.md) method, e.g., via the following [cURL](https://curl.se/) request: ```bash curl \ --request PATCH \ --header "Authorization: Bearer $IAM_TOKEN" \ --url 'https://trino.api.cloud.yandex.net/managed-trino/v1/clusters/' --data '@body.json' ``` You can get the cluster ID with the [list of clusters](cluster-list.md#list-clusters) in the folder. 1. Check the [server response](../api-ref/Cluster/update.md#yandex.cloud.operation.Operation) to make sure your request was successful. - gRPC API {#grpc-api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and place it in an environment variable: ```bash export IAM_TOKEN="" ``` 1. Clone the [cloudapi](https://github.com/yandex-cloud/cloudapi) repository: ```bash cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi ``` Below, we assume that the repository contents reside in the `~/cloudapi/` directory. 1. Create a file named `body.json` and paste the following code into it: ```json { "cluster_id": "", "update_mask": { "paths": [ ] }, "trino": { "resource_management": { "resource_groups": { "root_groups": [ { "name" : "", "soft_memory_limit" : "", "soft_concurrency_limit" : "", "hard_concurrency_limit" : "", "soft_cpu_limit" : "", "hard_cpu_limit" : "", "max_queued" : "", "scheduling_policy" : "", "scheduling_weight" : "", "sub_groups": [ { ... "sub_groups" : [] }, { ... "sub_groups" : [] }, ... { ... "sub_groups" : [] } ] }, { }, ... { } ], "selectors": [ { "user": "", "user_group": "", "query_type": "", "source": "", "client_tags": [""], "group": "" }, { }, ... { } ], "cpu_quota_period": "" } ... }, } } ``` Where: * `cluster_id`: Cluster ID. You can get the cluster ID with the [list of clusters](cluster-list.md#list-clusters) in the folder. * `update_mask`: List of parameters to update as an array of strings (`paths[]`). {% cut "Format for listing settings" %} ```yaml "update_mask": { "paths": [ "", "", ... "" ] } ``` {% endcut %} {% note warning %} When you update a cluster, all parameters of the object you are modifying will be reset to their defaults unless explicitly provided in the request. To avoid this, list the settings you want to change in the `update_mask` parameter. {% endnote %} * `root_groups`: Resource group tree description. The `name`, `hard_concurrency_limit`, and `max_queued` settings are required. * `name`: Group name. A group name can be a template that uses variable placeholders in `${}` format. A template name may contain the following types of variables: * Built-in variables. `USER` for username, `SOURCE` for query source. * User-defined variables. These are declared in selector rule properties: `user`, `user_group`, and `source`. When routing queries, Managed Service for Trino will create group instances with dynamically generated names. * `soft_memory_limit`: Maximum amount of memory available to the group. Once this limit is reached, new queries will be queued. You can set `soft_memory_limit` in one of the following ways: * As a percentage of the total available memory, e.g., `10%`. * As an absolute memory value, e.g., `1GB`. You can use one of these suffixes: `B`, `kB`, `MB`, `GB`, `TB`, or `PB`. * `soft_concurrency_limit`: Soft limit on the number of running queries. Once the limit is reached, the group will run new queries only if sibling groups are unable to accept queries or are above their soft limits. Otherwise, new queries will be queued. * `hard_concurrency_limit`: Hard limit on the number of running queries. Once this limit is reached, new queries will be queued. * `soft_cpu_limit`: Soft limit on CPU time. Once this limit is reached, `hard_concurrency_limit` will be reduced until the end of the current CPU quota calculation period. `soft_cpu_limit` cannot be greater than `hard_cpu_limit`. * `hard_cpu_limit`: Hard limit on CPU time. Once this limit is reached, new queries will be queued. {% note info %} If at least one of the two (`soft_cpu_limit` or `hard_cpu_limit`) is specified, make sure to specify `cpu_quota_period` as well. {% endnote %} * `max_queued`: Maximum number of queries per queue. Once this limit is reached, new queries will be rejected with an error. * `scheduling_policy`: [Queue scheduling policy](../concepts/resource-groups.md#policy). The possible values are: * `FAIR` * `WEIGHTED` * `WEIGHTED_FAIR` * `QUERY_PRIORITY` If not specified, the `FAIR` policy will apply. * `scheduling_weight`: Group weight used in the `WEIGHTED` and `WEIGHTED_FAIR` scheduling policies. If not specified, the group weight is `1`. * `sub_groups`: Descriptions of sub-groups. * `selectors`: Selector rule description. The `group` property is required. * `user`: Name of the user who submitted the query or a Java regular expression. The rule applies if the user name matches the regular expression. If not specified, the rule applies to queries from all users. * `user_group`: Name of the user group that submitted the query or a Java regular expression for user groups. The rule applies if the user group name matches the regular expression. If not specified, the rule applies to queries from users of any groups. * `query_type`: Type of the request. The possible values are: * `SELECT`: `SELECT` queries. * `EXPLAIN`: `EXPLAIN` queries, except `EXPLAIN ANALYZE`. * `DESCRIBE`: `DESCRIBE`, `DESCRIBE INPUT`, and `DESCRIBE OUTPUT` queries, as well as `SHOW` queries, e.g., `SHOW CATALOGS` or `SHOW SCHEMAS`. * `INSERT`: `INSERT`, `CREATE TABLE AS`, and `REFRESH MATERIALIZED VIEW` queries. * `MERGE`: `MERGE` queries. * `DELETE`: `DELETE` queries. * `ANALYZE`: `ANALYZE` queries. * `DATA_DEFINITION`: `CREATE`, `ALTER`, and `DROP` queries for schemas, tables, views, and materialized views, as well as queries that manage prepared statements, access permissions, sessions, and transactions. * `ALTER_TABLE_EXECUTE`: `ALTER TABLE ... EXECUTE` queries. * `source`: Query source name or a Java regular expression. The rule applies if the query source name matches the regular expression. If not specified, the rule applies to queries from all sources. * `client_tags`: Tag list. The rule applies only if the query contains all the specified tags. If not specified, the rule applies to queries with any tags. * `group`: Full name of the target resource group. It includes the names of all its parent groups, separated by dots, starting from the root group. A group name can use variable placeholders in `${}` format. A target group cannot have sub-groups. {% note warning %} A query that does not satisfy any of the specified rules is rejected with an error. To avoid this, add to the end of the description a rule without any restrictive conditions, containing only the `group` property. {% endnote %} * `cpu_quota_period`: CPU quota calculation period for resource groups. It takes an integer value in seconds, minutes, or hours, e.g., `140s`, `30m`, or `1h`. For more information about the group tree and selector rules, see [Resource groups in Managed Service for Trino](../concepts/resource-groups.md). 1. Call the [ClusterService.Update](../api-ref/grpc/Cluster/update.md) method, e.g., via the following [gRPCurl](https://github.com/fullstorydev/grpcurl) request: ```bash grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/trino/v1/cluster_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d @ \ trino.api.cloud.yandex.net:443 \ yandex.cloud.trino.v1.ClusterService.Update \ < body.json ``` 1. Check the [server response](../api-ref/grpc/Cluster/update.md#yandex.cloud.operation.Operation) to make sure your request was successful. {% endlist %} ## Deleting a resource group configuration {#delete} {% list tabs group=instructions %} - Management console {#console} 1. In the [management console](https://console.yandex.cloud), navigate to the relevant folder. 1. Navigate to **Managed Service for Trino**. 1. Click the cluster name. 1. Go to the **Resource management** section. 1. To delete resource groups you no longer need: 1. Click ![trash-bin](../../_assets/console-icons/trash-bin.svg) next to the resource group you want to delete. 1. Optionally, delete other resource groups in the same way. 1. To delete selector rules you no longer need: 1. Click ![trash-bin](../../_assets/console-icons/trash-bin.svg) next to the rule you want to delete. 1. Optionally, delete other selector rules in the same way. 1. Click **Save changes**. - CLI {#cli} If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install). The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id ` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions. To delete all resource groups and selector rules, run this command: ```bash yc managed-trino cluster remove-resource-groups ``` You can get the cluster ID and name with the [list of clusters in the folder](cluster-list.md#list-clusters). - Terraform {#tf} 1. Open the current Terraform configuration file with the infrastructure plan. To learn how to create this file, refer to [Creating a cluster](cluster-create.md). 1. To delete all resource groups and selector rules, delete the `resource_groups` parameter from the cluster description. 1. Make sure the settings are correct. 1. In the command line, navigate to the directory that contains the current Terraform configuration files defining the infrastructure. 1. Run this command: ```bash terraform validate ``` Terraform will show any errors found in your configuration files. 1. Confirm updating the resources. 1. Run this command to view the planned changes: ```bash terraform plan ``` If you described the configuration correctly, the terminal will display a list of the resources to update and their parameters. This is a verification step that does not apply changes to your resources. 1. If everything looks correct, apply the changes: 1. Run this command: ```bash terraform apply ``` 1. Confirm updating the resources. 1. Wait for the operation to complete. - REST API {#api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and put it into an environment variable: ```bash export IAM_TOKEN="" ``` 1. Create a file named `body.json` and paste the following code into it: ```json { "updateMask": "trino.resourceManagement.resourceGroups", "trino": { "resourceManagement": { "resourceGroups": {} } } } ``` Where: * `updateMask`: Comma-separated list of parameters to update. {% note warning %} When you update a cluster, all parameters of the object you are modifying will be reset to their defaults unless explicitly provided in the request. To avoid this, list the settings you want to change in the `updateMask` parameter. {% endnote %} * `resourceGroups`: Description of resource groups and selector rules. 1. Call the [Cluster.Update](../api-ref/Cluster/update.md) method, e.g., via the following [cURL](https://curl.se/) request: ```bash curl \ --request PATCH \ --header "Authorization: Bearer $IAM_TOKEN" \ --url 'https://trino.api.cloud.yandex.net/managed-trino/v1/clusters/' --data '@body.json' ``` You can get the cluster ID with the [list of clusters](cluster-list.md#list-clusters) in the folder. 1. Check the [server response](../api-ref/Cluster/update.md#yandex.cloud.operation.Operation) to make sure your request was successful. - gRPC API {#grpc-api} 1. [Get an IAM token for API authentication](../api-ref/authentication.md) and place it in an environment variable: ```bash export IAM_TOKEN="" ``` 1. Clone the [cloudapi](https://github.com/yandex-cloud/cloudapi) repository: ```bash cd ~/ && git clone --depth=1 https://github.com/yandex-cloud/cloudapi ``` Below, we assume that the repository contents reside in the `~/cloudapi/` directory. 1. Create a file named `body.json` and paste the following code into it: ```json { "cluster_id": "", "update_mask": { "paths": [ "trino.resource_management.resource_groups" ] }, "trino": { "resource_management": { "resource_groups": {} } } } ``` Where: * `cluster_id`: Cluster ID. You can get the cluster ID with the [list of clusters](cluster-list.md#list-clusters) in the folder. * `update_mask`: List of parameters to update as an array of strings (`paths[]`). {% cut "Format for listing settings" %} ```yaml "update_mask": { "paths": [ "", "", ... "" ] } ``` {% endcut %} {% note warning %} When you update a cluster, all parameters of the object you are modifying will be reset to their defaults unless explicitly provided in the request. To avoid this, list the settings you want to change in the `update_mask` parameter. {% endnote %} * `resource_groups`: Description of resource groups and selector rules. 1. Call the [ClusterService.Update](../api-ref/grpc/Cluster/update.md) method, e.g., via the following [gRPCurl](https://github.com/fullstorydev/grpcurl) request: ```bash grpcurl \ -format json \ -import-path ~/cloudapi/ \ -import-path ~/cloudapi/third_party/googleapis/ \ -proto ~/cloudapi/yandex/cloud/trino/v1/cluster_service.proto \ -rpc-header "Authorization: Bearer $IAM_TOKEN" \ -d @ \ trino.api.cloud.yandex.net:443 \ yandex.cloud.trino.v1.ClusterService.Update \ < body.json ``` 1. Check the [server response](../api-ref/grpc/Cluster/update.md#yandex.cloud.operation.Operation) to make sure your request was successful. {% endlist %} ## Example of a resource group configuration in a Managed Service for Trino cluster {#example} This example uses the following resource groups: * `global`: Root group that sets the general `hardConcurrencyLimit` and `maxQueued` limits. The `global` group contains sub-groups `adm`, `bi`, `etl`, and `adhoc`. * `adm`: Group for administrator queries and `DATA_DEFINITION` queries. High `schedulingWeight` values make it less probable that such queries will be blocked by user load. * `bi`: Group for queries to business analytics systems. This group uses the `softMemoryLimit` limit for queries not to take up too much memory and not to force other query types out. Within this group, for each tool, a sub-group instance is created with a dynamically generated name. Within each tool's group, sub-group instances are created for each user. This sets a separate limit for each tool and user. This limits the mutual impact between queries originating from different users and tools. * `etl`: Group for data retrieval, transformation, and upload queries. This group uses the `softCpuLimit` and `hardCpuLimit` limits for CPU time consumed by queries. * `adhoc`: Group for interactive user queries. Within this group, for each user, a sub-group instance is created with a dynamically generated name. This sets a separate limit for each user thus limiting the mutual impact between queries originating from different users. Queries are distributed between the `adm`, `bi`, `etl`, and `adhoc` groups as per the `weighted_fair` scheduling policy. The `schedulingWeight` parameter is not specified for the `adhoc` group; therefore, `1` (default) is used. No scheduling policy is specified for the `bi` and `adhoc` groups; therefore, queries are distributed between their sub-groups as per the default policy named `fair`. The following selector rules are used to send queries to the groups: 1. Queries of users from the `admins` group are sent to the `global.adm` resource group. 1. Queries with the `etl_job` tag are sent to the `global.etl` group. 1. The `DATA_DEFINITION` type queries are sent to the `global.adm` resource group. This ensures that queries used to call the `system.runtime.kill_query()` procedure will not wait for other user queries to complete. 1. The `SELECT` type queries from a source with a name formatted as `jdbc#(?[^#]+)` go to the `global.bi.${toolname}.${USER}` template group. For example, a query by the user `bob` from the source `jdbc#grafana` will go to a group instance named `global.bi.grafana.bob`. 1. All other queries are sent to the `global.adhoc.${USER}` template group. For example, a query by the user `bob` will be sent to the group instance named `global.adhoc.bob`. {% list tabs group=instructions %} - CLI {#cli} `resource-groups.json` for this example: ```json { "rootGroups": [ { "name": "global", "hardConcurrencyLimit": 20, "maxQueued": 200, "schedulingPolicy": "weighted_fair", "subGroups": [ { "name": "adm", "hardConcurrencyLimit": 5, "maxQueued": 50, "schedulingWeight": 5 }, { "name": "bi", "hardConcurrencyLimit": 10, "softMemoryLimit": "20%", "maxQueued": 100, "schedulingWeight": 3, "subGroups": [ { "name": "${toolname}", "hardConcurrencyLimit": 5, "maxQueued": 50, "subGroups": [ { "name": "${USER}", "hardConcurrencyLimit": 2, "maxQueued": 20 } ] } ] }, { "name": "etl", "hardConcurrencyLimit": 5, "softCpuLimit": "20s", "hardCpuLimit": "40s", "maxQueued": 50, "schedulingWeight": 1 }, { "name": "adhoc", "hardConcurrencyLimit": 5, "maxQueued": 100, "subGroups": [ { "name": "${USER}", "hardConcurrencyLimit": 2, "maxQueued": 20 } ] } ] } ], "selectors": [ { "userGroup": "admins", "group": "global.adm" }, { "clientTags": ["etl_job"], "group": "global.etl" }, { "queryType": "DATA_DEFINITION", "group": "global.adm" }, { "source": "jdbc#(?[^#]+)", "queryType": "SELECT", "group": "global.bi.${toolname}.${USER}" }, { "group": "global.adhoc.${USER}" } ], "cpuQuotaPeriod": "1m" } ``` - Terraform {#tf} `resource-groups.json` for this example: ```json { "rootGroups": [ { "name": "global", "hardConcurrencyLimit": 20, "maxQueued": 200, "schedulingPolicy": "weighted_fair", "subGroups": [ { "name": "adm", "hardConcurrencyLimit": 5, "maxQueued": 50, "schedulingWeight": 5 }, { "name": "bi", "hardConcurrencyLimit": 10, "softMemoryLimit": "20%", "maxQueued": 100, "schedulingWeight": 3, "subGroups": [ { "name": "${toolname}", "hardConcurrencyLimit": 5, "maxQueued": 50, "subGroups": [ { "name": "${USER}", "hardConcurrencyLimit": 2, "maxQueued": 20 } ] } ] }, { "name": "etl", "hardConcurrencyLimit": 5, "softCpuLimit": "20s", "hardCpuLimit": "40s", "maxQueued": 50, "schedulingWeight": 1 }, { "name": "adhoc", "hardConcurrencyLimit": 5, "maxQueued": 100, "subGroups": [ { "name": "${USER}", "hardConcurrencyLimit": 2, "maxQueued": 20 } ] } ] } ], "selectors": [ { "userGroup": "admins", "group": "global.adm" }, { "clientTags": ["etl_job"], "group": "global.etl" }, { "queryType": "DATA_DEFINITION", "group": "global.adm" }, { "source": "jdbc#(?[^#]+)", "queryType": "SELECT", "group": "global.bi.${toolname}.${USER}" }, { "group": "global.adhoc.${USER}" } ], "cpuQuotaPeriod": "1m" } ``` - REST API {#api} `body.json` for this example: ```json { "updateMask": "trino.resourceManagement.resourceGroups", "trino": { "resourceManagement": { "resourceGroups": { "rootGroups": [ { "name": "global", "hardConcurrencyLimit": "20", "maxQueued": "200", "schedulingPolicy": "weighted_fair", "subGroups": [ { "name": "adm", "hardConcurrencyLimit": "5", "maxQueued": "50", "schedulingWeight": "5" }, { "name": "bi", "hardConcurrencyLimit": "10", "softMemoryLimit": "20%", "maxQueued": "100", "schedulingWeight": "3", "subGroups": [ { "name": "${toolname}", "hardConcurrencyLimit": "5", "maxQueued": "50", "subGroups": [ { "name": "${USER}", "hardConcurrencyLimit": "2", "maxQueued": "20" } ] } ] }, { "name": "etl", "hardConcurrencyLimit": "5", "softCpuLimit": "20s", "hardCpuLimit": "40s", "maxQueued": "50", "schedulingWeight": "1" }, { "name": "adhoc", "hardConcurrencyLimit": "5", "maxQueued": "100", "subGroups": [ { "name": "${USER}", "hardConcurrencyLimit": "2", "maxQueued": "20" } ] } ] } ], "selectors": [ { "userGroup": "admins", "group": "global.adm" }, { "clientTags": ["etl_job"], "group": "global.etl" }, { "queryType": "DATA_DEFINITION", "group": "global.adm" }, { "source": "jdbc#(?[^#]+)", "queryType": "SELECT", "group": "global.bi.${toolname}.${USER}" }, { "group": "global.adhoc.${USER}" } ], "cpuQuotaPeriod": "1m" } } } } ``` - gRPC API {#grpc-api} `body.json` for this example: ```json { "cluster_id": "", "update_mask": { "paths": [ "trino.resource_management.resource_groups" ] }, "trino": { "resource_management": { "resource_groups": { "root_groups": [ { "name": "global", "hard_concurrency_limit": "20", "max_queued": "200", "scheduling_policy": "weighted_fair", "sub_groups": [ { "name": "adm", "hard_concurrency_limit": "5", "max_queued": "50", "scheduling_weight": "5" }, { "name": "bi", "hard_concurrency_limit": "10", "soft_memory_limit": "20%", "max_queued": "100", "scheduling_weight": "3", "sub_groups": [ { "name": "${toolname}", "hard_concurrency_limit": "5", "max_queued": "50", "sub_groups": [ { "name": "${USER}", "hard_concurrency_limit": "2", "max_queued": "20" } ] } ] }, { "name": "etl", "hard_concurrency_limit": "5", "soft_cpu_limit": "20s", "hard_cpu_limit": "40s", "max_queued": "50", "scheduling_weight": "1" }, { "name": "adhoc", "hard_concurrency_limit": "5", "max_queued": "100", "sub_groups": [ { "name": "${USER}", "hard_concurrency_limit": "2", "max_queued": "20" } ] } ] } ], "selectors": [ { "user_group": "admins", "group": "global.adm" }, { "client_tags": ["etl_job"], "group": "global.etl" }, { "query_type": "DATA_DEFINITION", "group": "global.adm" }, { "source": "jdbc#(?[^#]+)", "query_type": "SELECT", "group": "global.bi.${toolname}.${USER}" }, { "group": "global.adhoc.${USER}" } ], "cpu_quota_period": "1m" } } } } ``` {% endlist %}