关于数据库:KunlunDB-091版本Sysbench性能测试报告

概述

kunlun-0.9.1 的性能测试次要应用 Sysbench 进行，分为 oltp 测试和 olap 测试两大部分。

• 对于 oltp 测试，次要蕴含 4 种操作:read&write、write only、update_non_index、update_index，测试目标次要是查看新推出的强一致性模式 (rbr)，比照 MySQL 的官网强一致性计划(mgr) 性能有多大晋升。因为网络不是瓶颈，次要在内网的机器中进行。

• 对于 olap 测试，则次要蕴含: point select、simple range select、sum range select, order by range select、distinct range select，次要在 AWS EC2 的机器上运行，因为某些 select 操作对网络要求很高，大量操作就能用满千兆网，须要万兆网能力测出最好性能。另一目标则是掂量 AWS 上不同配置的性能价格比。

oltp 测试

根本配置状况

本测试分为 2 个局部:

• rbr: 应用 RBR 复制模式构建的集群，此为企业版独有。
• mgr: 应用 MGR 复制模式构建的集群，此为开源版和企业版都有。

客户端: 测试客户端应用一台 AMD Ryzen 9 5950X + 64GB 内存的机器，其上部署 sysbench 以及 HAProxy, sysbench 将申请发往 HAProxy, HAProxy 将申请发往三个计算节点。

数据: 总共为 18 个表，每个表 1000 万记录，总数据量为 36G，分到 3 个 Shard 外面，数据在 shard 间均匀分布，每个 shard 含有 6 个表，12G。

集群配置：集群应用三台机器，且做对等部署, 每台机器上部署一个元数据节点，一个计算节点, 一个 shard 的 primary 和另外两个 shards 的 replicas，三台机器配置为:

• § AMD Ryzen 9 5950X + 64G + 1TB SSD
• § AMD Ryzen 9 5950X + 128GB + 1TB SSD
• § AMD Ryzen 9 5950X + 128GB + 1TB SSD

缓存命中率: 每个数据节点 innodb_buffer_pool_size 为 12G，meta node 的 innodb_buffer_pool_size 为 512MB，缓存命中 100%，计算节点应用默认的内存配置。

测试状况:

• 测试线程为：300 400 500 600 700 800 900 1000。
• 总共测试四种操作:read&write、write only、update_non_index、update_index。
• 每个线程下每个操作运行工夫为 5 分钟。

测试后果

总体后果：

• rbr 为 0.9.1 版本新推出的，针对 mgr 复制模式的改良模式，从测试后果看，性能晋升显著。
• 对于 read&write：中低 (<=600) 线程下，mgr 和 rbr 体现差不多，线程数 >=700 时，rbr 比照 mgr 产生较大性能差，最高到靠近 3 倍。
• 对于 write only：低 (<=400) 线程下, rbr 约为 mgr 的 1.5 倍，中高线程下，rbr 为 mgr 的 2 倍以上。
• 对于 update_non_index 和 update_index：rbr 均匀超过 mgr 的 2 倍。

read&write

Sysbench 命令:

./sysbench --max-time=300 --test=tests/db/oltp.lua  --pgsql-host=$host  --pgsql-port=$port --pgsql-db=$dbname--oltp_tables_count=$tblcnt --oltp-table-size=$tblsize  --oltp-write-only=off --oltp-read-only=off--init-rng=on --num-threads=$thrcnt --max-requests=0 --oltp-dist-type=uniform --pgsql-user=$user--pgsql-password=$pass --oltp_auto_inc=off --db-driver=pgsql --oltp_use_xa_pct=0 --oltp_use_xa_2pc_pct=80--report-interval=10 run

rbr 的后果：

mgr 的后果：

write only

Sysbench 命令:

./sysbench --max-time=300--test=tests/db/oltp.lua --pgsql-host=$host --pgsql-port=$port --pgsql-db=$dbname --oltp_tables_count=$tblcnt--oltp-table-size=$tblsize --oltp-write-only=on --oltp-read-only=off --init-rng=on--num-threads=$thrcnt  --max-requests=0--oltp-dist-type=uniform --pgsql-user=$user --pgsql-password=$pass--oltp_auto_inc=off --db-driver=pgsql --oltp_use_xa_pct=0--oltp_use_xa_2pc_pct=80 --report-interval=10 run

rbr 的后果：

mgr 的后果：

