PolarDB:Commit timestamp (CTS) technology

Background information

Mainstream open source relational databases, such as MySQL and PostgreSQL, use an active transaction list for transaction resolution and Multi-Version Concurrency Control (MVCC). This approach causes severe performance bottlenecks in high-concurrency scenarios and prevents the full utilization of multiple CPU cores for concurrent transaction processing. This approach also has inherent bugs related to cluster-consistent reads, multi-point writes within a cluster, and XA transaction management in a share-nothing architecture.

In PolarTrans, transaction resolution does not require maintaining an active transaction list. The traditional process of copying transaction states is replaced by retrieving the maximum commit timestamp of the current cluster. The logic for transaction state iteration, retrieval, and query (visibility check) is more lightweight. PolarTrans also applies locking optimization to most transaction logic. This greatly improves performance in mixed read-write and write-only scenarios.

The all-memory CTS log consists of a ring buffer. A transaction is mapped to its corresponding slot by performing a modulo operation on its trx_id. Each slot contains a trx pointer and a commit sequence number (csn).

Technical benefits

• Starting a write transaction

  In the native transaction system, starting a write transaction requires protection by the trx sys mutex to allocate a transaction ID. It also writes to the active transaction ID array (rw_trx_ids) and maintains data structures such as the rw_trx_set collection for mapping active transaction IDs to trx and the rw_trx_list linked list. In the PolarTrans transaction system, a transaction is registered in the CTS log when it starts. A corresponding slot is allocated based on a modulo operation on the trx_id. The transaction state is then set to a special active mark. This process can be lock-free.

• Committing a write transaction

  In the native transaction system, committing a write transaction requires protection by the trx sys mutex. The system must find and remove the corresponding trx_id from rw_trx_ids and maintain data structures such as rw_trx_set and rw_trx_list. In the PolarTrans transaction system, committing a transaction only requires allocating a commit timestamp and updating the corresponding csn field in the CTS log.

• Read view

  The core of InnoDB's MVCC mechanism relies on a read view to control data visibility. In the native transaction system, retrieving a read view also requires protection by the trx sys mutex. The system copies the active transaction ID array, the current minimum active ID, and the maximum transaction ID. During a visibility check, the system may need to search the active transaction ID array to determine visibility. In scenarios with severe read-write conflicts, both read-write and read-only transactions must update and copy the current transaction state under the protection of a mutex. This process results in high maintenance overhead and inefficient visibility checks. The PolarTrans transaction system replaces the native read view by retrieving the maximum commit timestamp from the transaction system. This process is also lock-free. During a visibility check, you only need to compare the csn of the read-only transaction with the trx csn of the row record.

Enable PolarTrans

When you enable global consistency (high-performance mode), the PolarTrans feature is enabled by default. For more information about how to enable global consistency (high-performance mode), see Enable global consistency (high-performance mode).

Performance comparison

The queries per second (QPS) of the native transaction system (PolarTrans disabled) and the PolarTrans transaction system (PolarTrans enabled) were tested separately under the same conditions.

• Staging environment

  A PolarDB for MySQL 8.0 Cluster Edition cluster with 88 cores and 710 GB of memory.

• Test tool

  Sysbench

• Data volume

  88 tables, with 12 million records in each table.

• Test case

  The following built-in Sysbench use cases were used for testing.

  • oltp_read_write

  • oltp_insert

  • oltp_update_index

  • oltp_update_no_index

  • oltp_read_only

• Test results and description

  The test results show that the PolarTrans transaction system significantly improves overall database performance in read-write and write-only scenarios. In read-only scenarios, the overall database performance remains unchanged. This is because read-only transactions can use the ReadView cache to reduce the locking overhead during the transaction state copy process. Therefore, in these scenarios, the PolarTrans transaction system does not provide a significant performance improvement over the native transaction system.