Compute Group Architecture for Workload Isolation - ApsaraDB for ClickHouse

A compute group isolates compute resources within a single cluster. Each compute group has its own endpoint and compute resources. This lets you isolate and independently scale different workloads. It is suitable for scenarios such as read/write splitting and business resource isolation. This design ensures the stability of core services and improves cluster resource management efficiency.

Function Overview

The separation of compute resources lets you create multiple independent compute groups in a single Enterprise Edition cluster. Each compute group has its own endpoint, CPU, memory, and local cache. This feature provides the following core capabilities:

Compute resource isolation: The compute resources of different compute groups are isolated and do not affect each other. You can run data writes and queries independently on each compute group.
Independent scaling: You can adjust the resource scaling range for each compute group independently. Resources scale automatically based on CPU and memory load.
Independent O&M: You can view resource load monitoring, configure alert policies, and manage query analysis at the compute group level.
Independent read/write permission management: You can configure read/write (RW) or read-only (RO) permissions for individual compute groups. The default compute group always has RW permissions.
Shared storage: All compute groups in a cluster share the same data, which reduces storage costs.

Limits

This feature is available only for ApsaraDB for ClickHouse Enterprise Edition clusters that use the OSS storage class.
This feature is not currently available in the US (Virginia) and US (Silicon Valley) regions.

O&M feature support

Important

When you use Kafka external tables, the tables consume data on every node in the cluster. Because a read-only compute group cannot perform write operations, its presence can trigger a rebalance that slows down data consumption.

O&M feature	Supported at cluster level	Supported at compute group level	Notes
Modify endpoint	Yes	Yes	None.
Creating a public network	Yes	Yes	None.
Release public endpoint	Yes	Yes	None.
Adjust scaling configuration	Yes	Yes	None.
Query management	Yes	Yes	None.
Restart cluster	Yes	Yes	If a compute group has only one node, the group is unavailable during the restart.
View monitoring	Yes	Yes	None.
Configure alerting	Yes	Yes	Preset alert templates can only filter nodes of the default compute group. To create alerts for other compute groups, you must write custom PromeSQL queries.
Modify parameters	Yes	No	Parameter modifications apply to the entire cluster.
Data security management	Yes	No	Whitelists are synchronized and take effect across all compute groups.
DMS data management	Yes	No	You can currently connect only to the default compute group.
DTS data transmission link	Yes	No	You can currently connect only to the default compute group.
One-stop observability	Yes	No	You can currently connect only to the default compute group.
Upgrade kernel version	Yes	No	All compute groups in the cluster are upgraded in parallel. Important If a compute group has only one node, the group is unavailable during the upgrade.
Pause instance	Yes	No	Pausing an instance pauses all compute groups within that instance.
Start instance	Yes	No	Starting an instance starts all compute groups within that instance.
User management	Yes	No	User creation and authorization operations are synchronized across all compute groups.
Database management	Yes	No	Database operations are synchronized across all compute groups.

How to use

You can create and configure compute groups based on your workload and read/write requirements. Then, use the endpoint provided by the compute group to connect to the instance. Requests sent to different endpoints are processed in isolation on the compute nodes.

DML operations: Data Manipulation Language (DML) operations, such as INSERT and SELECT, are executed in isolation within each compute group.
DDL operations: Data Definition Language (DDL) operations, such as ALTER, CREATE, and DROP, are distributed to all compute groups for execution.

For more information about how to create and manage compute groups, see Compute group operations.