共计 5309 个字符,预计需要花费 14 分钟才能阅读完成。
一、Kunlun-Storage 简介
KunlunStorage 是泽拓科技基于 Percona-mysql-8.0.26 优化的数据库存储服务器,作为 KunlunDB 分布式数据库的存储节点,咱们对 percona-mysql 做了大量性能加强,补足了其在 XA 事务处理的容灾和错误处理方面的空白,并减少了一些昆仑数据库集群整体须要的性能,包含 fullsync 复制,update/delete…returning 语句等。
二、测试环境
测试软件:
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 和 Kunlun-Storage 各部署在一台:亚马逊 i3.4xlarge(CPU 8cores 16 Threads, 内存:122G,存储:2 个 1900 NVMe SSD)上(AWS 云上环境)
PostgreSQL 和 Kunlun-Storage 各部署同一台服务器上(CPU 16 cores 32 Threads, 内存: 64G,存储:1 个 NVMe SSD)上(本地部署环境)
软件版本:
Postgresql:PostgreSQL 14.2 onx86_64-pc-linux-gnu
Kunlun-Storage:8.0.26-16-kunlun-storage
数据库参数配置:
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
测试背景:
PostgreSQL 和 Kunlun-Storage 采纳默认的装置配置,只调整了内存参数及上述几个参数,整个测试过程 PostgreSQL 和 Kunlun-Storage 没有任何优化行为。
三、测试数据
测试软件:
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
表占用操作系统存储空间:36G
测试脚本:
测试的 sysbench 的线程从 64 到 900,每个线程案列执行 10 分钟,每个场景间断测试工夫 140 分钟。
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 变动范畴: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
四、AWS 云上环境测试后果
oltp_write_only 测试
oltp_update_index 测试
oltp_update_non_index 测试
五、本地部署测试后果
oltp_write_only 测试
oltp_update_index 测试
oltp_update_non_index 测试
oltp_read_write 测试
六、测试后果及总结
1. 在 OLTP write-only、oltp -read-write 和 OLTP update_index 场景下,Kunlun-Storage 性能显著优于 PostgreSQL。
须要强调的是,PostgreSQL 只有更新任何一个索引字段,都须要在所有索引中插入新的索引行指向新版本的数据行,此时 HOTupdate 无奈发挥作用。
因而,update_index 的性能会大幅落后于 MySQL。
在理论生产零碎中,更新到索引列是十分常见的景象,特地是还有 Vacuum 带来的 IO 耗费大幅增长,所以 PostgreSQL 的通用的写入性能就绝对较差。
2. 在 OLTP update_non_index 场景下,PostgreSQL 的 tps 性能高于 Kunlun-Storage,但 95 percent delay 也高于 KunlunStorage,这表明在更新的字段不是索引字段的场景下,因为 PostgreSQL 通过放弃 heap 页面半空,能够实现大多数行的更新是 HOT update,也就是不须要插入索引行,间接在与旧行同一个 heap 页面中写入新版本行数据即可,因而比均匀的 QPS 比 Kunlun-Storage 高 5%~30%。
不过从测试后果能够看到,PostgreSQL 的 QPS 和延时的稳定比拟大,因为无奈做 HOT update 的那些更新语句的延时也会大幅提高,也就导致 PostgreSQL95% 延时反而比 MySQL 大 10% 到 40% 左右。
因为大多数理论应用场景下是无奈防止更新索引字段的,并且即便对于不更新索引字段的语句,HOT update 也不能保障大概率产生(只有不更新任何索引字段并且 heap 页面有足够空间存储那个被更新的行的新版本的时候 HOT Update 能力产生),因而 PostgreSQL 的这种性能劣势的覆盖面过于狭隘。
3. PostgreSQL 在负载动态变化过程中,有显著的提早抖动,而 Kunlun-Storage 性能曲线绝对安稳.
-END-
昆仑数据库是一个 HTAP NewSQL 分布式数据库管理系统,能够满足用户对海量关系数据的存储管理和利用的全方位需要。
利用开发者和 DBA 的应用昆仑数据库的体验与单机 MySQL 和单机 PostgreSQL 简直完全相同,因为首先昆仑数据库反对 PostgreSQL 和 MySQL 双协定,反对规范 SQL:2011 的 DML 语法和性能以及 PostgreSQL 和 MySQL 对规范 SQL 的扩大。同时,昆仑数据库集群反对程度弹性扩容,数据主动拆分,分布式事务处理和分布式查询处理,强壮的容错容灾能力,欠缺直观的监测剖析告警能力,集群数据备份和复原等 罕用的 DBA 数据管理和操作。所有这些性能无需任何利用零碎侧的编码工作,也无需 DBA 人工染指,不停服不影响业务失常运行。
昆仑数据库具备全面的 OLAP 数据分析能力,通过了 TPC- H 和 TPC-DS 规范测试集,能够实时剖析最新的业务数据,帮忙用户发掘出数据的价值。昆仑数据库反对私有云和公有云环境的部署,能够与 docker,k8s 等云基础设施无缝合作,能够轻松搭建云数据库服务。
请拜访 http://www.zettadb.com/ 获取更多信息并且下载昆仑数据库软件、文档和材料。
KunlunDB 我的项目已开源
【GitHub:】
https://github.com/zettadb
【Gitee:】
https://gitee.com/zettadb