All Products
Search
Document Center

AnalyticDB for MySQL:Terms

Last Updated:Jun 18, 2024

This topic describes the terms that are used in AnalyticDB for MySQL.

region

Regions are geographical locations where Alibaba Cloud data centers are deployed. Regions are typically named after the cities where the data centers are deployed. For example, the data centers of the Malaysia (Kuala Lumpur) region reside in Kuala Lumpur.

zone

The zone in which you want to deploy your resources. Each region has multiple isolated locations known as zones, which have their own independent power supply and network. For example, the China (Beijing) region has twelve zones, which include Beijing Zone A and Beijing Zone B and so on. Resources that are deployed within the same zone share the same network, and therefore have minimal latency between each other. This means that services deployed within the same zone have faster communication speeds, which translates into more efficient business operations.

cluster

A concept on top of databases. Different clusters are physically isolated from each other. Each cluster can contain a physical database and multiple logical databases.

physical database

A physical representation or storage mode of a database on physical storage devices, including data files, log files, and index files. When you create an AnalyticDB for MySQL cluster, a physical database is automatically created. Each physical database is divided into multiple shards. The shards are distributed across storage node groups. Each shard is managed by a Raft group.

logical database

A logical organizational structure of a database, including tables, views, and indexes. When you execute CREATE DATABASE statements, logical databases are created. You can create up to 2048 logical databases for an AnalyticDB for MySQL cluster.

The databases mentioned in AnalyticDB for MySQL documentation are logical databases.

shard

A part of a table that is obtained after AnalyticDB for MySQL splits the table based on a distribution key. The shards are distributed across storage node groups. Each storage node group maintains a specific amount of data, which helps improve system scalability and performance.

Each shard is managed by an independent Raft group. Multiple replicas of a Raft group are deployed on multiple storage nodes that belong to the same storage node group. The Raft protocol ensures data consistency across the replicas.

Distribution of shards

image

The number of shards in an AnalyticDB for MySQL cluster does not change after you change the configurations of the cluster. You can execute the following statement to query the number of shards in an AnalyticDB for MySQL cluster: SELECT COUNT(1) FROM information_schema.kepler_meta_shards;.

partition

A part of a shard that is obtained after AnalyticDB for MySQL splits the shard based on a partition key. In most cases, the date column is selected as the partition key to perform lifecycle management on data.

table

AnalyticDB for MySQL supports two types of tables: partitioned tables and replicated tables. For information about how to create a table, see CREATE TABLE.

partitioned table

A partitioned table is also known as a standard table. AnalyticDB for MySQL splits the data of a partitioned table into multiple shards based on a distribution key and distributes the shards across storage nodes. Then, AnalyticDB for MySQL splits each shard into multiple partitions based on a partition key. Partitioned tables take advantage of the distributed system to improve query efficiency. A partitioned table can store up to hundreds of billions of data entries.

replicated table

Each shard of an AnalyticDB for MySQL cluster stores a full copy of replicated table data. We recommend that you do not store more than 20,000 rows of data in a replicated table.

Changes in a replicated table are broadcast to all shards of an AnalyticDB for MySQL cluster. This ensures data consistency across shards but affects write performance. We recommend that you do not frequently add, remove, or modify data in replicated tables.

elastic I/O unit (EIU)

Elastic I/O resources are bundled into units and sold as EIUs. For AnalyticDB for MySQL clusters in elastic mode for Cluster Edition, EIUs are composed of storage nodes and provide data storage, write, query, and scan capabilities.

Each EIU is a storage node group that consists of three storage nodes. You can purchase EIUs when you create an AnalyticDB for MySQL cluster. You can also scale up or out EIUs to meet high-throughput write or high-volume scan requirements. For information about the performance metrics of EIUs, see Scale up or out elastic I/O resources.

AnalyticDB compute unit (ACU)

Computing and storage resources of AnalyticDB for MySQL Data Lakehouse Edition are bundled into units and sold as ACUs. Each ACU is approximately equal to 1 core and 4 GB memory.

resource group

Computing resources are divided into resource groups to meet multi-tenancy and hybrid load requirements within an AnalyticDB for MySQL cluster. AnalyticDB for MySQL Data Warehouse Edition clusters in elastic mode for Cluster Edition and AnalyticDB for MySQL Data Lakehouse Edition clusters allow you to configure multiple resource groups. Each resource group has independent computing resources. The computing resources of different resource groups are physically isolated from each other. Different jobs are assigned to different resource groups for execution. For example, batch processing and real-time analysis are assigned to different resource groups to prevent resource contention and performance degradation.