update_non_index

Sysbench 命令：

./sysbench --max-time=300--test=tests/db/update_non_index.lua --pgsql-host=$host --pgsql-port=$port --pgsql-db=$dbname --oltp_tables_count=$tblcnt--oltp-table-size=$tblsize --oltp-write-only=on --oltp-read-only=off--init-rng=on --num-threads=$thrcnt --max-requests=0 --oltp-dist-type=uniform --pgsql-user=$user--pgsql-password=$pass --oltp_auto_inc=off --db-driver=pgsql--oltp_use_xa_pct=95 --oltp_use_xa_2pc_pct=80 --report-interval=10 run

rbr 的后果：

mgr 的后果：

update_index

Sysbench 命令:

./sysbench --max-time=300--test=tests/db/update_index.lua --pgsql-host=$host  --pgsql-port=$port--pgsql-db=$dbname --oltp_tables_count=$tblcnt --oltp-table-size=$tblsize--oltp-write-only=on --oltp-read-only=off --init-rng=on--num-threads=$thrcnt  --max-requests=0--oltp-dist-type=uniform --pgsql-user=$user --pgsql-password=$pass --oltp_auto_inc=off--db-driver=pgsql --oltp_use_xa_pct=95 --oltp_use_xa_2pc_pct=80--report-interval=10 run

rbr 的后果：

mgr 的后果：

olap 测试

olap 测试依据资源利用的状况，调整了机型的配置，以掂量不同配置下集群的整体体现，这里次要应用三种配置（仅列出不同)：

• 配置 1：计算节点应用 3 台 C5.4xlarge, 存储节点应用 3 台 i3.4xlarge，此配置仅测了 point select 的操作，因为很快发现存储节点 CPU 成为瓶颈。
• 配置 2：计算节点应用 3 台 C5.4xlarge, 存储节点应用 3 台 c5d.9xlarge
• 配置 3：计算节点应用 3 台 C5.9xlarge, 存储节点应用 3 台 c5d.9xlarge

根本配置状况

本测试应用 RBR 复制模式构建的集群，此为企业版独有。

测试客户端采纳 3 台 C5.4xlarge 来运行 sysbench, 通过 aws load balancer 做分流，将申请发向 3 个计算节点。

集群配置:

• rbr: 元数据集群应用 3 台 m5.xlarge, 蕴含 3 个 shards, 每个 shard 都是三正本，每台存储机器上具备一个 shard 的 primary 和另外两个 shards 的 replicas.

数据：总共为 18 个表，每个表 1000 万记录，总数据量为 36G，数据在 shard 间均匀分布，每个 shard 含有 6 个表，12G。

缓存命中率：每个数据节点 innodb_buffer_pool_size 为 20G，meta node 的 innodb_buffer_pool_size 为 1G，缓存命中 100%。

测试状况:

• 每台 sysbench 客户端测试线程为：50 100 200 300 400 500。
• 总共测试 5 种操作: point selects、simple range selects、sum range selects、order by range selects、distinct range selects。
• 每个线程下每个操作运行工夫为 5 分钟。

集群老本：

• 配置 1 = 3 (m5.xlarge + i3.4xlarge + c5.4xlarge) = 3 (1.356 + 9.365 + 3.943) = 3 14.664 = 44 CNY / hour。
• 配置 2 = 3 (m5.xlarge + c5d.9xlarge + c5.4xlarge) = 3 (1.356 + 10.721 + 3.943) = 3 16.02 = 48 CNY / hour。
• 配置 3 = 3 (m5.xlarge + c5d.9xlarge + c5.9xlarge) = 3 (1.356 + 10.721 + 8.872) = 3 20.949 = 63 CNY / hour。

测试后果

总体后果剖析：

• 通过应用 aws cloudwatch 剖析 EC2 的资源利用状况，可能更好的发现性能瓶颈，以便调整配置取得更好的性能价格比。
• 测试的目标之一是为了掂量云上不同配置下的性能价格比，每个具体操作前面都给出了性价比的折线图，更直观的显示比照后果。从后果上看，配置 3 可能更好施展集群各局部的整体性能，具备更高的性能价格比（qps/price per hour)。
• 因为存储节点基于 mysql 开发, 具备残缺的 SQL 解析执行性能，存储节点比其余竞品的存储节点具备更弱小的性能，但也要求更高的 CPU，在简单查问下性能也更杰出。
• 除 point select 外的其余汇集类查问对网络要求较高，在 AWS 上更容易展现出高性能，机房内的 1Gb/ s 的网络中，网络先到瓶颈，无奈测出高性能。

