Traditional cloud data warehouses buy resources based on peak values and spend 70% of their idle time idling. SelectDB Serverless completely separates the three layers of computing, caching, and storage. It can automatically scale with an elastic range, and the elasticity can be reduced from 10 minutes to seconds. This article configures a Serverless instance from scratch and measures the elasticity effect.
keywords: SelectDB · Serverless · Cloud data warehouse elasticity · Second-level scaling · Cost reduction · Pay As You Go · Alibaba Cloud
Question: Why is 70% of your cloud data warehouse bill wasted?
Suppose your team uses a cloud data warehouse to support BI reports. The query peak is between 9 and 11 am every day, requiring 64 core computing resources. The other 20 hours are low load and 8 cores are enough. In the traditional fixed specification model, you can only buy by 64 cores——In the remaining 20 hours, 56 cores are idling, and the resource utilization rate is less than 30%..
In addition, when encountering temporary large queries or burst traffic, the expansion of traditional cloud data warehouses takes 10 minutes to hours (node startup + cache warm-up). During this period, query delays soar, and may even trigger an avalanche.
The design idea of SelectDB Serverless is very simple:Let the resources follow the load, make up for the peaks, release them during the valleys, and charge based on actual usage..
Step 1: Understand three-layer decoupling—why "elasticity" requires three layers
Traditional storage and computing separation architectures (such as Snowflake) have separated computing and storage, butThe cache is still tied to the compute node——A fixed number of cores corresponds to a fixed-capacity local SSD. Want to increase the cache and improve the hit rate? Sorry, you have to upgrade the computing specifications at the same time, which is equivalent to paying for unnecessary computing power.
The approach of SelectDB Serverless is to disassemble all three layers:
Traditional architecture: after three-layer decoupling:
┌─────────────────┐ ┌──────────┐
│ Compute Node │ │ Compute │ ← According to actual CPU Usage elasticity
│ ┌───────────┐ │ ├──────────┤
│ │ Cache │ │ → │ Cache │ ← Independent flexibility, no longer tied to calculations
│ ├───────────┤ │ ├──────────┤
│ │ Storage │ │ │ Storage │ ← Scale according to actual data volume
│ └───────────┘ │ └──────────┘
└─────────────────┘
This means:
- The computing layer scales independently during capacity expansion.Does not affect cache hit rate(Because the cache has not changed)
- Want to increase cache capacity and improve hot data hit rate? Add cache directly,No need to pay for additional calculations
- The storage is based on the actual data volume. If you delete the data, the bill will be automatically reduced.
Step 2: Assign elastic range - only one min/max is needed
When creating an instance in the SelectDB Serverless console, you only need to set a flexible range, such as:
Calculate elastic range: 8 CCU ~ 128 CCU
The rest is fully automatic. The system will make decisions based on the following rules:
Expansion trigger:
CPU: 5second average > 60% # Once a sustained high load is detected, trigger immediately
Memory: instantaneous utilization > 60% # It can also respond promptly to memory-sensitive scenarios.
Shrink trigger:
CPU: < 30% # Two indicators are satisfied at the same time
Memory: < 30% # and continue 1 It will start to shrink after more than a few minutes
Strategy: Progressive scaling # Avoid frequent jitter
The design principles are clear:Expansion must be decisive and reduction must be steady..
In addition to simple threshold rules, the system also has a layer AI-assisted decision-making——When the elastic request is triggered, AI will combine historical load patterns, cycle characteristics and current resource levels to determine whether the expansion/reduction is reasonable. Compared with the pure rule strategy, the elastic accuracy is increased by 40%.
What scenarios can trigger how much elasticity?
| scene | peak | Trough value | elasticity multiple | Suitable for Serverless? |
|---|---|---|---|---|
| Business Day BI Report | AM 64 Core | Night 8 core | 8x | ✅ Typical scenarios |
| ToC day and night traffic | Daytime 128 cores | 8 AM Core | 16x | ✅ Direct cap |
| Big sale flash sale | Activity 256 Core | Daily 32 cores | 8x | ⚠️ More than 16 times requires horizontal orientation |
| Stable ETL | 32 cores all day | 32 cores | 1x | ❌ Annual and monthly subscriptions are more cost-effective |
Step 3: Verify the elasticity effect - a complete expansion and contraction process
Expansion (low load → high load)
Trigger condition: CPU 5-second average exceeds 60% Action: The system is expanded vertically in place, and the computing specifications are adjusted in real time. Time consuming: seconds Impact: Query being executed is not affected (in-place scaling + continuous connection)
-- Simulate high load: run large queries concurrently, CPU hold on until 70%
-- Observable on the console CCU from 8 Automatically upgrade to 24 → 48 → Continue to upgrade as needed
Shrinking (high load → low load)
Trigger condition: CPU and memory are below 30% at the same time for 1 minute Action: Progressive reduction and gradual release of computing resources Time-consuming: Progressive (not falling to the bottom value all at once) Impact: Queries are not affected
Extreme scenarios (peak-to-valley ratio > 16x)
The upper limit of vertical elasticity is 16 times that of a single cluster. When scenes such as big sales exceed this range, it takes about 3 minutes to achieve horizontal elasticity (increase the number of nodes) through the console. The query delay fluctuates slightly but is generally controllable.
Cost Calculation: Serverless vs Annual and Monthly Subscription
Go back to the beginning and make a simple estimate of the 64-core BI scenario:
peak period: 4 Hour/sky × 64 CCU
Off-peak period: 6 Hour/sky × 16 CCU
low period: 14 Hour/sky × 8 CCU → this 14 Hourly original plan according to 64 CCU Pay
elastic release = (64-8) / 64 = 87.5% >>> 28% critical point
When elastically releasable computing resources exceed 28% At this time, Serverless pay-as-you-go pricing begins to outperform annual and monthly subscriptions. 87.5% far exceeds this threshold, and the cost reduction effect is significant.
Of course, if your load is stable at 32 cores for a long time and the peak-to-trough difference is almost zero, then annual and monthly subscriptions are more economical. Serverless is not a panacea, but the more obvious the peaks and valleys, the better it is.
Cache independent configuration - an easily overlooked saving point
In a three-tier decoupled architecture, caches can be configured independently. In an actual scenario, your query may only rely on 200GB of hot data, but the computing specifications are set at 128 cores by peak demand. Under the traditional architecture, the cache follows the calculation, and you can only accept the cache capacity corresponding to 128 cores (which may far exceed actual needs).
SelectDB Serverless allows youReduce computing specifications while maintaining or even increasing cache capacity, match the actual hot data volume and query concurrency, and further optimize the cost structure.
What kind of team is it suitable for?
- BI team: Concentrated query during working days, almost no load at night/weekends, and extremely high elastic release ratio
- AI Agent Platform: The query load is completely unpredictable, and model calls may burst at any time.
- A data team that doesn’t want to take care of operations and maintenance: Only elastic ranges are set, and expansion and contraction are fully managed.
- Cost-sensitive startups: Pay what you use, no sunk costs
About Apache Doris: Apache Doris is a high-performance real-time analytics database. SelectDB Serverless is built based on the Doris kernel and has been officially commercialized on Alibaba Cloud.SelectDB Provides enterprise-grade support. Welcome to join Doris community.