Kunlun storage vs PostgreSQL OLTP test

One 、Kunlun-Storage brief introduction

KunlunStorage Zetuo technology is based on Percona-mysql-8.0.26 Optimized database storage server , As KunlunBase Storage node of distributed database , We are right. percona-mysql A lot of performance enhancements have been made , Complements its XA Gaps in disaster recovery and error handling of transaction processing , And added some functions needed by Kunlun database cluster as a whole , Include fullsync Copy ,update/delete...returning Statement etc. .

Two 、 Test environment

Testing software ：

sysbench 1.1.0-df89d34 (using bundled LuaJIT 2.1.0-beta3（AWS  Cloud environment ）

sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3）（ Local deployment environment ）

Server configuration ：

PostgreSQL and Kunlun-Storage Each deployed on one ： Amazon i3.4xlarge（CPU 8cores 16 Threads, Memory :122G, Storage :2 individual 1900 NVMe SSD） On （AWS  Cloud environment ）

PostgreSQL and Kunlun-Storage Deploy on the same server （CPU 16 cores 32 Threads,  Memory : 64G, Storage :1 individual  NVMe SSD） On （ Local deployment environment ）

Software version ：

Postgresql：PostgreSQL 14.2 onx86_64-pc-linux-gnu

Kunlun-Storage:8.0.26-16-kunlun-storage

Database parameter configuration ：

PostgreSQL：

shared_buffers = 32768MB
wal_level = replica
fsync = on 
synchronous_commit = on 
wal_sync_method = fdatasync 
full_page_writes = on 


Kunlun-Storage:

innodb_buffer_pool_size 32768MB
inndo_flush_at_trx_commit=1
sync_binlog=1
innodb_use_fdatasync = 1


Test background ：

PostgreSQL and Kunlun-Storage Use the default installation configuration , Only the memory parameters and the above parameters are adjusted , The whole testing process PostgreSQL and Kunlun-Storage There is no optimization behavior .

3、 ... and 、 Test data

Testing software ：

sysbench 1.1.0-df89d34 (using bundled LuaJIT 2.1.0-beta3（AWS  Cloud environment ）

sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3）（ Local deployment environment ）

Sysbench Test scenarios ：

Scene one  ：oltp_write_only

Each transaction is executed as follows 4 Kind of operation ：execute_index_updates()、execute_non_index_updates()、execute_delete_inserts()

Scene two ：oltp_update_index

Each transaction is executed as follows 1 Kind of operation ：execute_index_updates()

Scene three ：oltp_update_non_index

Each transaction is executed as follows 1 Kind of operation ：execute_non_index_updates()

Scene 4 ：oltp_read_write.lua

Each transaction is executed as follows 7 Kind of operation ：execute_simple_ranges(),execute_sum_ranges()、 execute_order_ranges()、execute_distinct_ranges()、execute_index_updates()、execute_non_index_updates()、execute_delete_inserts()

Corresponding to each operation SQL The statement is as follows ：

sum_ranges = {
 "SELECT SUM(k) FROMsbtest%u WHERE id BETWEEN ? AND ?",
 t.INT, t.INT},
order_ranges = {
 "SELECT c FROMsbtest%u WHERE id BETWEEN ? AND ? ORDER BY c",
 t.INT, t.INT},
distinct_ranges = {
 "SELECT DISTINCT cFROM sbtest%u WHERE id BETWEEN ? AND ? ORDER BY c",
 t.INT, t.INT},
index_updates = {
 "UPDATE sbtest%uSET k=k+1 WHERE id=?",
 t.INT},
non_index_updates = {
 "UPDATE sbtest%uSET c=? WHERE id=?",
 {t.CHAR, 120}, t.INT},
deletes = {
 "DELETE FROMsbtest%u WHERE id=?",
 t.INT},
inserts = {
 "INSERT INTOsbtest%u (id, k, c, pad) VALUES (?, ?, ?, ?)",
 t.INT, t.INT, {t.CHAR,120}, {t.CHAR, 60}}


Test data volume ：

--tables=18 --table-size=10000000

The table occupies the storage space of the operating system ：36G

The test script ：

The test of sysbench  Thread from 64  To 900 , Execution of each thread 10 minute , Continuous test time for each scenario 140 minute .

Kunlun-Storage:

sysbench /usr/local/share/sysbench/oltp_write_only.lua--db-driver=mysql --mysql-host=172.31.41.115 --mysql-port=6001 --mysql-user=pgx --mysql-password=pgx_pwd--mysql-db=vpgtest --tables=18 --table-size=10000000 --report-interval=10--threads=64 --time=600 run
 
sysbench/usr/local/share/sysbench/oltp_update_index.lua --db-driver=mysql --mysql-host=172.31.41.115 --mysql-port=6001 --mysql-user=pgx--mysql-password=pgx_pwd --mysql-db=vpgtest --tables=18 --table-size=10000000--report-interval=10 --threads=64 --time=600 run 

sysbench/usr/local/share/sysbench/oltp_update_non_index.lua --db-driver=mysql--mysql-host=172.31.41.115 --mysql-port=6001 --mysql-user=pgx --mysql-password=pgx_pwd--mysql-db=vpgtest --tables=18 --table-size=10000000 --report-interval=10--threads=64 --time=600 run 


Threads  The range of change ：64-128-192-......900

PostgreSQL:

sysbench/usr/local/share/sysbench/oltp_read_write.lua --db-driver=pgsql--pgsql-host=172.31.44.208 --pgsql-port=5432 --pgsql-user=postgres --pgsql-password=postgres--pgsql-db=postgres --tables=18 --table-size=10000000 --report-interval=10--threads=64 --time=600 run
 
sysbench /usr/local/share/sysbench/oltp_update_index.lua--db-driver=pgsql --pgsql-host=172.31.44.208 --pgsql-port=5432 --pgsql-user=postgres --pgsql-password=postgres--pgsql-db=postgres --tables=18 --table-size=10000000 --report-interval=10--threads=64 --time=600 run

sysbench/usr/local/share/sysbench/oltp_update_non_index.lua --db-driver=pgsql--pgsql-host=172.31.44.208 --pgsql-port=5432 --pgsql-user=postgres --pgsql-password=postgres--pgsql-db=postgres --tables=18 --table-size=10000000 --report-interval=10--threads=640 --time=600 run


Threads  The range of change ：64-128-192-......900

Four 、 AWS  Cloud environment test results

oltp_write_only  test

oltp_update_index  test

oltp_update_non_index  test

5、 ... and 、 Local deployment test results

oltp_write_only  test

oltp_update_index  test

oltp_update_non_index  test

oltp_read_write  test

6、 ... and 、 Test results and summary

1.

  stay OLTP write-only、oltp -read-write and OLTP update_index scenario ,Kunlun-Storage The performance is obviously better than PostgreSQL.

It's important to note that ,PostgreSQL Just update any index field , You need to insert new index rows into all indexes to point to the new version of data rows , here HOTupdate It doesn't work .

therefore ,update_index The performance of will lag far behind MySQL.

In the actual production system , Updating to index columns is a very common phenomenon , Especially the Vacuum It brings IO Consumption has increased significantly , therefore PostgreSQL The general-purpose write performance of is relatively poor .

2.

  stay OLTP update_non_index scenario ,PostgreSQL Of tps Performance is higher than Kunlun-Storage, but 95 percent delay Also higher than KunlunStorage, This indicates that in a scenario where the updated field is not an index field , because PostgreSQL By keeping  heap The page is half empty , Most row updates that can be achieved are HOT update, That is, there is no need to insert index rows , Directly in the same... As the old line heap Write the new line data in the page , So it's better than the average QPS Than Kunlun-Storage high 5%～30%.

But from the test results, we can see ,PostgreSQL Of QPS The fluctuation of and delay is relatively large , Because I can't do HOT update The latency of those updated statements will also increase significantly , Also leads to PostgreSQL95% Instead, the delay is greater than MySQL Big 10% To 40% about .

Since it is impossible to avoid updating index fields in most actual use scenarios , And even for statements that do not update index fields ,HOT update There is no guarantee that the probability of （ Only do not update any index fields and heap When the page has enough space to store the new version of the updated row  HOT Update  To happen ）, therefore PostgreSQL The coverage of this performance advantage is too narrow .

3.

 PostgreSQL During the dynamic change of load , There is obvious delay jitter , and Kunlun-Storage The performance curve is relatively stable .

-END-

Kunlun database is a HTAP NewSQL Distributed database management system , It can meet the all-round needs of users for the storage, management and utilization of massive relational data . Application developers and DBA The experience of using Kunlun database is similar to that of single machine MySQL And stand alone PostgreSQL almost the same , Because first of all, Kunlun database supports PostgreSQL and MySQL Double agreement , Support standards SQL:2011 Of  DML  Grammar and function and PostgreSQL and MySQL To the standard  SQL An extension of . meanwhile , Kunlun database cluster supports horizontal elastic expansion , Automatic data splitting , Distributed transaction processing and distributed query processing , Robust fault tolerance , Improve the intuitive monitoring, analysis and alarm capability , Cluster data backup and recovery   frequently-used DBA  Data management and operation . All these functions do not require any coding work on the application system side , No need DBA Artificial intervention , Non-stop service does not affect the normal operation of business . Kunlun database has a comprehensive OLAP  Data analysis capabilities , Passed TPC-H and TPC-DS Standard test set , It can analyze the latest business data in real time , Help users discover the value of data . Kunlun database supports the deployment of public cloud and private cloud environments , It can be done with docker,k8s Wait for cloud infrastructure to work seamlessly , You can easily build cloud database services . Please visit  http://www.zettadb.com/  Get more information and download Kunlun database software 、 Documents and materials .KunlunBase The project is open source

【GitHub：】https://github.com/zettadb

【Gitee：】https://gitee.com/zettadb