PolarDB:Terms

Term

Description

region

The geographical area of the data center in which a PolarDB-X instance is deployed.

zone

A geographical area in a region. A zone uses an independent power supply and network. The network latency between PolarDB-X instances that reside in the same zone is lower than the network latency between PolarDB-X instances that reside in different zones.

Instance

PolarDB-X provides services in multi-node mode. Each PolarDB-X instance consists of multiple compute nodes and data nodes.

specification

The specification of each node in a PolarDB-X instance. The specification specifies the resources of each node in the PolarDB-X instance. For example, a specification of 8 cores and 64 GB memory indicates that each node uses 8 CPU cores and the memory capacity of each node is 64 GB.

endpoint

An endpoint is a domain name that is used to access PolarDB-X databases. An endpoint is also known as an access point. Each PolarDB-X instance contains multiple endpoints. Each endpoint can be used to connect to one or more nodes. For example, requests that are sent to the primary endpoint are forwarded to the primary node. An endpoint specifies the attributes of database connections, such as the read/write mode, node, load balancing mode, and consistency level.

address

An address is the carrier of an endpoint in different networks. An endpoint may contain an address that can be used to connect to the corresponding instance over the internal network and an address that can be used to connect to the corresponding instance over the Internet. An address specifies network attributes, such as the domain name, IP address, VPC, and vSwitch.

cluster endpoint

The endpoint of a PolarDB-X cluster is a domain name that can be used to access all nodes in the cluster. Operations, such as auto scaling, intelligent routing, read/write splitting, load balancing, and consistency level management, can be performed by using the endpoint of the PolarDB-X cluster.

read-only endpoint

A read-only endpoint is a domain name that can be used to access all read-only nodes in a PolarDB-X cluster. PolarDB-X supports the following data consistency levels for read queries: strong data consistency and weak data consistency.

primary instance

The primary instance of a PolarDB-X cluster provides database services. You can access the PolarDB-X cluster by using the endpoints of the primary instance.

read-only instance

Read-only instances provide additional resources that are physically isolated from the primary instance to help reduce the workload on the primary instance. The primary instance and read-only instances use the same data replicas, and read-only instances can be used to execute SQL statements that are sent to the primary instance. You can use read-only instances to simplify your business architecture. This way, you do not need to manage specific data replicas for read-only instances. This also helps reduce costs and maintenance workloads.

workload

Workloads are classified into transactional processing (TP) workloads and analytic processing (AP) workloads. TP workloads include operations in transactions, write operations, and simple query operations. AP workloads include complex query operations.

TP

Transactional processing. The transactional processing workloads include simple operations, operations for processing small amounts of data, and real-time operations.

AP

Analytical processing. The analytical processing workloads include complex compute operations and operations that are performed to process large amounts of data.

intelligent routing

After the intelligent routing feature is enabled for a PolarDB-X instance, PolarDB-X routes SQL queries based on the workload types of SQL queries. For example, SQL queries that are identified as AP workloads are routed to read-only instances.

read/write splitting

After the read/write splitting feature is enabled for a PolarDB-X instance, PolarDB-X routes SQL queries based on the types of SQL queries. For example, SQL queries that are used to perform transactions and write operations are routed to the primary instance, and all read operations are routed to read-only instances.

data consistency level

PolarDB-X supports the following data consistency levels for read queries: strong data consistency and weak data consistency. Strong data consistency: You can query the most recent data that is submitted by the primary instance. This helps ensure the data consistency of all queries that are performed on the primary instance and read-only instances. If the most recent data is not synchronized from the primary instance to read-only instances when a query request is received, PolarDB-X waits until the most recent data is synchronized. Weak data consistency: You can query the current data that is stored in read-only instances. If the most recent data is not synchronized from the primary instance to read-only instances when a query request is received, PolarDB-X does not wait for the most recent data to be synchronized and performs the query immediately after the request is received.

three-role mode

PolarDB-X supports the three-role mode for database management. In this mode, the following roles are created to manage databases: database administrator (DBA), database security administrator (DSA), and data audit administrator (DAA). This helps improve the security of your database because the database management permissions are not granted to a single account. The three-role mode is suitable for scenarios in which financial transactions are performed.

whitelist

PolarDB-X allows you to use whitelists to manage the IP addresses and CIDR blocks that you allow to access a PolarDB-X instance. This helps ensure the security of the processes that are used to access the PolarDB-X instance. Whitelists do not affect the normal running of PolarDB-X instances.

audit log

Audit logs are used to record the operations that are performed on PolarDB-X instances. By default, SQL audit logs are retained for 45 days.

HTAP

Hybrid transactional and analytical processing (HTAP) provides online transaction processing (OLTP) capabilities and online analytical processing (OLAP) capabilities.

compute node

The storage resources and computing resources in a PolarDB-X instance are decoupled. The computing layer of a PolarDB-X instance consists of multiple compute nodes (CNs). The priorities and specifications of the compute nodes are the same.

A compute node consists of multiple modules such as SQL parsers, optimizers, and executors.

data node

