All Products
Search

This Product

    ApsaraDB for ClickHouse:Serverless capabilities for ApsaraDB for ClickHouse Enterprise Edition

    Document Center

    ApsaraDB for ClickHouse:Serverless capabilities for ApsaraDB for ClickHouse Enterprise Edition

    Last Updated:Jan 16, 2025

    ApsaraDB for ClickHouse Enterprise Edition uses the compute-storage separation architecture to provide serverless capabilities, which allow computing resources of clusters to be dynamically scaled based on your business loads. In scenarios in which business loads significantly fluctuate, the serverless capabilities of ApsaraDB for ClickHouse Enterprise Edition help you reduce resource usage during off-peak hours. This way, the overall cost of resource procurement is reduced. This topic describes the serverless capabilities of ApsaraDB for ClickHouse Enterprise Edition clusters, serverless policies, and usage scenarios.

    Feature description

    Computing resources

    The billing unit of computing resources in an ApsaraDB for ClickHouse cluster is ClickHouse Compute Unit (CCU). 1 CCU is equivalent to 1 virtual CPU (vCPU) and 4 GiB of memory.

    For an Enterprise Edition cluster, computing resources can be scaled within the specified scaling range based on actual business loads. The minimum scaling step size is 1 CCU.

    The following figure shows the resource usage and specification changes of clusters with defined specifications and Enterprise Edition clusters in scenarios where business loads greatly fluctuate. Clusters with defined specifications have the following disadvantages: A large number of resources are wasted during off-peak hours. Resources are insufficient during peak hours, which affects service performance. Enterprise Edition clusters have the following advantages:

    • Resources can be dynamically scaled based on business requirements. This reduces the O&M workload.

    • The overall resource utilization is improved. This reduces resource procurement costs.

    • During peak hours, resources are scaled out within seconds without impact on your business. This improves system stability.

    image

    Storage resources

    Enterprise Edition uses Object Storage Service (OSS) to implement shared storage. In serverless mode, storage resources are billed by using the pay-as-you-go billing method. You do not need to purchase disks in advance.

    Scenarios

    • Your business has obvious peak hours and off-peak hours.

    • Intermittent business spikes require frequent changes to cluster configurations.

    • The loads are unpredictable, as seen in the Internet of Things (IoT) and edge computing scenarios.

    • O&M costs are expected to be reduced, and O&M efficiency is expected to be improved.

    Fees

    The fees of ApsaraDB for ClickHouse Enterprise Edition clusters consist of the fees of computing resources and the fees of storage resources. For more information, see Pay-as-you-go billing for ApsaraDB for ClickHouse Enterprise Edition.

    You can also purchase resource plans to offset the resource consumption of clusters. This helps further reduce your costs. For more information about the billing rules and purchase of resource plans, see Resource plan.

    Trigger conditions for auto scaling of serverless resources

    ApsaraDB for ClickHouse Enterprise Edition provides the conservative and aggressive serverless policies.

    Note

    • The scaling of an ApsaraDB for ClickHouse cluster does not change the number of nodes in the cluster when the maximum CCU remains unchanged. The number of nodes in a cluster depends only on the maximum CCU of the cluster. If the maximum CCU of an ApsaraDB for ClickHouse Enterprise Edition cluster is larger than 64, the number of nodes in the cluster can be calculated by the following formula: Maximum CCU/32. For a cluster whose maximum CCU is equal to or less than 64, the cluster contains two nodes.

    • Necessary metadata is stored in the memory of each node in the cluster. Therefore, if you change the maximum CCU of a cluster, the memory usage and CCU usage of the cluster may change because the number of nodes in the cluster varies with the maximum CCU.

    Serverless policy

    Enabling method

    Scale-out

    Scale-in

    Type: conservative.

    Application scenarios:

    • Resource usage is lower than 30% during off-peak hours.

    • The differences in resource usage between peak and off-peak hours are large.

    • High business stability is required.

    By default, the conservative serverless policy is used when you create a cluster.

    • Trigger conditions (a scale-out can be triggered when any one of the following conditions is met):

      • The average CPU utilization exceeds 60% for 5 consecutive seconds.

      • The memory usage exceeds 60% for 1 second.

    • Result: Amount of computing resources allocated = MIN(The actual resource usage divided by 45%, The predefined upper limit for scaling). The actual resource usage is the resource usage of your cluster that triggers the scale-out.

    Note

    The actual resource usage = MAX(CPU utilization x CCU, memory usage x CCU)

    • Trigger conditions (a scale-in can be triggered when all the following conditions are met):

      • The CPU utilization is less than 30% for 60 consecutive seconds.

      • The memory usage is less than 30% for 60 consecutive seconds.

      • The amount of resources for the current cluster is greater than the predefined lower limit for scaling.

    • Method: Resources are gradually scaled in by decrements of 1 CCU, rather than being reduced to the desired value at once.

    • Result: Amount of computing resources allocated = MAX(The number of CCUs required to keep CPU utilization at 30%, The number of CCUs required to keep memory usage at 30%, The predefined lower limit for scaling).

    Type: aggressive.

    Application scenarios:

    • The resource usage is greater than 30% during off-peak hours.

    • You have a strong demand for cost reduction.

    You can submit a ticket to enable the whitelist feature.

    Important

    After you enable the aggressive policy, the performance and stability of your cluster may be affected. Proceed with caution.

    • Impact on performance: The cluster will trigger the scale-in of computing resources and release the locks of node caches more frequently. This affects the cache hit ratio.

    • Impact on stability: Increasing the scaling threshold and decreasing the scaling step size may result in a longer scale-out time and more memory limit exceptions.

    • Trigger conditions (a scale-out can be triggered when any one of the following conditions is met):

      • The average CPU utilization exceeds 90% for 5 consecutive seconds.

      • The memory usage exceeds 80% for 1 second.

    • Result: Amount of computing resources allocated = MIN(The actual resource usage divided by 45%, The predefined upper limit for scaling). The actual resource usage is the resource usage of your cluster that triggers the scale-out.

    Note

    The actual resource usage = MAX(CPU utilization x CCU, memory usage x CCU)

    • Trigger conditions (a scale-in can be triggered when all the following conditions are met):

      • The CPU utilization is less than 80% for 15 consecutive seconds.

      • The memory usage is less than 75% for 15 consecutive seconds.

    • Method: Resources are gradually scaled in by decrements of 1 CCU, rather than being reduced to the desired value at once.

    • Result: Amount of computing resources allocated = MAX(The number of CCUs required to keep CPU utilization at 80%, The number of CCUs required to keep memory usage at 75%, The predefined lower limit for scaling).

    What to do next