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.
- 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.
- PolarDB for MySQL Cluster Edition clusters of different specifications.
- Dedicated ApsaraDB RDS for MySQL High-availability Edition instances of different specifications (local SSDs).
Precautions
- PolarDB for MySQL and ApsaraDB RDS for MySQL have the same specifications.
- PolarDB for MySQL and ApsaraDB RDS for MySQL use the same version.
The reason is that implementation mechanisms vary based on versions. For example, PolarDB for MySQL 8.0.1 optimizes multi-core CPUs by separately abstracting threads, such as Log_writer, log_flusher, log_checkpoint, and log_write_notifier. However, if only a few CPU cores are used, the performance of MySQL 8.0 is lower than that of MySQL 5.6 or MySQL 5.7. We recommend that you do not compare PolarDB for MySQL 5.6 with ApsaraDB RDS for MySQL 5.7 or 8.0. This is because the optimizer of PolarDB for MySQL 5.6 is not as excellent as that of the later versions of PolarDB for MySQL.
- 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.