The storage resources and computing resources in a PolarDB-X instance are decoupled. The storage layer of a PolarDB-X instance consists of multiple data nodes (DNs). The priorities and specifications of the data nodes are the same.

Data nodes are used to persistently store data in PolarDB-X. Data nodes provide storage services of high reliability and strong data consistency based on the Paxos protocol.

CDC

Change data capture (CDC) allows you to subscribe to incremental binary logs and provides the primary/secondary replication feature for MySQL databases. CDC is also known as incremental data capture.

GMS

Global meta service (GMS) maintains the global strong consistency of meta information such as information about tables, schemas, and statistics, and maintains security information such as information about accounts and permissions. GMS also provides a global timestamp distributor named Timestamp Oracle (TSO).

CTS

The commit timestamp (CTS) feature is an extension of the global timestamp feature. CTS can be used to ensure that snapshots can be read in distributed transactions.

ACID

Atomicity, consistency, isolation, and durability (ACID) indicates the properties that must be ensured when database management systems write data or update data to maintain the reliability of transactions.

sharding

Sharding is a process that splits data in a table into multiple database shards and table shards based on a sharding key and specific sharding rules.

broadcast table

A broadcast table is a table that is not split. The replicas of a broadcast table are stored in each data node of the database in which the broadcast table is stored.

non-partitioned table

A table that is not split.

partitioned table

A table that is split into partitions. Data in the table is separately stored in each partition.

table group

You can add specific tables into a table group to reduce the number of queries that are performed across different data nodes. This helps improve the query performance. Tables in a table group must contain the same number of partitions, and the tables must be partitioned by using the same algorithm and the same partition key.

partition group

If all tables in a table group are partitioned tables, a specific partition from each table is classified into the same partition group. A partition group is the basic unit that is used in partition scheduling. All partitions in a partition group are stored on the same data node.

join group

A join group contains multiple tables. When a join operation is performed on tables in the same join group, PolarDB-X pushes down the join operation to the data node layer for execution. If the join operation is performed at the data node layer, the query is performed in a more efficient manner. If a join operation is performed on tables that are not in the same join group, PolarDB-X does not push down the join operation to the data node layer.

logical query

A logical query is an SQL query that a client sends to PolarDB-X for execution.

physical query

A physical query is an SQL query that is executed at the data node layer.

logical connection

Logical connections are used to connect clients to compute nodes of PolarDB-X instances.

physical connection

Physical connections are used to connect compute nodes of PolarDB-X instances to data nodes of PolarDB-X instances.

distributed execution plan

A distributed execution plan is the execution plan that is generated after the optimizer of a distributed database optimizes an SQL query. A distributed execution plan describes how to execute an SQL statement on each node.

cost model

A cost model is used to evaluate the cost of an execution plan of a physical query. The cost of an execution plan is evaluated based on the following metrics: CPU utilization, memory usage, I/O throughput, and network bandwidth usage.

execution model

Traditional databases use the Volcano model. PolarDB-X uses a hybrid model that combines the PULL method and PUSH method.

CBO

Cost-based optimizer (CBO) optimizes SQL queries based on costs to generate the most efficient execution plans.

RBO

Rule-based optimizer (RBO) optimizes SQL queries based on specific rules.

operator

Operators are the basic units of execution plans. An execution plan consists of multiple operators.

scheduling

Scheduling is a process that is performed to transfer 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.

distributed transaction

Distributed transactions are transactions that are performed across multiple data nodes.

global timestamp

Global timestamps are incremental and globally unique in a PolarDB-X instance.

local indexes

Local indexes are maintained by the MySQL engine that data nodes run. Local indexes are also known as secondary indexes.

GSI

Data in a global secondary index (GSI) is distributed across multiple data nodes based on specific rules.

clustered index

A clustered index is a special global secondary index that covers all columns of the base table by default. When a clustered index is used, requested data can be queried from the index table without the need to scan the base table. This can help reduce resource overheads.

automatic sharding

Automatic sharding horizontally splits data in a table into multiple shards based on the primary key.

scale-out and scale-in

Scale-out indicates the scaling operation that is performed to increase the number of nodes of a PolarDB-X instance. For example, you can scale out a PolarDB-X instance from four nodes to eight nodes. Scale-in indicates the scaling operation that is performed to decrease the number of nodes of a PolarDB-X instance.

scale-up and scale-down

Scale-up indicates the scaling operation that is performed to upgrade the specification of each node of a PolarDB-X instance. For example, you can scale up the specification of each node from 4 cores and 8 GB memory to 16 cores and 32 GB memory. Scale-down indicates the scaling operation that is performed to downgrade the specification of each node of a PolarDB-X instance.

X-Paxos

X-Paxos is a protocol developed by Alibaba Group. X-Paxos is used to ensure data consistency in distributed databases.

leader, follower, and learner

X-Paxos supports the following types of nodes: leader, follower, and learner. A leader node can initiate requests. A follower node can be elected as a new leader when a failure occurs on the existing leader node. A learner node can only receive data changes from the primary instance and cannot be elected as a leader.