point selects

Sysben 命令:

 ./sysbench --max-time=300 --test=tests/db/oltp.lua  --pgsql-host=$host  --pgsql-port=$port --pgsql-db=$dbname--oltp_tables_count=$tblcnt --oltp-table-size=$tblsize --oltp-write-only=off--oltp-read-only=on --init-rng=on --num-threads=$thrcnt  --max-requests=0 --oltp-dist-type=uniform--pgsql-user=$user --pgsql-password=$pass --oltp_auto_inc=off --db-driver=pgsql --oltp_use_xa_pct=0--oltp_use_xa_2pc_pct=80 --oltp_point_selects=10 --oltp_simple_ranges=0--oltp_sum_ranges=0 --oltp_order_ranges=0 --oltp_distinct_ranges=0 --report-interval=30run

rbr 模式的后果：

simple range selects

Sysbench 命令：

./sysbench --max-time=300 --test=tests/db/oltp.lua  --pgsql-host=$host  --pgsql-port=$port --pgsql-db=$dbname --oltp_tables_count=$tblcnt--oltp-table-size=$tblsize --oltp-write-only=off --oltp-read-only=on--init-rng=on --num-threads=$thrcnt --max-requests=0 --oltp-dist-type=uniform --pgsql-user=$user--pgsql-password=$pass --oltp_auto_inc=off --db-driver=pgsql --oltp_use_xa_pct=0--oltp_use_xa_2pc_pct=80 --oltp_point_selects=0 --oltp_simple_ranges=1--oltp_sum_ranges=0 --oltp_order_ranges=0 --oltp_distinct_ranges=0--report-interval=30 run

rbr 模式的后果：

sum range selects

Sysbench 命令:

./sysbench --max-time=300 --test=tests/db/oltp.lua  --pgsql-host=$host  --pgsql-port=$port --pgsql-db=$dbname--oltp_tables_count=$tblcnt --oltp-table-size=$tblsize --oltp-write-only=off--oltp-read-only=on --init-rng=on --num-threads=$thrcnt  --max-requests=0 --oltp-dist-type=uniform --pgsql-user=$user--pgsql-password=$pass  --oltp_auto_inc=off --db-driver=pgsql--oltp_use_xa_pct=0 --oltp_use_xa_2pc_pct=80 --oltp_point_selects=0--oltp_simple_ranges=0 --oltp_sum_ranges=1 --oltp_order_ranges=0--oltp_distinct_ranges=0 --report-interval=30 run

rbr 模式的后果：

order by range selects

Sysbench 命令：

./sysbench --max-time=300 --test=tests/db/oltp.lua  --pgsql-host=$host  --pgsql-port=$port --pgsql-db=$dbname--oltp_tables_count=$tblcnt --oltp-table-size=$tblsize --oltp-write-only=off--oltp-read-only=on --init-rng=on --num-threads=$thrcnt  --max-requests=0 --oltp-dist-type=uniform--pgsql-user=$user --pgsql-password=$pass --oltp_auto_inc=off --db-driver=pgsql --oltp_use_xa_pct=0--oltp_use_xa_2pc_pct=80 --oltp_point_selects=0 --oltp_simple_ranges=0--oltp_sum_ranges=0 --oltp_order_ranges=1 --oltp_distinct_ranges=0--report-interval=30 run

rbr 模式的后果：

distinct range selects

Sysbench 命令：

./sysbench --max-time=300 --test=tests/db/oltp.lua  --pgsql-host=$host  --pgsql-port=$port --pgsql-db=$dbname --oltp_tables_count=$tblcnt--oltp-table-size=$tblsize --oltp-write-only=off --oltp-read-only=on--init-rng=on --num-threads=$thrcnt --max-requests=0 --oltp-dist-type=uniform --pgsql-user=$user--pgsql-password=$pass --oltp_auto_inc=off --db-driver=pgsql --oltp_use_xa_pct=0--oltp_use_xa_2pc_pct=80 --oltp_point_selects=0 --oltp_simple_ranges=0--oltp_sum_ranges=0 --oltp_order_ranges=0 --oltp_distinct_ranges=1--report-interval=30 run

rbr 模式的后果：

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