ApsaraDB for ClickHouse Enterprise Edition is a managed cloud service built on open source ClickHouse. Its architecture differs from self-managed ClickHouse in ways that reduce operational overhead — and those differences affect which features and syntax are available. You can visit the official ClickHouse website to obtain background information about ClickHouse Cloud. This topic covers the architectural model and compatibility details you need before migrating.
Architecture
ApsaraDB for ClickHouse Enterprise Edition separates compute from storage and manages replication automatically, so you don't have to deploy a fixed-size cluster, configure replicas for high availability, or shard data manually.
The architecture delivers the following:
Compute-storage separation: Compute and storage scale independently, so you don't have to over-provision either resource when configuring a static instance.
Tiered storage with multi-level caching: Object storage provides virtually unlimited capacity with high cost efficiency, so you don't need to size a storage partition in advance or worry about high storage costs.
High availability by default: Replication is managed transparently, so you can focus on building applications or analyzing data.
Automatic scaling for variable workloads: The service scales compute up when your workload increases and scales down when it decreases, so you don't need to predict server size in advance.
Advanced scaling controls: Set an auto-scaling maximum for cost control, or an auto-scaling minimum to reserve compute capacity for performance-sensitive workloads.
Compatibility
DDL syntax
In most cases, DDL syntax in ApsaraDB for ClickHouse Enterprise Edition matches self-managed ClickHouse. The following exceptions apply:
CREATE AS SELECTis not supported. UseCREATE ... EMPTY ... AS SELECTinstead, then insert data separately. For details, see Getting Data Into ClickHouse - Part 1.Some experimental DDL syntax is not supported, such as
ALTER TABLE … MODIFY QUERY.Some functions are disabled for security reasons, such as the
addressToLineSQL function.The
ON CLUSTERparameter is not supported.
Database and table engines
ApsaraDB for ClickHouse Enterprise Edition provides high availability by default. When you create a table using a standard MergeTree engine name, the service automatically uses the corresponding Shared* equivalent.
The following Shared* engines are natively supported:
| Engine | Notes |
|---|---|
| SharedMergeTree | Default when no engine is specified |
| SharedSummingMergeTree | |
| SharedAggregatingMergeTree | |
| SharedReplacingMergeTree | |
| SharedCollapsingMergeTree | |
| SharedVersionedCollapsingMergeTree |
Standard MergeTree engine names are automatically converted:
| Engine specified | Engine used |
|---|---|
| MergeTree | SharedMergeTree |
| SummingMergeTree | SharedSummingMergeTree |
| AggregatingMergeTree | SharedAggregatingMergeTree |
| ReplacingMergeTree | SharedReplacingMergeTree |
| CollapsingMergeTree | SharedCollapsingMergeTree |
| VersionedCollapsingMergeTree | SharedVersionedCollapsingMergeTree |
The following additional engines are also supported: URL, View, MaterializedView, GenerateRandom, Null, Buffer, Memory, Deltalake, Hudi, MySQL, MongoDB, NATS, PostgreSQL, Kafka, and S3.
Because high availability is built in, you don't need a distributed table engine. Table creation is simplified accordingly.
Dictionaries
ApsaraDB for ClickHouse Enterprise Edition supports dictionaries sourced from PostgreSQL, MySQL, remote and local ClickHouse servers, Redis, MongoDB, and HTTP sources. Dictionaries speed up lookups in ClickHouse.
Federated queries
ApsaraDB for ClickHouse Enterprise Edition supports federated queries for cross-cluster communication within the cloud and with external self-managed ClickHouse clusters.
Supported integration engines: Deltalake, Hudi, MySQL, MongoDB, NATS, PostgreSQL, and OSS.
Federated queries are not supported for the following engines: SQLite, ODBC (Open Database Connectivity), JDBC (Java Database Connectivity), Redis, RabbitMQ, HDFS (Hadoop Distributed File System), and Hive.
Experimental features
Experimental features cover new SQL syntax, query optimizations, and performance improvements that are still being validated. They can be enabled in development environments.
In production, experimental features are disabled by default to preserve stability. To enable an experimental feature in production, contact Alibaba Cloud technical support to verify the feature won't affect your environment.
Default operational settings
Limits settings
`max_parts_in_total`: lowered from 100,000 to 10,000
The default value of max_parts_in_total for MergeTree tables has been reduced from 100,000 to 10,000. A large number of data parts causes slow service startup in the cloud — and typically indicates a partition key that is too granular, which is usually accidental and should be avoided. If you hit this limit, check whether your partition key produces more granularity than your queries require. Lowering this default makes it easier to catch over-partitioned tables early.
System settings
ApsaraDB for ClickHouse Enterprise Edition is tuned for variable workloads. Most system settings are not user-configurable. If you need advanced system tuning, contact Alibaba Cloud technical support.