This topic describes the terms that you may encounter when using the cloud-native distributed relational database PolarDB-X.
Console terms
Concept | Description |
Region | The geographic area of a data center where a PolarDB cluster is deployed. |
Zone | A geographical area within a region. A zone has an independent power supply and network. The network latency between instances within the same zone is lower than that between instances that reside in different zones. |
Cluster (instance) | PolarDB-X uses a multi-node cluster architecture. A cluster contains multiple compute nodes and data nodes. A cluster is also called an instance. |
Compute node | PolarDB-X instances use a storage-compute separation architecture. The compute layer consists of multiple compute nodes. All compute nodes are equal in relationship and have the same specifications. A compute node includes modules such as SQL parser, optimizer, and executor. |
Data node | PolarDB-X instances use a storage-compute separation architecture. The storage layer consists of multiple data nodes. All data nodes are equal in relationship and have the same specifications. Data nodes are responsible for data persistence and provide high reliability and strong consistency based on the majority-based Paxos protocol. |
Metadata node | The metadata management node of a PolarDB-X instance. It primarily records status information such as table topology and provides global timestamp services. |
Change data capture | The primary/secondary replication protocol is compatible with the protocols and data formats that are supported by MySQL binary logging. Change data capture (CDC) provides a primary/secondary replication protocol that is compatible with MySQL and the incremental subscription capabilities. |
Instance type | The resource configuration of each node in a PolarDB-X instance, such as 8 cores and 64 GB of memory. |
Cluster endpoint | A unified read/write endpoint that integrates multiple nodes in an instance. A cluster endpoint has the following features: auto scaling, intelligent routing, read/write splitting, load balancing, and the consistency level. |
Read-only endpoint | An endpoint that integrates multiple read-only nodes in an instance to provide read-only services. A PolarDB-X cluster provides read-only services with two query consistency levels: strong consistency and weak consistency. |
Primary instance | The primary cluster that provides database services. You can access the primary instance by using the cluster endpoint. |
Read-only instance | Read-only instances provide additional physical resources that are isolated from the primary instance to reduce the workload on the primary instance. Read-only instances support the SQL syntax used on the primary instance and can share the same data as the primary data. Read-only instances can simplify the data link in your business architecture and free you from additional data synchronization. This way, your O&M and budget cost can be reduced. |
Workload | Workloads are classified into transaction processing (TP) and analytical processing (AP). Intra-transaction operations, write operations, and simple query operations are categorized as TP workloads. Complex query operations are categorized as AP workloads. |
Intelligent routing | If you enable intelligent routing for the cluster endpoint, the workload types of SQL queries are identified based on statistics to route the SQL queries. For example, SQL queries that are identified as AP loads are routed to read-only instances. |
Read/write splitting | If you enable read/write splitting for the cluster endpoint, operations are directly routed to different instances based on the type of SQL statements. For example, intra-transaction operations and write operations are routed to the primary instance, and all query operations are all routed to read-only instances. |
Query consistency level | The read-only endpoint provides two query consistency levels: strong consistency and weak consistency.
|
Three-role mode | PolarDB-X supports the three-role mode for database management. In the three-role mode, three roles are created to manage databases. The three roles are database administrator (DBA), database security administrator (DSA), and data audit administrator (DAA). This makes your database more secure because the database management permissions are not granted to one account. The three-role mode is mainly used in financial business. |
Whitelist | Provides access security protection for PolarDB-X instances. Setting a whitelist does not affect the normal operation of PolarDB-X instances. |
Audit log | Records user operations. SQL audit logs are retained for 45 days by default. |
Kernel terms
Concept | Description |
Distributed table | Sharding is a process that splits data in table into multiple databases and tables by using a shard key based on specific rules. |
Broadcast table | A broadcast table is not split, and all data nodes in the database have a replica of the table. |
Single table | Single tables are tables that are not split. |
Database mode | Specified by the Mode parameter when creating a database. It includes two modes: DRDS and AUTO. |
DRDS mode database | A database created with |
AUTO mode database | A database created with |
AUTO table | In an AUTO mode database, tables created without using the PARTITION syntax are called AUTO tables. AUTO tables are distributed. |
Partitioned table | In an AUTO mode database, tables created using the |
Table group | In an AUTO mode database, to avoid cross-machine queries as much as possible and improve performance, certain global indexes can be grouped into a table group. All indexes in a table group must have the same number of partitions, the same partition algorithm, and the same partition key. Table groups are at the global index level. The primary table has its own table group, and each global secondary index also has its own table group. |
Partition group | In an AUTO mode database, when tables in a table group are partitioned tables, a partition from each table in the table group forms a partition group. A partition group is the basic unit of partition scheduling. All table partitions belonging to a partition group are always located on the same data node. |
Join group | In an AUTO mode database, a join group consists of multiple tables. Global indexes (primary tables and global secondary indexes) in the same join group will be scheduled to the same table group. |
Execution plan | A plan that can be executed after parsing and optimizing an SQL query statement. |
Query rewrites | Optimizing logical plans based on predefined rules to output better logical plans. |
Plan cache | Caches execution plans so that the next time the SQL statement is executed, the execution plan can be directly obtained based on the parameterized SQL string. |
Plan management | Plan management is a process that saves one or multiple execution plans for each SQL statements. When a SQL statement is executed, PolarDB-X selects a saved execution plan for the SQL statement. |
Cost model | Used to estimate the cost of physical query execution plans. PolarDB-X describes execution costs using a four-tuple (CPU, Memory, IO, Net). |
Execution model | Unlike traditional databases that use the Volcano execution model, PolarDB-X uses a hybrid execution model that combines Pull and Push. |
CBO (Cost Based Optimizer) | Cost-based optimizer. |
RBO (Rule Based Optimizer) | Rule-based optimizer. |
Operator | Operators are the basic units of execution plans. An execution plan consists of multiple operators. |
Scheduling | Scheduling is a process that move a job or part of a job to another machine for execution. |
Online DDL | Online DDL indicates DDL operations that do not block concurrent DML operations. For example, the operations that are performed to create indexes do not block concurrent DML operations that are being performed. |
Logical query | SQL queries sent from the client to PolarDB-X. |
Physical query | SQL queries executed on data nodes. |
Logical connection | The connection from the client to a PolarDB-X compute node. |
Physical connection | The connection from a PolarDB-X compute node to a PolarDB-X data node. |
Distributed transaction | Operations within the same transaction involve multiple data nodes. |
Global timestamp | Global timestamps are incremental and globally unique in a PolarDB-X cluster. |
Local index | Local indexes are maintained by MySQL in data nodes. Also known as secondary indexes. |
Global secondary index (GSI) | Data in a global secondary index (GSI) is distributed on multiple data nodes based on specific rules. |
Clustered index | Clustered indexes are special global secondary indexes that cover all columns of the base table by default. When clustered indexes are used, requested data can be queried from the index table without the need to scan the base table. This reduces resource overheads. |
Automatic sharding | Automatically shards tables based on the primary key type. |
Scale-out and scale-in | Scale-out or scale-in indicates the increasing or decreasing of the number of nodes. For example, you can scale out a cluster from four nodes to eight nodes. |
Scale-up and scale-down | Increases or decreases the configuration of a single node. For example, the node specification can be increased from 4 cores and 8 GB to 16 cores and 32 GB. |
XPaxos | X-Paxos is a protocol developed by Alibaba Group. X-Paxos is used to ensure data consistency in distributed databases. |
Leader/Follower/Learner | X-Paxos defines the following three node types: The leader node initiates proposals. The follower node can elect a new leader. The learner node only receives data changes from the primary instance and does not participate in the leader election. |
Back to Primary Table | The operation of querying the primary table to complete the columns needed for a query after scanning an index. |