This topic describes the comparison results of the online transaction processing (OLTP) performance between PolarDB for MySQL and ApsaraDB RDS for MySQL in the same scenarios.
Compared with ApsaraDB RDS for MySQL, PolarDB for MySQL has been optimized in the following aspects to improve the overall performance of clusters.
PolarDB for MySQL adopts leading hardware technologies, including the Optane solid-state drive (SSD) of the 3D XPoint storage medium, NVMe SSDs, and RDMA over Converged Ethernet (RoCE).
PolarDB for MySQL implements a set of I/O and network protocol stacks that run in user mode based on new hardware. This improves performance and reduces latency.
Items, such as locks, I/O paths, and large tables, are optimized at the kernel layer. This improves performance in concurrency scenarios.
The products used for the test are:
PolarDB for MySQL Cluster Edition Edition clusters of different specifications.
Dedicated ApsaraDB RDS for MySQL High-availability Edition instances of different specifications (local SSDs).
For more information about the test, see OLTP performance test tools and methods.
Precautions
Before you begin, make sure that the following conditions are met to obtain accurate performance comparison results.
PolarDB for MySQL and ApsaraDB RDS for MySQL have the same specifications.
PolarDB for MySQL and ApsaraDB RDS for MySQL use the same version.
We recommend that you simulate the loads in actual production environments or use the sysbench benchmark suite to compare the performance. In this way, the performance data obtained in the tests is closer to the data obtained in actual production scenarios.
We recommend that you do not use just a single SQL statement to compare the read performance between PolarDB for MySQL and ApsaraDB RDS for MySQL.
PolarDB for MySQL decouples computing from storage, which compromises the response time of a single SQL statement. Therefore, the read performance of PolarDB for MySQL is lower than that of ApsaraDB RDS for MySQL. However, the cache hit ratio for an online database is greater than 99% in most cases. Only the first read request consumes I/O resources and compromises read performance. Subsequent read requests do not consume I/O resources because the data is stored in a buffer pool. For subsequent read requests, PolarDB for MySQL and ApsaraDB RDS for MySQL offer the same read performance.
We recommend that you do not use just a single SQL statement to compare the write performance. Instead, we recommend that you simulate a production environment and perform stress testing.
We recommend that you compare the primary nodes and read-only nodes in PolarDB for MySQL with the primary instances and read-only instances in ApsaraDB RDS for MySQL for performance comparison. Note that semi-synchronous replication is implemented for the read-only instances in ApsaraDB RDS for MySQL. By default, PolarDB for MySQL uses the quorum mechanism for data writes. If the data is written to two of the three replicas or all of the three replicas, the system determines that the write operation is successful. PolarDB for MySQL implements data redundancy at the storage layer and ensures strong consistency and high reliability for the three replicas. Therefore, an appropriate comparison method is to compare the PolarDB for MySQL service with the ApsaraDB RDS for MySQL service where semi-synchronous replication instead of asynchronous replication is implemented for the read-only instances.
Performance comparison between PolarDB for MySQL 8.0.1 and ApsaraDB RDS for MySQL 8.0
Performance comparison between PolarDB for MySQL 5.7 and ApsaraDB RDS for MySQL 5.7
Performance comparison between PolarDB for MySQL 5.6 and ApsaraDB RDS for MySQL 5.6
