Klustron-Storage vs PostgreSQL OLTP 测试

1 Klustron-Storage 简介

Klustron-Storage 是泽拓科技基于 Percona-mysql-8.0.26 优化的数据库存储服务器，作为 Klustron 分布式数据库的存储节点，我们对 percona-mysql 做了大量性能增强，补足了其在 XA 事务处理的容灾和错误处理方面的空白，并增加了一些 Klustron 集群整体需要的功能，包括fullsync复制，update/delete...returning语句等。

2 测试环境

测试软件：

• sysbench 1.1.0-df89d34 (using bundled LuaJIT 2.1.0-beta3（AWS 云上环境）

• sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3）（本地部署环境）

服务器配置：

• PostgreSQL 和 Klustron-Storage 各部署在一台：亚马逊 i3.4xlarge（CPU 8cores 16 Threads,内存:122G，存储:2个1900 NVMe SSD）上（AWS 云上环境）

• PostgreSQL 和 Klustron-Storage 各部署同一台服务器上（CPU 16 cores 32 Threads, 内存: 64G，存储:1个 NVMe SSD）上（本地部署环境）

软件版本：

• Postgresql：PostgreSQL 14.2 onx86_64-pc-linux-gnu

• Klustron-Storage:8.0.26-16-Klustron-Storage

数据库参数配置：

PostgreSQL：

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

Klustron-Storage:

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

测试背景：

PostgreSQL 和 Klustron-Storage 采用默认的安装配置，只调整了内存参数及上述几个参数，整个测试过程 PostgreSQL 和 Klustron-Storage 没有任何优化行为。

3 测试数据

测试软件：

• sysbench 1.1.0-df89d34 (using bundled LuaJIT 2.1.0-beta3（AWS 云上环境）

• sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3）（本地部署环境）

Sysbench测试场景：

场景一 ：oltp_write_only

每个事务执行如下 4 种操作：execute_index_updates()、execute_non_index_updates()、execute_delete_inserts()

场景二：oltp_update_index

每个事务执行如下 1 种操作：execute_index_updates()

场景三：oltp_update_non_index

每个事务执行如下 1 种操作：execute_non_index_updates()

场景四：oltp_read_write.lua

每个事务执行如下 7 种操作：execute_simple_ranges(),execute_sum_ranges()、 execute_order_ranges()、execute_distinct_ranges()、execute_index_updates()、execute_non_index_updates()、execute_delete_inserts()

各个操作操作对应的 SQL 语句如下：

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}}

测试数据量：

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

表占用操作系统存储空间：36 G

测试脚本：

测试的 sysbench 的线程从 64 到 900 ，每个线程案列执行 10 分钟，每个场景连续测试时间 140 分钟。

Klustron-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 变化范围：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 变化范围：64-128-192-......900

4 AWS 云上环境测试结果

oltp_write_only 测试

oltp_update_index 测试

oltp_update_non_index 测试

5 本地部署测试结果

oltp_write_only 测试

oltp_update_index 测试

oltp_update_non_index 测试

oltp_read_write 测试

6 测试结果及总结

**1.**在OLTP write-only、oltp -read-write 和 OLTP update_index 场景下，Klustron-Storage 性能明显优于 PostgreSQL。

需要强调的是，PostgreSQL 只要更新任何一个索引字段，都需要在所有索引中插入新的索引行指向新版本的数据行，此时 HOTupdate 无法发挥作用。

因此，update_index 的性能会大幅落后于 MySQL。

在实际生产系统中，更新到索引列是非常常见的现象，特别是还有Vacuum带来的IO消耗大幅增长，所以PostgreSQL的通用的写入性能就相对较差。

**2.**在 OLTP update_non_index 场景下，PostgreSQL 的 tps 性能高于 Klustron-Storage，但 95 percent delay 也高于 Klustron-storage，这表明在更新的字段不是索引字段的场景下，由于 PostgreSQL 通过保持 heap 页面半空，可以实现大多数行的更新是 HOT update，也就是不需要插入索引行，直接在与旧行同一个 heap 页面中写入新版本行数据即可，因此比平均的 QPS 比 Klustron-Storage 高 5%～30% 。

不过从测试结果可以看到，PostgreSQL 的 QPS 和延时的波动比较大，因为无法做 HOT update 的那些更新语句的延时也会大幅提高，也就导致 PostgreSQL 95% 延时反而比 MySQL 大 10% 到 40% 左右。

由于大多数实际使用场景下是无法避免更新索引字段的，并且即使对于不更新索引字段的语句，HOT update 也不能保证大概率发生（只有不更新任何索引字段并且 heap 页面有足够空间存储那个被更新的行的新版本的时候 HOT Update 才能发生），因此PostgreSQL的这种性能优势的覆盖面过于狭窄。

**3.**PostgreSQL 在负载动态变化过程中，有明显的延迟抖动，而 Klustron-Storage 性能曲线相对平稳.

END