This topic describes the terms used in ApsaraDB for ClickHouse. This helps you understand ApsaraDB for ClickHouse.

region

A region is the geographic location where the server that runs your ApsaraDB for ClickHouse cluster resides. You must specify a region when you create an ApsaraDB for ClickHouse cluster. The region cannot be changed after the cluster is created.

zone

Zones are physical areas within a region. Each zone has an independent power grid and network. Zones are interconnected over an internal network. If clusters reside in the same zone, clusters can communicate with each other at a low network latency.

ApsaraDB for ClickHouse cluster

An ApsaraDB for ClickHouse cluster is a distributed database that runs on multiple physical ClickHouse servers. A ClickHouse server can have one or more replicas and one or more shards based on different specifications. An ApsaraDB for ClickHouse cluster can contain multiple logical database objects.

edition

ApsaraDB for ClickHouse provides the following cluster editions:
  • Double-replica Edition: For ApsaraDB for ClickHouse of the Double-replica Edition, each shard has a replica. If a shard fails, its replica can take over services from the failed shard.
  • Single-replica Edition: For ApsaraDB for ClickHouse of the Single-replica Edition, each shard has no replica. If a shard in a cluster fails, the entire cluster becomes unavailable. The cluster cannot provide stable services until the shard is recovered.
Note
  • The number of resources that an ApsaraDB for ClickHouse cluster of the Double-replica Edition requires is twice the number of resources that an ApsaraDB for ClickHouse cluster of the Single-replica Edition requires. An ApsaraDB for ClickHouse cluster of the Double-replica Edition costs twice as much as an ApsaraDB for ClickHouse cluster of the Single-replica Edition.
  • An ApsaraDB for ClickHouse cluster of the Single-replica Edition uses highly reliable disks to avoid data losses.

shard

In scenarios in which a large amount of data needs to be processed, the storage and computing resources of a single server may cause performance bottlenecks. To make data processing efficient, ApsaraDB for ClickHouse distributes a large amount of data to multiple servers. Each server stores and processes only part of the data. In this architecture, each server is called a shard.

replica

To ensure data security and high availability if an error occurs, ApsaraDB for ClickHouse provides replicas. Data on a server can be replicated to one or more servers.

database

A database is the object of the highest level in an ApsaraDB for ClickHouse cluster. A database can contain objects such as tables, columns, views, functions, and data types.

table

A table consists of rows and columns. Data is organized in a table.

Tables in ApsaraDB for ClickHouse can be divided into local tables and distributed tables based on data distribution.
TypeDescriptionDifference
local tableWhen you write data to a local table, the data is written only to the server that stores the local table and cannot be distributed to other servers.
  • Local tables do not support horizontal scaling. When you write data to a local table or query data from a local table, the performance is limited by the storage and computing resources of a single server.
  • Distributed tables support horizontal scaling. When you write data to a distributed table or query data from a distributed table, the system can consume the storage and computing resources of multiple servers.
distributed tableA distributed table consists of a number of local tables. A distributed table abstracts local tables into a unified table and supports data write and query operations for external users. When data is written to a distributed table, the data is automatically distributed to each local table of the distributed table. When data in a distributed table is queried, each local table of the distributed table is queried. The query results of all the local tables are aggregated and returned.
Tables in ApsaraDB for ClickHouse can be divided into non-replicated tables and replicated tables based on storage engines.
TypeDescriptionDifference
non-replicated tableEach non-replicated table is stored on a single node and cannot be replicated to other nodes. Only one replica exists.
  • If an error occurs, high availability cannot be ensured for a non-replicated table.
  • If an error occurs and at least one replica of a replicated table is available, the replicated table can still be queried.
replicated tableData in a replicated table is automatically replicated to multiple nodes. This indicates that a replicated table has multiple replicas.