ApsaraDB for SelectDB Serverless automatically scales resources based on your workload, eliminating the need for server management. You pay only for the resources you use. This approach prevents performance bottlenecks during peak business hours and reduces costs associated with idle resources during off-peak times. This lets you focus on core business tasks, such as data processing and analytics.
ApsaraDB for SelectDB Serverless is in public preview. To use this feature, submit a form to apply for access.
Automatic elastic scaling
Resource usage comparison
When business workloads fluctuate significantly, the compute resource specifications for standard ApsaraDB for SelectDB instances and ApsaraDB for SelectDB Serverless instances change as follows.
| The figure shows the following:
|
Scenarios
Analytics scenarios with significant fluctuations in business workload. For example, BI report generation and user behavior analysis, characterized by clear cycles in access volume and compute load.
Businesses that want to reduce operations and maintenance (O&M) workload and resource costs. For example, companies with rapid growth or unpredictable workloads that want to improve O&M efficiency, reduce resource costs, and respond to business needs more quickly.
Temporary data tasks. For example, staging environments with infrequent resource usage, or unpredictable data analytics tasks where query complexity and resource consumption are difficult to estimate.
Elastic scaling mechanism
In ApsaraDB for SelectDB Serverless, the elastic scaling mechanism is the core capability for on-demand resource allocation and cost optimization. It is determined by both built-in elastic rules and your configured resource scaling range. By combining predefined elastic rules with business workload metrics, such as CPU usage and memory usage, the elastic scaling mechanism intelligently determines when to increase or decrease resources. This dynamic adjustment ensures sufficient resource support during peak business hours and automatically releases idle resources during off-peak periods. This reduces costs and improves resource utilization.
Before configuring the elastic scaling mechanism for ApsaraDB for SelectDB Serverless, you must first understand the core components of an ApsaraDB for SelectDB instance:
Component | Description |
Instance endpoint | Receives requests. It is managed and elastically scaled on demand by ApsaraDB for SelectDB. You do not need to manage it. |
Cluster | A distributed system that executes requests. Each cluster contains one or more BE nodes. Each node includes compute and cache resources. |
Storage | Provides storage resources for data services at the instance level. It is measured in GB, used elastically on demand, and requires no management. |
An ApsaraDB for SelectDB instance can contain multiple clusters. Because different business workloads have varying patterns and scaling needs, ApsaraDB for SelectDB Serverless lets you set a separate elastic scaling range for each cluster. This allows for more granular resource management and cost control. The elastic scaling mechanism within a cluster mainly involves configuration rules for compute and cache resources. The configuration methods are described in the following sections.
Compute resource
Unit
SCU (SelectDB Computing Unit): The unit for elastic compute resources in ApsaraDB for SelectDB Serverless. 1 SCU corresponds to the service capability of 1 core and 4 GB of memory.
Elastic rules
Elastic rule
Trigger condition
Elastic policy
BE pop-up
One of the following conditions is met:
The average CPU usage over 5 seconds exceeds 60%.
The memory usage within 1 second exceeds 60%.
Resources after scale-out = MIN(Actual resource usage that triggered the scale-out / 45%, Predefined upper limit for SCU)
BE scale-in
Both of the following conditions are met and persist for 1 minute:
CPU usage < 30%
Memory usage < 30%
Resources after scale-in = MAX(Actual resource usage that triggered the scale-in / 45%, Predefined lower limit for SCU)
NoteTo prevent resource fluctuations, the scale-in process is performed gradually with a step size of 1 CCU, instead of all at once.
Set the elastic range
The cluster automatically scales up or down based on elastic rules. To prevent continuous resource scaling or runaway costs from unusually large requests, you can set the number of workers and node specifications to control the cluster's scaling range.
Number of workers: The number of workers is customizable. When you add or remove cluster nodes, requests may be routed to new nodes, which can decrease the cache hit ratio and cause query performance fluctuations.
Node specifications: You can set the upper and lower elastic limits for a single compute node. During vertical scaling, the cluster scales up or down within this range.
Cache resource
Single-node cache capacity: You can set the cache size for a single node. The cache capacity for a single node must be between 100 GB and 10 TB, inclusive.
Cluster cache capacity: Cluster cache capacity = Single-node cache capacity × Number of nodes. When the number of cluster nodes changes, the cluster cache capacity changes accordingly.
References
For more information about creating and managing ApsaraDB for SelectDB Serverless instances, see the referenced document.